This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Network Chaos NG Scenarios

1: Network Chaos API
2: Node Interface Down

3: Node Network Chaos

4: Node Network Filter

5: Pod Network Chaos

6: Pod Network Filter

7: VMI Network Chaos

8: VMI Network Filter

This scenario introduce a new infrastructure to refactor and port the current implementation of the network chaos plugins

Available Scenarios

Network Chaos NG scenarios:

1 - Network Chaos API

`AbstractNetworkChaosModule` abstract module class

All the plugins must implement the AbstractNetworkChaosModule abstract class in order to be instantiated and ran by the Netwok Chaos NG plugin. This abstract class implements two main abstract methods:

run(self, target: str, kubecli: KrknTelemetryOpenshift, error_queue: queue.Queue = None) is the entrypoint for each Network Chaos module. If the module is configured to be run in parallel error_queue must not be None
- target: param is the name of the resource (Pod, Node etc.) that will be targeted by the scenario
- kubecli: the KrknTelemetryOpenshift needed by the scenario to access to the krkn-lib methods
- error_queue: a queue that will be used by the plugin to push the errors raised during the execution of parallel modules
get_config(self) -> (NetworkChaosScenarioType, BaseNetworkChaosConfig) returns the common subset of settings shared by all the scenarios BaseNetworkChaosConfig and the type of Network Chaos Scenario that is running (Pod Scenario or Node Scenario)

`BaseNetworkChaosConfig` base module configuration

Is the base class that contains the common parameters shared by all the Network Chaos NG modules.

id is the string name of the Network Chaos NG module
wait_duration if there is more than one network module config in the same config file, the plugin will wait wait_duration seconds before running the following one
test_duration the duration in seconds of the scenario
label_selector the selector used to target the resource
instance_count if greater than 0 picks instance_count elements from the targets selected by the filters randomly
execution if more than one target are selected by the selector the scenario can target the resources both in serial or parallel.
namespace the namespace were the scenario workloads will be deployed
service_account optional service account for the scenario workload (empty string uses the cluster default)
taints : List of taints for which tolerations need to be created. Example: [“node-role.kubernetes.io/master:NoSchedule”]

2 - Node Interface Down

Brings one or more network interfaces down on a target node for a configurable duration, then restores them. Can be used to simulate network partitions, NIC failures, or loss of connectivity at the node level.

How to Run Node Interface Down Scenarios

Choose your preferred method to run node interface down scenarios:

Example scenario file: node_interface_down.yaml

Configuration

- id: node_interface_down
  image: quay.io/krkn-chaos/krkn-network-chaos:latest
  wait_duration: 0
  test_duration: 60
  label_selector: "node-role.kubernetes.io/worker="
  instance_count: 1
  execution: parallel
  namespace: default
  # scenario specific settings
  target: ""
  interfaces: []
  recovery_time: 30
  taints: []

For the common module settings please refer to the documentation.

target: the node name to target (used when label_selector is not set)
interfaces: a list of network interface names to bring down (e.g. ["eth0", "bond0"]). Leave empty to auto-detect the node’s default interface
recovery_time: seconds to wait after bringing the interface(s) back up before continuing. Set to 0 to skip the recovery wait

Usage

To enable node interface down scenarios edit the kraken config file, go to the section kraken -> chaos_scenarios of the yaml structure and add a new element to the list named network_chaos_ng_scenarios then add the desired scenario pointing to the scenario yaml file.

kraken:
    ...
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/openshift/node_interface_down.yaml

Note

You can specify multiple scenario files of the same type by adding additional paths to the list:

kraken:
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/openshift/node_interface_down-1.yaml
            - scenarios/openshift/node_interface_down-2.yaml

You can also combine multiple different scenario types in the same config.yaml file. Scenario types can be specified in any order, and you can include the same scenario type multiple times:

kraken:
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/openshift/node_interface_down.yaml
        - pod_disruption_scenarios:
            - scenarios/pod-kill.yaml
        - node_scenarios:
            - scenarios/node-reboot.yaml

Run

python run_kraken.py --config config/config.yaml

Run

$ podman run --name=<container_name> --net=host --pull=always --env-host=true -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:node-interface-down
$ podman logs -f <container_name or container_id> # Streams Kraken logs
$ podman inspect <container-name or container-id> --format "{{.State.ExitCode}}" # Outputs exit code which can considered as pass/fail for the scenario

$ docker run $(./get_docker_params.sh) --name=<container_name> --net=host --pull=always -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:node-interface-down
OR
$ docker run -e <VARIABLE>=<value> --net=host --pull=always -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:node-interface-down
$ docker logs -f <container_name or container_id> # Streams Kraken logs
$ docker inspect <container-name or container-id> --format "{{.State.ExitCode}}" # Outputs exit code which can considered as pass/fail for the scenario

TIP: Because the container runs with a non-root user, ensure the kube config is globally readable before mounting it in the container. You can achieve this with the following commands:

kubectl config view --flatten > ~/kubeconfig && chmod 444 ~/kubeconfig && docker run $(./get_docker_params.sh) --name=<container_name> --net=host --pull=always -v ~kubeconfig:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:<scenario>

Supported parameters

The following environment variables can be set on the host running the container to tweak the scenario/faults being injected:

ex.) export <parameter_name>=<value>

See list of variables that apply to all scenarios here that can be used/set in addition to these scenario specific variables

Parameter	Description	Default
TOTAL_CHAOS_DURATION	Duration in seconds to keep the interface(s) down	60
RECOVERY_TIME	Seconds to wait after bringing the interface(s) back up	0
NODE_SELECTOR	Label selector to choose target nodes. If not specified, a schedulable node will be chosen at random	""
NODE_NAME	The node name to target (used when label selector is not set)
INSTANCE_COUNT	Restricts the number of nodes selected by the label selector	1
EXECUTION	Execution mode for multiple nodes: `serial` or `parallel`	parallel
INTERFACES	Comma-separated list of interface names to bring down (e.g. `eth0` or `eth0,bond0`). Leave empty to auto-detect the default interface	""
NAMESPACE	Namespace where the chaos workload pod will be deployed	default
TAINTS	List of taints for which tolerations need to be created. Example: `["node-role.kubernetes.io/master:NoSchedule"]`	""
SERVICE_ACCOUNT	Optional service account for the chaos workload pod	""

NOTE In case of using custom metrics profile or alerts profile when CAPTURE_METRICS or ENABLE_ALERTS is enabled, mount the metrics profile from the host on which the container is run using podman/docker under /home/krkn/kraken/config/metrics-aggregated.yaml and /home/krkn/kraken/config/alerts. For example:

