Block Traffic

Parameter	Description	Default
Fail on Host Network	Emit failure when the targeted container is using the host network	true
Duration	How long should the traffic be affected?	30s
Include Hostnames	(optional) Restrict to/from which hosts the traffic is affected.
Include IPs/CIDRs	(optional) Restrict to/from which IP addresses or blocks the traffic is affected.
Exclude Hostnames	(optional) Exclude traffic to/from these hosts from being affected. Excludes always take precedence over the include restrictions.
Exclude IPs/CIDRs	(optional) Exclude traffic to/from these IP addresses or CIDR blocks from being affected. Excludes always take precedence over the include restrictions.
Include Ports	(optional) Restrict to which ports the traffic is reduced
Block Localhost Traffic	(optional) Also block matching traffic on the loopback interface (127.0.0.0/8, ::1), e.g. between two processes in the same container or between containers of the same pod. Combine with the include restrictions above, otherwise all localhost traffic is blocked.	false

Details

Note: If you are going to attack containers using network attacks, all containers in the target's linux network namespace (e.g. all containers belonging to the same Kubernetes Pod) will be affected. In case you want to target the traffic of a single container in the namespace you can for example use the port parameter to limit the blast radius.

Localhost traffic

By default, localhost traffic (127.0.0.0/8, ::1) in the target's network namespace is not blocked. Enable Block Localhost Traffic to block it as well. As all containers of a Kubernetes Pod share the network namespace, this also blocks traffic between them over localhost, e.g. between an application and its sidecar.

Only localhost traffic matching the include restrictions is blocked. Without restrictions, all localhost traffic in the pod is blocked, including sidecars such as service mesh proxies. Use Include Ports to target a single container's port.
Only the address families of the include restrictions are affected: with IPv4 includes only, ::1 keeps working.
While the attack runs, the namespace's default routing rule for local traffic (0: from all lookup local) is replaced and restored when the attack ends. If that default rule is missing, the attack doesn't start.
A Block Traffic attack with this option can't run at the same time as another Block Traffic attack on the same container; the second attack fails to start.
If the target container uses the host network, the option blocks the host's localhost traffic (e.g. probes or agents on 127.0.0.1), except the extension's own ports. Use Fail on Host Network to prevent this.

Useful Templates (4 of 21)

See all

Kubernetes deployment survives Redis downtime

Check that your application gracefully handles a Redis cache downtime and continues to deliver its intended functionality. The cache downtime may be caused by an unavailable Redis instance or a complete cluster.

Motivation

Redis downtime can lead to degraded system performance, lost data, and potentially long system recovery times. By testing your system's resilience to Redis downtime, you can ensure that it can handle the outage gracefully and continue to deliver its intended functionality. Additionally, you can identify any potential weaknesses in your system and take appropriate measures to improve its performance and resilience.

Structure

We will verify that a load-balanced user-facing endpoint fully works while having all pods ready. As soon as we simulate Redis downtime, we expect the system to indicate unavailability appropriately and maintain its throughput. We can block the traffic to the Redis instance to simulate downtime. The experiment aims to ensure that your system can gracefully handle the outage and continue delivering its intended functionality. The performance should return to normal after the Redis instance is available again.

Redis

Recoverability

Datadog

Graceful degradation when Microsoft SQL Server database can not be reached

An unavailable Microsoft SQL Server database might be too severe for suitable fallbacks and requires your system to indicate unavailability appropriately

Motivation

Depending on your context, an unavailable Microsoft SQL Server database may be considered so severe that there are no suitable fallbacks. In this case, ensuring that your system indicates an appropriate error message is essential. After the Microsoft SQL Server database returns, your system should recover automatically.

Structure

We ensure that a load-balanced user-facing endpoint fully works while having all pods ready. When we simulate an unavailable Microsoft SQL Server database, we expect the user-facing endpoint to indicate unavailability by responding with a "Service unavailable" status. To simulate the unavailability, we can block the Microsoft SQL Server database client connection on its hostname so that no incoming or outgoing traffic goes through. The endpoint should recover automatically once the Microsoft SQL Server database is reachable again.

Graceful degradation when Oracle database can not be reached

An unavailable Oracle database might be too severe for suitable fallbacks and requires your system to indicate unavailability appropriately

Motivation

Depending on your context, an unavailable Oracle database may be considered so severe that there are no suitable fallbacks. In this case, ensuring that your system indicates an appropriate error message is essential. After the Oracle database returns, your system should recover automatically.

Structure

We ensure that a load-balanced user-facing endpoint fully works while having all pods ready. When we simulate an unavailable Oracle database, we expect the user-facing endpoint to indicate unavailability by responding with a "Service unavailable" status. To simulate the unavailability, we can block the Oracle database client connection on its hostname so that no incoming or outgoing traffic goes through. The endpoint should recover automatically once the Oracle database is reachable again.

Graceful degradation when Postgres database can not be reached

An unavailable Postgres database might be too severe for suitable fallbacks and requires your system to indicate unavailability appropriately

Motivation

Depending on your context, an unavailable Postgres database may be considered so severe that there are no suitable fallbacks. In this case, ensuring that your system indicates an appropriate error message is essential. After the Postgres database returns, your system should recover automatically.

Structure

We ensure that a load-balanced user-facing endpoint fully works while having all pods ready. When we simulate an unavailable Postgres database, we expect the user-facing endpoint to indicate unavailability by responding with a "Service unavailable" status. To simulate the unavailability, we can block the Postgres database client connection on its hostname so that no incoming or outgoing traffic goes through. The endpoint should recover automatically once the Postgres database is reachable again.

More Container Actions

See all