$ podman run --name=<container_name> --net=host --pull=always --env-host=true -v <path-to-custom-metrics-profile>:/home/krkn/kraken/config/metrics-aggregated.yaml -v <path-to-custom-alerts-profile>:/home/krkn/kraken/config/alerts -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:node-interface-down

krknctl run node-interface-down [--<parameter> <value>]

Can also set any global variable listed here

Node Interface Down Parameters

Argument	Type	Description	Required	Default Value
`--chaos-duration`	number	Duration in seconds to keep the interface(s) down	false	60
`--recovery-time`	number	Seconds to wait after bringing the interface(s) back up before continuing	false	0
`--node-selector`	string	Label selector to choose target nodes	false	node-role.kubernetes.io/worker=
`--node-name`	string	Node name to target (used when node-selector is not set)	false
`--namespace`	string	Namespace where the chaos workload pod will be deployed	false	default
`--instance-count`	number	Number of nodes to target from those matching the selector	false	1
`--execution`	enum	Execution mode when targeting multiple nodes: `serial` or `parallel`	false	parallel
`--interfaces`	string	Comma-separated list of interface names to bring down. Leave empty to auto-detect the default interface	false
`--image`	string	The chaos workload container image	false	quay.io/redhat-chaos/krkn-ng-tools:latest
`--taints`	string	List of taints for which tolerations need to be created	false

3 - Node Network Chaos

Injects network degradation (latency, packet loss, bandwidth) into a target node’s network interfaces using Linux tc rules.

Injects network degradation (latency, packet loss, bandwidth restriction) into a target node’s network interfaces using Linux tc (traffic control) rules. Unlike node-network-filter which blocks specific ports via iptables, this module shapes traffic at the interface level. Includes safety checks for existing tc rules on the node.

How to Run Node Network Chaos Scenarios

Choose your preferred method to run node network chaos scenarios:

Configuration

- id: node_network_chaos
  image: "quay.io/krkn-chaos/krkn-network-chaos:latest"
  wait_duration: 1
  test_duration: 60
  label_selector: ""
  service_account: ""
  instance_count: 1
  execution: parallel
  namespace: default
  # scenario specific settings
  target: "<node_name>"
  interfaces: []
  ingress: true
  egress: true
  latency: ""         # empty string to skip; or e.g. 100ms (units: us, ms, s)
  loss: 10           # percentage (no % symbol)
  bandwidth: 1gbit   # supported units: bit, kbit, mbit, gbit, tbit
  force: false
  taints: []

For the common module settings please refer to the documentation.

latency: network latency to inject. Format: integer followed by us (microseconds), ms (milliseconds), or s (seconds). Example: 100ms. Set to empty string to skip.
loss: packet loss percentage as a plain integer (no % symbol). Example: 10 means 10% packet loss. Set to empty string to skip.
bandwidth: bandwidth limit. Format: integer followed by bit, kbit, mbit, gbit, or tbit. Example: 100mbit. Set to empty string to skip.
interfaces: list of network interface names to target. Leave empty to auto-detect the node’s default interface.
ingress: apply rules to incoming traffic (default: true)
egress: apply rules to outgoing traffic (default: true)
target: the node name to target (used when label_selector is not set)
force: by default (false), if the target node already has tc rules configured, the scenario aborts with a warning to avoid damaging cluster networking. Set to true to override existing rules. A 10-second warning delay is inserted before proceeding. Use with caution.

Usage

To enable node network chaos scenarios edit the kraken config file, go to the section kraken -> chaos_scenarios of the yaml structure and add a new element to the list named network_chaos_ng_scenarios then add the desired scenario pointing to the scenario yaml file.

kraken:
    ...
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/kube/node-network-chaos.yml

Note

You can specify multiple scenario files of the same type by adding additional paths to the list:

kraken:
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/kube/node-network-chaos-1.yml
            - scenarios/kube/node-network-chaos-2.yml

You can also combine multiple different scenario types in the same config.yaml file. Scenario types can be specified in any order, and you can include the same scenario type multiple times:

kraken:
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/kube/node-network-chaos.yml
        - pod_disruption_scenarios:
            - scenarios/pod-kill.yaml
        - node_scenarios:
            - scenarios/node-reboot.yaml

Warning

When force is set to false (default), the scenario will check if the target node already has complex tc queueing disciplines configured. If existing rules are detected, the scenario aborts to prevent damaging cluster networking. Only set force: true if you understand the implications of overriding existing traffic control rules.

Run

python run_kraken.py --config config/config.yaml

Not yet supported

node_network_chaos is not currently available as a krkn-hub container image. Use the Krkn tab to run this scenario directly.

Not yet supported

node_network_chaos is not currently available via krknctl. Use the Krkn tab to run this scenario directly.

Example scenario file: node-network-chaos.yml

4 - Node Network Filter

Creates iptables rules on one or more nodes to block incoming and outgoing traffic on a port in the node network interface. Can be used to block network based services connected to the node or to block inter-node communication.

How to Run Node Network Filter Scenarios

Choose your preferred method to run node network filter scenarios:

Example scenario file: node-network-filter.yml

Configuration

- id: node_network_filter
  wait_duration: 300
  test_duration: 100
  label_selector: "kubernetes.io/hostname=ip-10-0-39-182.us-east-2.compute.internal"
  instance_count: 1
  execution: parallel
  namespace: 'default'
  # scenario specific settings
  ingress: false
  egress: true
  target: node-name
  interfaces: []
  protocols:
   - tcp
  ports:
    - 2049
  taints: []
  service_account: ""

for the common module settings please refer to the documentation.

ingress: filters incoming traffic on one or more ports
egress: filters outgoing traffic on one or more ports
target: the node name (if label_selector is not set)
interfaces: network interfaces used for outgoing traffic when egress is enabled (same semantics as krknctl and krkn-hub)
ports: ports that incoming and/or outgoing filtering applies to (depending on ingress / egress)
protocols: the IP protocols to filter (tcp and udp)
taints: list of taints for which tolerations are created. Example: ["node-role.kubernetes.io/master:NoSchedule"]
service_account: optional service account for the scenario workload (empty string uses the default)

Usage

To enable hog scenarios edit the kraken config file, go to the section kraken -> chaos_scenarios of the yaml structure and add a new element to the list named network_chaos_ng_scenarios then add the desired scenario pointing to the hog.yaml file.

kraken:
    ...
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/kube/node-network-filter.yml

Note

You can specify multiple scenario files of the same type by adding additional paths to the list:

kraken:
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/kube/node-network-filter-1.yml
            - scenarios/kube/node-network-filter-2.yml
            - scenarios/kube/node-network-filter-3.yml

You can also combine multiple different scenario types in the same config.yaml file. Scenario types can be specified in any order, and you can include the same scenario type multiple times:

kraken:
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/kube/node-network-filter.yml
        - pod_disruption_scenarios:
            - scenarios/pod-kill.yaml
        - node_scenarios:
            - scenarios/node-reboot.yaml
        - network_chaos_ng_scenarios:  # Same type can appear multiple times
            - scenarios/kube/node-network-filter-2.yml

Examples

Please refer to the use cases section for some real usage scenarios.

Run

python run_kraken.py --config config/config.yaml

Run

$ podman run --name=<container_name> --net=host --pull=always --env-host=true -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:node-network-filter
$ podman logs -f <container_name or container_id> # Streams Kraken logs
$ podman inspect <container-name or container-id> --format "{{.State.ExitCode}}" # Outputs exit code which can considered as pass/fail for the scenario

$ docker run $(./get_docker_params.sh) --name=<container_name> --net=host --pull=always -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:node-network-filter
OR 
$ docker run -e <VARIABLE>=<value> --net=host --pull=always -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:node-network-filter
$ docker logs -f <container_name or container_id> # Streams Kraken logs
$ docker inspect <container-name or container-id> --format "{{.State.ExitCode}}" # Outputs exit code which can considered as pass/fail for the scenario

TIP: Because the container runs with a non-root user, ensure the kube config is globally readable before mounting it in the container. You can achieve this with the following commands:

kubectl config view --flatten > ~/kubeconfig && chmod 444 ~/kubeconfig && docker run $(./get_docker_params.sh) --name=<container_name> --net=host --pull=always -v ~kubeconfig:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:<scenario>

Supported parameters

The following environment variables can be set on the host running the container to tweak the scenario/faults being injected:

ex.) export <parameter_name>=<value>

See list of variables that apply to all scenarios here that can be used/set in addition to these scenario specific variables

Parameter	Description	Type	Default
TOTAL_CHAOS_DURATION	set chaos duration (in sec) as desired	number	60
NODE_SELECTOR	defines the node selector for choosing target nodes. If not specified, one schedulable node in the cluster will be chosen at random. If multiple nodes match the selector, all of them will be subjected to stress.	string	""
NODE_NAME	the node name to target (if label selector not selected)	string
INSTANCE_COUNT	restricts the number of selected nodes by the selector	number	“1”
EXECUTION	sets the execution mode of the scenario on multiple nodes, can be parallel or serial	enum	“parallel”
INGRESS	sets the network filter on incoming traffic, can be true or false	boolean	false
EGRESS	sets the network filter on outgoing traffic, can be true or false	boolean	false
INTERFACES	a list of comma separated names of network interfaces (eg. eth0 or eth0,eth1,eth2) to filter for outgoing traffic	string	""
PORTS	a list of comma separated port numbers (eg 8080 or 8080,8081,8082) to filter for both outgoing and incoming traffic	string	""
PROTOCOLS	a list of comma separated protocols to filter (tcp, udp or both)	string
TAINTS	List of taints for which tolerations need to be created. Example: [“node-role.kubernetes.io/master:NoSchedule”]	string	[]
SERVICE_ACCOUNT	optional service account for the Node Network Filter workload	string	""

$ podman run --name=<container_name> --net=host --pull=always --env-host=true -v <path-to-custom-metrics-profile>:/home/krkn/kraken/config/metrics-aggregated.yaml -v <path-to-custom-alerts-profile>:/home/krkn/kraken/config/alerts -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:node-network-filter

krknctl run node-network-filter [--<parameter> <value>]

Can also set any global variable listed here

Node Network Filter Parameters

krknctl marks --ingress and --egress as required flags (you should pass both). Values: at least one of --ingress or --egress must be true; both may be true to filter incoming and outgoing traffic.

Argument	Type	Description	Required	Default Value
`--chaos-duration`	number	Chaos duration in seconds	false	60
`--node-selector`	string	Node label selector (format: `key=value`)	false
`--node-name`	string	Specific node name to target (alternative to node-selector)	false
`--namespace`	string	Namespace where the scenario container is deployed	false	default
`--instance-count`	number	Number of nodes to target when using node-selector	false	1
`--execution`	enum	Execution mode: `parallel` or `serial`	false	parallel
`--ingress`	boolean	Filter incoming traffic (`true` / `false`)	true
`--egress`	boolean	Filter outgoing traffic (`true` / `false`)	true
`--interfaces`	string	Network interfaces for outgoing traffic (comma-separated, e.g. `eth0,eth1`). Optional; empty uses workload defaults	false
`--ports`	string	Network ports to filter traffic (comma-separated, e.g., `8080,8081,8082`)	true
`--image`	string	The network chaos injection workload container image	false	quay.io/krkn-chaos/krkn-network-chaos:latest
`--protocols`	string	Network protocols to filter: `tcp`, `udp`, or `tcp,udp`	false	tcp
`--taints`	string	Comma-separated taints (tolerations are derived for the workload). Same notation as elsewhere in Network Chaos NG docs, e.g. `node-role.kubernetes.io/master:NoSchedule`	false
`--service-account`	string	Service account for the workload (optional)	false

Parameter Format Details

Node Selection:

--node-selector: Label selector in format key=value (e.g., node-role.kubernetes.io/worker=)
--node-name: Specific node name (e.g., ip-10-0-1-100.ec2.internal)
Specify either --node-selector OR --node-name, not both
When using --node-selector, use --instance-count to limit the number of selected nodes

Port Format:

Single port: 8080
Multiple ports: 8080,8081,8082 (comma-separated, no spaces)

Protocol Format:

Valid values: tcp, udp, tcp,udp, or udp,tcp
Default: tcp

Interface Format:

Applies to egress (outgoing) filtering, matching the scenario image metadata
Single interface: eth0
Multiple interfaces: eth0,eth1,eth2 (comma-separated, no spaces)
May be left empty when not needed for your egress rules

Taints Format:

Comma-separated Kubernetes taints; the workload gets matching tolerations
Examples: node-role.kubernetes.io/master:NoSchedule or key=value:NoSchedule when the taint includes a value

Usage Notes

Node targeting: This scenario targets nodes (not pods) and creates iptables rules on the target node(s) to filter network traffic
Ingress/Egress: Pass both flags; at least one must be true. Both may be true to filter incoming and outgoing traffic
Execution modes:
- parallel: Applies network filtering to all selected nodes simultaneously
- serial: Applies network filtering to nodes one at a time

Example Commands

Basic egress filtering (block outgoing traffic):

krknctl run node-network-filter \
  --node-selector node-role.kubernetes.io/worker= \
  --instance-count 1 \
  --ingress false \
  --egress true \
  --ports 8080 \
  --protocols tcp \
  --chaos-duration 120

Ingress + egress filtering (block both incoming and outgoing):

krknctl run node-network-filter \
  --node-name ip-10-0-1-100.ec2.internal \
  --ingress true \
  --egress true \
  --ports 9090,9091 \
  --protocols tcp,udp \
  --interfaces eth0 \
  --chaos-duration 300

Multi-port filtering with parallel execution:

krknctl run node-network-filter \
  --node-selector kubernetes.io/os=linux \
  --instance-count 3 \
  --execution parallel \
  --ingress false \
  --egress true \
  --ports 6379,6380,6381 \
  --protocols tcp \
  --chaos-duration 180

5 - Pod Network Chaos

Injects network degradation (latency, packet loss, bandwidth) into a target pod’s network interfaces using Linux tc rules.

Injects network degradation (latency, packet loss, bandwidth restriction) into a target pod’s network interfaces using Linux tc (traffic control) rules. Unlike pod-network-filter which blocks specific ports via iptables, this module shapes traffic at the interface level.

How to Run Pod Network Chaos Scenarios

Choose your preferred method to run pod network chaos scenarios:

Configuration

- id: pod_network_chaos
  image: "quay.io/krkn-chaos/krkn-network-chaos:latest"
  wait_duration: 1
  test_duration: 60
  label_selector: ""
  service_account: ""
  instance_count: 1
  execution: parallel
  namespace: default
  # scenario specific settings
  target: "<pod_name>"
  interfaces: []
  ingress: true
  egress: true
  latency: ""         # empty string to skip; or e.g. 100ms (units: us, ms, s)
  loss: 10           # percentage (no % symbol)
  bandwidth: 1gbit   # supported units: bit, kbit, mbit, gbit, tbit
  taints: []

For the common module settings please refer to the documentation.

latency: network latency to inject. Format: integer followed by us (microseconds), ms (milliseconds), or s (seconds). Example: 100ms. Set to empty string to skip.
loss: packet loss percentage as a plain integer (no % symbol). Example: 10 means 10% packet loss. Set to empty string to skip.
bandwidth: bandwidth limit. Format: integer followed by bit, kbit, mbit, gbit, or tbit. Example: 100mbit. Set to empty string to skip.
interfaces: list of network interface names to target. Leave empty to auto-detect the pod’s default interface.
ingress: apply rules to incoming traffic (default: true)
egress: apply rules to outgoing traffic (default: true)
target: the pod name to target (used when label_selector is not set)

Usage

To enable pod network chaos scenarios edit the kraken config file, go to the section kraken -> chaos_scenarios of the yaml structure and add a new element to the list named network_chaos_ng_scenarios then add the desired scenario pointing to the scenario yaml file.

kraken:
    ...
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/kube/pod-network-chaos.yml

Note

You can specify multiple scenario files of the same type by adding additional paths to the list:

kraken:
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/kube/pod-network-chaos-1.yml
            - scenarios/kube/pod-network-chaos-2.yml

You can also combine multiple different scenario types in the same config.yaml file. Scenario types can be specified in any order, and you can include the same scenario type multiple times:

kraken:
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/kube/pod-network-chaos.yml
        - pod_disruption_scenarios:
            - scenarios/pod-kill.yaml
        - node_scenarios:
            - scenarios/node-reboot.yaml

Run

python run_kraken.py --config config/config.yaml

Not yet supported

pod_network_chaos is not currently available as a krkn-hub container image. Use the Krkn tab to run this scenario directly.

Not yet supported

pod_network_chaos is not currently available via krknctl. Use the Krkn tab to run this scenario directly.

Example scenario file: pod-network-chaos.yml

6 - Pod Network Filter

Creates iptables rules on one or more pods to block incoming and outgoing traffic on a port in the pod network interface. Can be used to block network based services connected to the pod or to block inter-pod communication.

How to Run Pod Network Filter Scenarios

Choose your preferred method to run pod network filter scenarios:

Example scenario file: pod-network-filter.yml

Configuration

- id: pod_network_filter
  wait_duration: 300
  test_duration: 100
  label_selector: "app=label"
  instance_count: 1
  execution: parallel
  namespace: 'default'
  # scenario specific settings
  ingress: false
  egress: true
  target: 'pod-name'
  interfaces: []
  protocols:
    - tcp
  ports:
    - 80
  taints: []

for the common module settings please refer to the documentation.

ingress: filters the incoming traffic on one or more ports. If set one or more network interfaces must be specified
egress : filters the outgoing traffic on one or more ports.
target: the pod name (if label_selector not set)
interfaces: a list of network interfaces where the incoming traffic will be filtered
ports: the list of ports that will be filtered
protocols: the ip protocols to filter (tcp and udp)
taints : List of taints for which tolerations need to be created. Example: [“node-role.kubernetes.io/master:NoSchedule”]

Usage

kraken:
    ...
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/kube/pod-network-filter.yml

Note

You can specify multiple scenario files of the same type by adding additional paths to the list:

kraken:
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/kube/pod-network-filter-1.yml
            - scenarios/kube/pod-network-filter-2.yml
            - scenarios/kube/pod-network-filter-3.yml

You can also combine multiple different scenario types in the same config.yaml file. Scenario types can be specified in any order, and you can include the same scenario type multiple times:

kraken:
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/kube/pod-network-filter.yml
        - pod_disruption_scenarios:
            - scenarios/pod-kill.yaml
        - node_scenarios:
            - scenarios/node-reboot.yaml
        - network_chaos_ng_scenarios:  # Same type can appear multiple times
            - scenarios/kube/pod-network-filter-2.yml

Examples

Please refer to the use cases section for some real usage scenarios.

Run

python run_kraken.py --config config/config.yaml

Run

$ podman run --name=<container_name> --net=host --pull=always --env-host=true -v <path-to-kube-config>:/home/krkn/.kube/config:z -d quay.io/krkn-chaos/krkn-hub:pod-network-filter
$ podman logs -f <container_name or container_id> # Streams Kraken logs
$ podman inspect <container-name or container-id> --format "{{.State.ExitCode}}" # Outputs exit code which can considered as pass/fail for the scenario

$ docker run $(./get_docker_params.sh) --name=<container_name> --net=host --pull=always -v <path-to-kube-config>:/home/krkn/.kube/config:z -d quay.io/krkn-chaos/krkn-hub:pod-network-filter
OR 
$ docker run -e <VARIABLE>=<value> --net=host --pull=always -v <path-to-kube-config>:/home/krkn/.kube/config:z -d quay.io/krkn-chaos/krkn-hub:pod-network-filter
$ docker logs -f <container_name or container_id> # Streams Kraken logs
$ docker inspect <container-name or container-id> --format "{{.State.ExitCode}}" # Outputs exit code which can considered as pass/fail for the scenario

TIP: Because the container runs with a non-root user, ensure the kube config is globally readable before mounting it in the container. You can achieve this with the following commands:

kubectl config view --flatten > ~/kubeconfig && chmod 444 ~/kubeconfig && docker run $(./get_docker_params.sh) --name=<container_name> --net=host --pull=always -v ~kubeconfig:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:<scenario>

Supported parameters

The following environment variables can be set on the host running the container to tweak the scenario/faults being injected:

ex.) export <parameter_name>=<value>

See list of variables that apply to all scenarios here that can be used/set in addition to these scenario specific variables

Parameter	Description	Type	Default
TOTAL_CHAOS_DURATION	set chaos duration (in sec) as desired	number	60
POD_SELECTOR	defines the pod selector for choosing target pods. If multiple pods match the selector, all of them will be subjected to stress.	string	""
POD_NAME	the pod name to target (if POD_SELECTOR not specified)	string
INSTANCE_COUNT	restricts the number of selected pods by the selector	number	“1”
EXECUTION	sets the execution mode of the scenario on multiple pods, can be parallel or serial	enum	“parallel”
INGRESS	sets the network filter on incoming traffic, can be true or false	boolean	false
EGRESS	sets the network filter on outgoing traffic, can be true or false	boolean	true
INTERFACES	a list of comma separated names of network interfaces (eg. eth0 or eth0,eth1,eth2) to filter for outgoing traffic	string	""
PORTS	a list of comma separated port numbers (eg 8080 or 8080,8081,8082) to filter for both outgoing and incoming traffic	string	""
PROTOCOLS	a list of comma separated network protocols (tcp, udp or both of them e.g. tcp,udp)	string	“tcp”
NAMESPACE	namespace where the scenario container will be deployed	string	default
IMAGE	the network chaos injection workload container image	string	quay.io/krkn-chaos/krkn-network-chaos:latest
TAINTS	List of taints for which tolerations need to be created. Example: [“node-role.kubernetes.io/master:NoSchedule”]	string	[]
SERVICE_ACCOUNT	optional service account for the Pod Network Filter workload	string	""

$ podman run --name=<container_name> --net=host --pull=always --env-host=true -v <path-to-custom-metrics-profile>:/home/krkn/kraken/config/metrics-aggregated.yaml -v <path-to-custom-alerts-profile>:/home/krkn/kraken/config/alerts -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:pod-network-filter

krknctl run pod-network-filter [--<parameter> <value>]

Can also set any global variable listed here

Argument	Type	Description	Required	Default Value
`--chaos-duration`	number	Chaos Duration	false	60
`--pod-selector`	string	Pod Selector	false
`--pod-name`	string	Pod Name	false
`--namespace`	string	Namespace	false	default
`--instance-count`	number	Number of instances to target	false	1
`--execution`	enum	Execution mode	false
`--ingress`	boolean	Filter incoming traffic	true
`--egress`	boolean	Filter outgoing traffic	true
`--interfaces`	string	Network interfaces to filter outgoing traffic (if more than one separated by comma)	false
`--ports`	string	Network ports to filter traffic (if more than one separated by comma)	true
`--image`	string	The network chaos injection workload container image	false	quay.io/krkn-chaos/krkn-network-chaos:latest
`--protocols`	string	The network protocols that will be filtered	false	tcp
`--taints`	string	Comma-separated taints (tolerations are derived for the workload), e.g. `node-role.kubernetes.io/master:NoSchedule`	false
`--service-account`	string	Service account for the Pod Network Filter workload (optional)	false

Parameter Format Details

Pod Selection:

--pod-selector: Label selector in format key=value (e.g., app=myapp)
--pod-name: Specific pod name (alternative to pod-selector)
Specify either --pod-selector OR --pod-name, not both
When using --pod-selector, use --instance-count to limit the number of selected pods

Port Format:

Single port: 8080
Multiple ports: 8080,8081,8082 (comma-separated, no spaces)

Protocol Format:

Valid values: tcp, udp, tcp,udp, or udp,tcp
Default: tcp

Interface Format:

Single interface: eth0
Multiple interfaces: eth0,eth1,eth2 (comma-separated, no spaces)

Example Commands

Basic egress filtering (block outgoing traffic on a port):

krknctl run pod-network-filter \
  --pod-selector app=myapp \
  --namespace default \
  --ingress false \
  --egress true \
  --ports 8080 \
  --protocols tcp \
  --chaos-duration 120

Ingress + egress filtering (block both directions):

krknctl run pod-network-filter \
  --pod-name my-pod-abc123 \
  --namespace my-namespace \
  --ingress true \
  --egress true \
  --ports 9090,9091 \
  --protocols tcp,udp \
  --chaos-duration 300

Multi-pod filtering with parallel execution:

krknctl run pod-network-filter \
  --pod-selector app=redis \
  --namespace redis-cluster \
  --instance-count 3 \
  --execution parallel \
  --ingress false \
  --egress true \
  --ports 6379,6380 \
  --protocols tcp \
  --chaos-duration 180

7 - VMI Network Chaos

Injects network degradation into a KubeVirt Virtual Machine Instance (VMI) by shaping traffic on the VM's tap interface inside the virt-launcher network namespace. Supports configurable bandwidth limiting, latency injection, and packet loss. Unlike node or pod network chaos, this scenario targets the tap device that connects QEMU to the bridge, so only the specific VMI is affected without disrupting OVN's BFD heartbeats or other workloads on the same node.

How to Run VMI Network Chaos Scenarios

Choose your preferred method to run VMI network chaos scenarios:

Example scenario file: virt_network_chaos.yaml

Configuration

- id: vmi_network_chaos
  image: "quay.io/krkn-chaos/krkn-network-chaos:latest"
  wait_duration: 300
  test_duration: 120
  label_selector: ""
  service_account: ""
  taints: []
  namespace: "my-namespace"
  instance_count: 1
  execution: serial
  target: ".*"
  interfaces: []
  ingress: true
  egress: true
  latency: "100ms"
  loss: "10"
  bandwidth: "100mbit"

For the common module settings please refer to the documentation.

target: regex to match VMI names within the namespace (e.g. "<vmi-name-prefix>-.*" or ".*" for all)
namespace: namespace containing the target VMIs (required; also supports regex to match multiple namespaces)
interfaces: list of tap interface names to target. Leave empty to auto-detect the tap device in the virt-launcher network namespace
ingress: shape incoming traffic to the VM
egress: shape outgoing traffic from the VM
latency: artificial network latency added to packets (e.g. "100ms", "500ms")
loss: percentage of packets to drop (e.g. "10" for 10%, "50" for 50%)
bandwidth: maximum throughput cap (e.g. "100mbit", "1gbit", "500kbit")

Note

At least one of latency, loss, or bandwidth should be set. Setting all three simultaneously compounds the degradation.

Catastrophic Configurations

The following combinations produce the most impactful chaos:

Complete network degradation (maximum chaos):

  latency: "2000ms"
  loss: "50"
  bandwidth: "1mbit"

Combines severe latency with heavy packet loss and near-complete bandwidth exhaustion.

DNS blackout via latency (cascading failures):

  latency: "5000ms"
  loss: "0"
  bandwidth: ""

5-second latency causes DNS timeouts across every service in the VM, producing cascading failures without a hard cut.

Bandwidth starvation:

  latency: ""
  loss: "0"
  bandwidth: "100kbit"

Throttles the VMI to 100 kbit/s — enough to keep connections alive but too slow for most application traffic.

Usage

To enable VMI network chaos scenarios edit the kraken config file, go to the section kraken -> chaos_scenarios of the yaml structure and add a new element to the list named network_chaos_ng_scenarios then add the desired scenario pointing to the scenario yaml file.

kraken:
    ...
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/openshift/virt_network_chaos.yaml

Note

You can specify multiple scenario files of the same type by adding additional paths to the list:

kraken:
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/openshift/virt_network_chaos.yaml
            - scenarios/openshift/virt_network_chaos_2.yaml

You can also combine multiple different scenario types in the same config.yaml file:

kraken:
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/openshift/virt_network_chaos.yaml
        - pod_disruption_scenarios:
            - scenarios/pod-kill.yaml

Run

python run_kraken.py --config config/config.yaml

Run

$ podman run --name=<container_name> --net=host --pull=always --env-host=true -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:vmi-network-chaos
$ podman logs -f <container_name or container_id> # Streams Kraken logs
$ podman inspect <container-name or container-id> --format "{{.State.ExitCode}}" # Outputs exit code which can considered as pass/fail for the scenario

$ docker run $(./get_docker_params.sh) --name=<container_name> --net=host --pull=always -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:vmi-network-chaos
OR
$ docker run -e <VARIABLE>=<value> --net=host --pull=always -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:vmi-network-chaos
$ docker logs -f <container_name or container_id> # Streams Kraken logs
$ docker inspect <container-name or container-id> --format "{{.State.ExitCode}}" # Outputs exit code which can considered as pass/fail for the scenario

TIP: Because the container runs with a non-root user, ensure the kube config is globally readable before mounting it in the container. You can achieve this with the following commands:

kubectl config view --flatten > ~/kubeconfig && chmod 444 ~/kubeconfig && docker run $(./get_docker_params.sh) --name=<container_name> --net=host --pull=always -v ~/kubeconfig:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:vmi-network-chaos

Supported parameters

The following environment variables can be set on the host running the container to tweak the scenario/faults being injected:

ex.) export <parameter_name>=<value>

See list of variables that apply to all scenarios here that can be used/set in addition to these scenario specific variables

Parameter	Description	Type	Default
TOTAL_CHAOS_DURATION	Chaos duration in seconds	number	120
NAMESPACE	Namespace containing the target VMIs (required)	string
VMI_NAME	Regex to match VMI names (e.g. `virt-server-.` or `.` for all)	string	`.*`
LABEL_SELECTOR	Label selector to filter VMIs (e.g. `app=myapp`)	string	`""`
INSTANCE_COUNT	Maximum number of VMIs to target	number	1
EXECUTION	Execution mode: `serial` or `parallel`	enum	`serial`
INGRESS	Shape incoming traffic to the VM	boolean	true
EGRESS	Shape outgoing traffic from the VM	boolean	true
INTERFACES	Comma-separated tap interface names (empty to auto-detect)	string	`""`
LATENCY	Artificial latency added to packets (e.g. `100ms`, `500ms`)	string	`""`
LOSS	Packet loss percentage (e.g. `10` for 10%)	string	`""`
BANDWIDTH	Maximum throughput cap (e.g. `100mbit`, `1gbit`)	string	`""`
WAIT_DURATION	Seconds to wait before running the next scenario in the same file	number	300
IMAGE	Network chaos injection workload image	string	`quay.io/krkn-chaos/krkn-network-chaos:latest`
TAINTS	List of taints for which tolerations are created (e.g. `["node-role.kubernetes.io/master:NoSchedule"]`)	string	`[]`
SERVICE_ACCOUNT	Optional service account for the scenario workload	string	`""`

$ podman run --name=<container_name> --net=host --pull=always --env-host=true -v <path-to-custom-metrics-profile>:/home/krkn/kraken/config/metrics-aggregated.yaml -v <path-to-custom-alerts-profile>:/home/krkn/kraken/config/alerts -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:vmi-network-chaos

krknctl run vmi-network-chaos [--<parameter> <value>]

Can also set any global variable listed here

VMI Network Chaos Parameters

Argument	Type	Description	Required	Default Value
`--chaos-duration`	number	Chaos duration in seconds	false	120
`--namespace`	string	Namespace containing the target VMIs	true
`--target`	string	Regex to match VMI names (e.g. `<vmi-name-prefix>-.` or `.` for all)	false	`.*`
`--label-selector`	string	Label selector to filter VMIs (e.g. `app=myapp`)	false
`--instance-count`	number	Maximum number of VMIs to target	false	1
`--execution`	enum	Execution mode: `parallel` or `serial`	false	serial
`--ingress`	boolean	Shape incoming traffic to the VM	false	true
`--egress`	boolean	Shape outgoing traffic from the VM	false	true
`--interfaces`	string	Comma-separated tap interface names (empty to auto-detect)	false
`--latency`	string	Artificial latency added to packets (e.g. `100ms`, `500ms`)	false
`--loss`	string	Packet loss percentage (e.g. `10` for 10%)	false
`--bandwidth`	string	Maximum throughput cap (e.g. `100mbit`, `1gbit`, `500kbit`)	false
`--image`	string	Network chaos injection workload image	false	quay.io/krkn-chaos/krkn-network-chaos:latest
`--taints`	string	Comma-separated taints for which tolerations are created (e.g. `node-role.kubernetes.io/master:NoSchedule`)	false
`--service-account`	string	Optional service account for the scenario workload	false
`--wait-duration`	number	Seconds to wait before running the next scenario in the same file	false	300

Parameter Format Details

VMI Selection:

--namespace: required; supports regex to match multiple namespaces (e.g. virt-density-.*)
--target: regex matched against VMI names (e.g. <vmi-name-prefix>-.* targets all VMIs whose name starts with that prefix)
--label-selector: Kubernetes label selector in key=value format
Use --instance-count to limit how many matching VMIs are targeted

Traffic Shaping Values:

--latency: any value accepted by Linux tc netem delay (e.g. 100ms, 1s, 500ms)
--loss: integer percentage without the % symbol (e.g. 10 = 10%)
--bandwidth: any value accepted by Linux tc HTB rate (e.g. 100mbit, 1gbit, 500kbit)
At least one of --latency, --loss, or --bandwidth should be set

Interface Detection:

Leave --interfaces empty to let the scenario auto-detect the tap device inside the virt-launcher network namespace
Specify explicitly (e.g. tap0) only if auto-detection fails or you want to target a specific interface

Example Commands

Add latency and packet loss to all VMIs in a namespace:

krknctl run vmi-network-chaos \
  --namespace <namespace> \
  --target ".*" \
  --latency 100ms \
  --loss 10 \
  --chaos-duration 120

Bandwidth cap on a specific VMI:

krknctl run vmi-network-chaos \
  --namespace <namespace> \
  --target "<vmi-name>" \
  --bandwidth 1mbit \
  --ingress true \
  --egress true \
  --chaos-duration 300

Catastrophic combined degradation:

krknctl run vmi-network-chaos \
  --namespace <namespace> \
  --target "<vmi-name-prefix>-.*" \
  --instance-count 3 \
  --execution parallel \
  --latency 2000ms \
  --loss 50 \
  --bandwidth 1mbit \
  --chaos-duration 180

DNS blackout simulation (high latency, no packet drop):

krknctl run vmi-network-chaos \
  --namespace <namespace> \
  --target ".*" \
  --latency 5000ms \
  --chaos-duration 60

8 - VMI Network Filter

Injects iptables-based network filtering into a KubeVirt Virtual Machine Instance (VMI) by applying INPUT and OUTPUT rules inside the virt-launcher network namespace via nsenter. Supports port and protocol-specific filtering so you can selectively block DNS, SSH, HTTP, or any other traffic without cutting all connectivity. The tap interface (tap0) is targeted directly so only the specific VMI is isolated, leaving OVN's BFD heartbeats and other node workloads unaffected.

How to Run VMI Network Filter Scenarios

Choose your preferred method to run VMI network filter scenarios:

Example scenario file: virt_network.yaml

Configuration

- id: vmi_network_filter
  image: "quay.io/krkn-chaos/krkn-network-chaos:latest"
  wait_duration: 300
  test_duration: 120
  label_selector: ""
  service_account: ""
  taints: []
  namespace: "my-namespace"
  instance_count: 1
  execution: serial
  target: ".*"
  interfaces: []
  ingress: true
  egress: true

For the common module settings please refer to the documentation.

target: regex to match VMI names within the namespace (e.g. "<vmi-name-prefix>-.*" or ".*" for all)
namespace: namespace containing the target VMIs (required; also supports regex to match multiple namespaces)
interfaces: list of tap interface names to target. Leave empty to auto-detect the tap device in the virt-launcher network namespace
ingress: apply iptables DROP rules to incoming traffic
egress: apply iptables DROP rules to outgoing traffic
ports: list of ports to block (omit or leave empty to block all ports)
protocols: list of IP protocols to filter — tcp, udp, or both (defaults to ["tcp", "udp"])

Note

ports and protocols are optional. When ports is omitted or empty, all traffic on the specified protocols is blocked — equivalent to full network isolation.

Catastrophic Configurations

Full network isolation (most catastrophic):

  ingress: true
  egress: true
  # no ports or protocols — blocks all TCP and UDP

Complete network cut to the VMI.

DNS blackout (cascading failures):

  ingress: true
  egress: true
  protocols:
    - tcp
    - udp
  ports:
    - 53

Blocking DNS (port 53) causes every service inside the VM that resolves hostnames to fail with timeouts. Cascading failures across the application stack without a hard cut — often the most realistic chaos scenario.

Management plane loss:

  ingress: true
  egress: true
  protocols:
    - tcp
  ports:
    - 22
    - 443
    - 6443

Blocks SSH, HTTPS, and the Kubernetes API server. The VM stays running but is unreachable for management and API calls.

Application layer only:

  ingress: true
  egress: true
  protocols:
    - tcp
  ports:
    - 80
    - 443
    - 8080
    - 8443

Kills HTTP/HTTPS traffic only — tests application resilience without taking the entire VM offline.

Usage

To enable VMI network filter scenarios edit the kraken config file, go to the section kraken -> chaos_scenarios of the yaml structure and add a new element to the list named network_chaos_ng_scenarios then add the desired scenario pointing to the scenario yaml file.

kraken:
    ...
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/openshift/virt_network.yaml

Note

You can specify multiple scenario files of the same type by adding additional paths to the list:

kraken:
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/openshift/virt_network.yaml
            - scenarios/openshift/virt_network_2.yaml

You can also combine multiple different scenario types in the same config.yaml file:

kraken:
    chaos_scenarios:
        - network_chaos_ng_scenarios:
            - scenarios/openshift/virt_network.yaml
        - pod_disruption_scenarios:
            - scenarios/pod-kill.yaml

Run

python run_kraken.py --config config/config.yaml

Run

$ podman run --name=<container_name> --net=host --pull=always --env-host=true -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:vmi-network-filter
$ podman logs -f <container_name or container_id> # Streams Kraken logs
$ podman inspect <container-name or container-id> --format "{{.State.ExitCode}}" # Outputs exit code which can considered as pass/fail for the scenario

$ docker run $(./get_docker_params.sh) --name=<container_name> --net=host --pull=always -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:vmi-network-filter
OR
$ docker run -e <VARIABLE>=<value> --net=host --pull=always -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:vmi-network-filter
$ docker logs -f <container_name or container_id> # Streams Kraken logs
$ docker inspect <container-name or container-id> --format "{{.State.ExitCode}}" # Outputs exit code which can considered as pass/fail for the scenario

TIP: Because the container runs with a non-root user, ensure the kube config is globally readable before mounting it in the container. You can achieve this with the following commands:

kubectl config view --flatten > ~/kubeconfig && chmod 444 ~/kubeconfig && docker run $(./get_docker_params.sh) --name=<container_name> --net=host --pull=always -v ~/kubeconfig:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:vmi-network-filter

Supported parameters

The following environment variables can be set on the host running the container to tweak the scenario/faults being injected:

ex.) export <parameter_name>=<value>

See list of variables that apply to all scenarios here that can be used/set in addition to these scenario specific variables

Parameter	Description	Type	Default
TOTAL_CHAOS_DURATION	Chaos duration in seconds	number	120
NAMESPACE	Namespace containing the target VMIs (required)	string
VMI_NAME	Regex to match VMI names (e.g. `virt-server-.` or `.` for all)	string	`.*`
LABEL_SELECTOR	Label selector to filter VMIs (e.g. `app=myapp`)	string	`""`
INSTANCE_COUNT	Maximum number of VMIs to target	number	1
EXECUTION	Execution mode: `serial` or `parallel`	enum	`serial`
INGRESS	Apply DROP rules to incoming traffic	boolean	true
EGRESS	Apply DROP rules to outgoing traffic	boolean	true
INTERFACES	Comma-separated tap interface names (empty to auto-detect)	string	`""`
PORTS	Comma-separated port numbers to block (empty = all ports)	string	`""`
PROTOCOLS	Comma-separated protocols to filter: `tcp`, `udp`, or both	string	`tcp,udp`
WAIT_DURATION	Seconds to wait before running the next scenario in the same file	number	300
IMAGE	Network chaos injection workload image	string	`quay.io/krkn-chaos/krkn-network-chaos:latest`
TAINTS	List of taints for which tolerations are created (e.g. `["node-role.kubernetes.io/master:NoSchedule"]`)	string	`[]`
SERVICE_ACCOUNT	Optional service account for the scenario workload	string	`""`

$ podman run --name=<container_name> --net=host --pull=always --env-host=true -v <path-to-custom-metrics-profile>:/home/krkn/kraken/config/metrics-aggregated.yaml -v <path-to-custom-alerts-profile>:/home/krkn/kraken/config/alerts -v <path-to-kube-config>:/home/krkn/.kube/config:Z -d quay.io/krkn-chaos/krkn-hub:vmi-network-filter

krknctl run vmi-network-filter [--<parameter> <value>]

Can also set any global variable listed here

VMI Network Filter Parameters

Argument	Type	Description	Required	Default Value
`--chaos-duration`	number	Chaos duration in seconds	false	120
`--namespace`	string	Namespace containing the target VMIs	true
`--target`	string	Regex to match VMI names (e.g. `<vmi-name-prefix>-.` or `.` for all)	false	`.*`
`--label-selector`	string	Label selector to filter VMIs (e.g. `app=myapp`)	false
`--instance-count`	number	Maximum number of VMIs to target	false	1
`--execution`	enum	Execution mode: `parallel` or `serial`	false	serial
`--ingress`	boolean	Apply DROP rules to incoming traffic	false	true
`--egress`	boolean	Apply DROP rules to outgoing traffic	false	true
`--interfaces`	string	Comma-separated tap interface names (empty to auto-detect)	false
`--ports`	string	Comma-separated port numbers to block (e.g. `53`, `22,443,6443`). Empty = all ports	false
`--protocols`	string	Protocols to filter: `tcp`, `udp`, or `tcp,udp`	false	`tcp,udp`
`--image`	string	Network chaos injection workload image	false	quay.io/krkn-chaos/krkn-network-chaos:latest
`--taints`	string	Comma-separated taints for which tolerations are created (e.g. `node-role.kubernetes.io/master:NoSchedule`)	false
`--service-account`	string	Optional service account for the scenario workload	false
`--wait-duration`	number	Seconds to wait before running the next scenario in the same file	false	300

Parameter Format Details

VMI Selection:

--namespace: required; supports regex to match multiple namespaces (e.g. virt-density-.*)
--target: regex matched against VMI names (e.g. <vmi-name-prefix>-.* targets all VMIs whose name starts with that prefix)
Use --instance-count to limit how many matching VMIs are targeted

Port and Protocol Format:

--ports: comma-separated integers, no spaces (e.g. 53 or 22,443,6443). Omit to block all ports
--protocols: tcp, udp, or tcp,udp. Defaults to both

Interface Detection:

Leave --interfaces empty to let the scenario auto-detect the tap device inside the virt-launcher network namespace
Specify explicitly (e.g. tap0) only if auto-detection fails

Example Commands

DNS blackout (most impactful cascading failure):

krknctl run vmi-network-filter \
  --namespace <namespace> \
  --target ".*" \
  --ports 53 \
  --protocols tcp,udp \
  --ingress true \
  --egress true \
  --chaos-duration 120

Full network isolation:

krknctl run vmi-network-filter \
  --namespace <namespace> \
  --target "<vmi-name>" \
  --ingress true \
  --egress true \
  --chaos-duration 60

Management plane loss (SSH + API):

krknctl run vmi-network-filter \
  --namespace <namespace> \
  --target "<vmi-name-prefix>-.*" \
  --instance-count 2 \
  --ports 22,443,6443 \
  --protocols tcp \
  --ingress true \
  --egress true \
  --chaos-duration 300

Application layer only (HTTP/HTTPS):

krknctl run vmi-network-filter \
  --namespace <namespace> \
  --target ".*" \
  --execution parallel \
  --ports 80,443,8080,8443 \
  --protocols tcp \
  --ingress true \
  --egress true \
  --chaos-duration 180

Network Chaos NG Scenarios

Available Scenarios

Network Chaos NG scenarios:

1 - Network Chaos API

AbstractNetworkChaosModule abstract module class

BaseNetworkChaosConfig base module configuration

2 - Node Interface Down

How to Run Node Interface Down Scenarios

Configuration

Usage

Note

Run

Run

Supported parameters

Node Interface Down Parameters

3 - Node Network Chaos

How to Run Node Network Chaos Scenarios

Configuration

Usage

Note

Warning

Run

Not yet supported

Not yet supported

4 - Node Network Filter

How to Run Node Network Filter Scenarios

Configuration

Usage

Note

Examples

Run

Run

Supported parameters

Node Network Filter Parameters

Parameter Format Details

Usage Notes

Example Commands

5 - Pod Network Chaos

How to Run Pod Network Chaos Scenarios

Configuration

Usage

Note

Run

Not yet supported

Not yet supported

6 - Pod Network Filter

How to Run Pod Network Filter Scenarios

Configuration

Usage

Note

Examples

Run

Run

Supported parameters

Parameter Format Details

Example Commands

7 - VMI Network Chaos

How to Run VMI Network Chaos Scenarios

Configuration

Note

Catastrophic Configurations

Usage

Note

Run

Run

Supported parameters

VMI Network Chaos Parameters

Parameter Format Details

Example Commands

8 - VMI Network Filter

How to Run VMI Network Filter Scenarios

Configuration

Note

Catastrophic Configurations

Usage

Note

Run

Run

Supported parameters

VMI Network Filter Parameters

`AbstractNetworkChaosModule` abstract module class

`BaseNetworkChaosConfig` base module configuration