> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/kubernetes.md).

# Chaos Faults for Kubernetes

### Introduction <a href="#introduction" id="introduction"></a>

Kubernetes faults disrupt the resources running on a Kubernetes cluster. They can be categorized into pod-level faults and node-level faults.

{% hint style="info" %}
**EKS FARGATE SUPPORT**

On **Amazon EKS Fargate**, only the following pod-level faults are supported:

* [Pod delete](#pod-delete)
* [Pod autoscaler](#pod-autoscaler)

All other Kubernetes faults require standard EC2-based worker nodes.
{% endhint %}

<table data-view="cards"><thead><tr><th></th><th></th><th><select multiple><option value="KJdeCrBr" label="node" color="blue"></option><option value="G2t7K70Q" label="pod" color="blue"></option><option value="vFflCB9o" label="jvm" color="blue"></option><option value="xT0CaeFJ" label="exception" color="blue"></option><option value="ByUKpor9" label="cpu" color="blue"></option><option value="X8qqCJKZ" label="memory" color="blue"></option><option value="6Fk26ZvW" label="solace" color="blue"></option><option value="B7kSQ_zy" label="latency" color="blue"></option><option value="Pr9L4SpD" label="sql" color="blue"></option><option value="4GO2B-JI" label="mongo" color="blue"></option><option value="duDrHj_o" label="kafka" color="blue"></option><option value="5Slxvgse" label="redis" color="blue"></option><option value="EgaAbFvo" label="cache" color="blue"></option><option value="AfH4YkuP" label="expire" color="blue"></option><option value="uLPcIK61" label="function" color="blue"></option><option value="OlrkfQBZ" label="error" color="blue"></option></select></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Kubelet service kill</strong></td><td>Kubelet service kill makes the application unreachable on the account of the node turning unschedulable (NotReady).</td><td><span data-option="KJdeCrBr">node</span></td><td><a href="#kubelet-service-kill">#kubelet-service-kill</a></td></tr><tr><td><strong>Node CPU hog</strong></td><td>Node CPU hog exhausts the CPU resources on a Kubernetes node.</td><td><span data-option="KJdeCrBr">node</span></td><td><a href="#node-cpu-hog">#node-cpu-hog</a></td></tr><tr><td><strong>Node drain</strong></td><td>Node drain drains the node of all its resources running on it.</td><td><span data-option="KJdeCrBr">node</span></td><td><a href="#node-drain">#node-drain</a></td></tr><tr><td><strong>Node IO stress</strong></td><td>Node IO stress causes I/O stress on the Kubernetes node.</td><td><span data-option="KJdeCrBr">node</span></td><td><a href="#node-io-stress">#node-io-stress</a></td></tr><tr><td><strong>Node memory hog</strong></td><td>Node memory hog causes memory resource exhaustion on the Kubernetes node.</td><td><span data-option="KJdeCrBr">node</span></td><td><a href="#node-memory-hog">#node-memory-hog</a></td></tr><tr><td><strong>Node network latency</strong></td><td>Node network latency introduces network latency to the Kubernetes node.</td><td><span data-option="KJdeCrBr">node</span></td><td><a href="#node-network-latency">#node-network-latency</a></td></tr><tr><td><strong>Node network loss</strong></td><td>Node network loss introduces packet loss in the Kubernetes node.</td><td><span data-option="KJdeCrBr">node</span></td><td><a href="#node-network-loss">#node-network-loss</a></td></tr><tr><td><strong>Node restart</strong></td><td>Node restart disrupts the state of the node by restarting it.</td><td><span data-option="KJdeCrBr">node</span></td><td><a href="#node-restart">#node-restart</a></td></tr><tr><td><strong>Node taint</strong></td><td>Node taint taints (contaminates) the node by applying the desired effect.</td><td><span data-option="KJdeCrBr">node</span></td><td><a href="#node-taint">#node-taint</a></td></tr><tr><td><strong>Container kill</strong></td><td>Container kill terminates a single container inside a target pod, leaving the pod scheduled so the container restarts in place.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#container-kill">#container-kill</a></td></tr><tr><td><strong>Disk fill</strong></td><td>Disk fill consumes a configurable percentage of a target container's ephemeral storage to test eviction and write-failure handling.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#disk-fill">#disk-fill</a></td></tr><tr><td><strong>FS fill</strong></td><td>FS fill writes a configurable amount of data into a specific path inside a target container to test mounted-volume capacity and write-failure handling.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#fs-fill">#fs-fill</a></td></tr><tr><td><strong>Pod API block</strong></td><td>Pod API block drops selected API requests or responses on a target pod using path, method, header, query, and source or destination filters (with HTTPS support).</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-api-block">#pod-api-block</a></td></tr><tr><td><strong>Pod API latency</strong></td><td>Pod API latency adds a configurable delay to selected API calls on a target pod with path, method, header, query, and source or destination filters (with HTTPS support).</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-api-latency">#pod-api-latency</a></td></tr><tr><td><strong>Pod API modify body</strong></td><td>Pod API modify body overwrites request or response bodies on selected API calls of a target pod using path, method, header, query, and source or destination filters (with HTTPS support).</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-api-modify-body">#pod-api-modify-body</a></td></tr><tr><td><strong>Pod API modify header</strong></td><td>Pod API modify header overrides request or response headers on selected API calls of a target pod using path, method, query, and source or destination filters (with HTTPS support).</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-api-modify-header">#pod-api-modify-header</a></td></tr><tr><td><strong>Pod API status code</strong></td><td>Pod API status code overrides the HTTP status code returned by selected API calls of a target pod using path, method, header, query, and source or destination filters (with HTTPS support).</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-api-status-code">#pod-api-status-code</a></td></tr><tr><td><strong>Pod API modify response custom</strong></td><td>Pod API modify response custom combines status code, header, and body modifications on selected API calls of a target pod in a single experiment (with HTTPS support).</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-api-modify-response-custom">#pod-api-modify-response-custom</a></td></tr><tr><td><strong>Pod autoscaler</strong></td><td>Pod autoscaler scales a target Deployment or StatefulSet to a configured replica count for a fixed duration to test cluster capacity and node autoscaling.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-autoscaler">#pod-autoscaler</a></td></tr><tr><td><strong>Pod CPU hog</strong></td><td>Pod CPU hog consumes excess CPU resources of the application container.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-cpu-hog">#pod-cpu-hog</a></td></tr><tr><td><strong>Pod delete</strong></td><td>Pod delete removes one or more pods of a target workload to test replica availability, controller recovery, and graceful termination.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-delete">#pod-delete</a></td></tr><tr><td><strong>Pod DNS error</strong></td><td>Pod DNS error fails DNS lookups from inside a target pod for selected hostnames (or all hostnames) to test how the application handles upstream lookup failures.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-dns-error">#pod-dns-error</a></td></tr><tr><td><strong>Pod DNS spoof</strong></td><td>Pod DNS spoof redirects DNS lookups for selected hostnames inside a target pod to a different address so the application opens connections to the wrong destination.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-dns-spoof">#pod-dns-spoof</a></td></tr><tr><td><strong>Pod HTTP latency</strong></td><td>Pod HTTP latency adds a configurable delay to HTTP responses served by a target pod on a chosen service port to test client timeouts, retries, and tail-latency budgets.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-http-latency">#pod-http-latency</a></td></tr><tr><td><strong>Pod HTTP modify body</strong></td><td>Pod HTTP modify body overwrites the HTTP response body served by a target pod to test client behavior under corrupted, empty, or unexpected payloads.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-http-modify-body">#pod-http-modify-body</a></td></tr><tr><td><strong>Pod HTTP modify header</strong></td><td>Pod HTTP modify header overrides HTTP request or response headers on a target pod to test resilience to missing, altered, or unexpected header values.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-http-modify-header">#pod-http-modify-header</a></td></tr><tr><td><strong>Pod HTTP reset peer</strong></td><td>Pod HTTP reset peer forcibly resets TCP connections carrying HTTP requests to a target pod after a configurable delay to test client retry, connection-pool, and circuit-breaker behavior.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-http-reset-peer">#pod-http-reset-peer</a></td></tr><tr><td><strong>Pod HTTP status code</strong></td><td>Pod HTTP status code overrides the HTTP response status code returned by a target pod (and optionally overwrites the body) to test client error handling on specific HTTP statuses.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-http-status-code">#pod-http-status-code</a></td></tr><tr><td><strong>Pod IO attribute override</strong></td><td>Pod IO attribute override rewrites file attributes returned by stat syscalls on a target container's mounted volume to test how the application reacts to changed permissions, ownership, size, or timestamps.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-io-attribute-override">#pod-io-attribute-override</a></td></tr><tr><td><strong>Pod IO error</strong></td><td>Pod IO error makes filesystem syscalls on a target container's mounted volume return a configurable error code so you can validate how the application handles failed reads, writes, and opens.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-io-error">#pod-io-error</a></td></tr><tr><td><strong>Pod IO latency</strong></td><td>Pod IO latency adds a configurable delay to filesystem syscalls against a target container's mounted volume so you can test how the application behaves under slow storage.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-io-latency">#pod-io-latency</a></td></tr><tr><td><strong>Pod IO mistake</strong></td><td>Pod IO mistake seeds wrong bytes into reads or writes against a target container's mounted volume so you can validate how the application detects and recovers from silent data corruption.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-io-mistake">#pod-io-mistake</a></td></tr><tr><td><strong>Pod IO stress</strong></td><td>Pod IO stress generates sustained filesystem read and write load inside a target container's mounted volume to test disk pressure, slow IO, and ephemeral-storage exhaustion.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-io-stress">#pod-io-stress</a></td></tr><tr><td><strong>Pod JVM method exception</strong></td><td>Pod JVM method exception causes a specific Java method in a target JVM to throw a configurable exception on every invocation so you can test how callers handle the failure.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="vFflCB9o">jvm, </span><span data-option="xT0CaeFJ">exception</span></td><td><a href="#pod-jvm-method-exception">#pod-jvm-method-exception</a></td></tr><tr><td><strong>Pod JVM CPU stress</strong></td><td>Pod JVM CPU stress drives a configurable number of CPU cores inside a target JVM to test how the application behaves when its Java process is starved of CPU.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="vFflCB9o">jvm, </span><span data-option="ByUKpor9">cpu</span></td><td><a href="#pod-jvm-cpu-stress">#pod-jvm-cpu-stress</a></td></tr><tr><td><strong>Pod JVM memory stress</strong></td><td>Pod JVM memory stress injects JVM memory stress for a Java process executing in a Kubernetes pod by consuming excessive memory resources of the JVM.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="vFflCB9o">jvm, </span><span data-option="X8qqCJKZ">memory</span></td><td><a href="#pod-jvm-memory-stress">#pod-jvm-memory-stress</a></td></tr><tr><td><strong>Pod JVM modify return</strong></td><td>Pod JVM modify return overrides the return value of a specific Java method in a target JVM so you can test how callers behave when a method silently returns wrong data.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="vFflCB9o">jvm</span></td><td><a href="#pod-jvm-modify-return">#pod-jvm-modify-return</a></td></tr><tr><td><strong>Pod JVM Solace Latency</strong></td><td>Pod JVM Solace Latency adds a configurable delay to Solace publisher or subscriber calls from a target JVM, scoped by topic or queue, to test timeout and back-pressure behavior under slow Solace messaging.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="vFflCB9o">jvm, </span><span data-option="6Fk26ZvW">solace, </span><span data-option="B7kSQ_zy">latency</span></td><td><a href="#pod-jvm-solace-latency">#pod-jvm-solace-latency</a></td></tr><tr><td><strong>Pod JVM Solace Exception</strong></td><td>Pod JVM Solace Exception causes Solace publisher or subscriber calls from a target JVM to throw a configurable exception on a chosen topic or queue so you can test caller error handling.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="vFflCB9o">jvm, </span><span data-option="6Fk26ZvW">solace, </span><span data-option="xT0CaeFJ">exception</span></td><td><a href="#pod-jvm-solace-exception">#pod-jvm-solace-exception</a></td></tr><tr><td><strong>Pod JVM method latency</strong></td><td>Pod JVM method latency adds a configurable delay to every invocation of a specific Java method in a target JVM so you can test how callers and dependents behave under slow methods.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="B7kSQ_zy">latency</span></td><td><a href="#pod-jvm-method-latency">#pod-jvm-method-latency</a></td></tr><tr><td><strong>Pod JVM trigger gc</strong></td><td>Pod JVM trigger gc forces an immediate full garbage collection in a target JVM so you can measure GC pause impact on latency, throughput, and downstream timeouts.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="vFflCB9o">jvm</span></td><td><a href="#pod-jvm-trigger-gc">#pod-jvm-trigger-gc</a></td></tr><tr><td><strong>Pod JVM SQL Exception</strong></td><td>Pod JVM SQL Exception causes JDBC calls from a target JVM to throw a configurable exception, scoped by table and SQL operation, so you can test how the application handles database failures.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="vFflCB9o">jvm, </span><span data-option="Pr9L4SpD">sql, </span><span data-option="xT0CaeFJ">exception</span></td><td><a href="#pod-jvm-sql-exception">#pod-jvm-sql-exception</a></td></tr><tr><td><strong>Pod JVM SQL Latency</strong></td><td>Pod JVM SQL Latency adds a configurable delay to JDBC calls from a target JVM, scoped by table and SQL operation, so you can test connection-pool exhaustion and timeout handling under slow databases.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="vFflCB9o">jvm, </span><span data-option="Pr9L4SpD">sql, </span><span data-option="B7kSQ_zy">latency</span></td><td><a href="#pod-jvm-sql-latency">#pod-jvm-sql-latency</a></td></tr><tr><td><strong>Pod JVM Mongo Exception</strong></td><td>Pod JVM Mongo Exception causes MongoDB calls from a target JVM to throw a configurable exception, scoped by database and collection, so you can test how the application handles MongoDB failures.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="vFflCB9o">jvm, </span><span data-option="4GO2B-JI">mongo, </span><span data-option="xT0CaeFJ">exception</span></td><td><a href="#pod-jvm-mongo-exception">#pod-jvm-mongo-exception</a></td></tr><tr><td><strong>Pod JVM Mongo Latency</strong></td><td>Pod JVM Mongo Latency adds a configurable delay to MongoDB calls from a target JVM, scoped by database and collection, so you can test how the application behaves under slow MongoDB operations.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="vFflCB9o">jvm, </span><span data-option="4GO2B-JI">mongo, </span><span data-option="B7kSQ_zy">latency</span></td><td><a href="#pod-jvm-mongo-latency">#pod-jvm-mongo-latency</a></td></tr><tr><td><strong>Pod JVM Kafka Exception</strong></td><td>Pod JVM Kafka Exception causes Kafka producer or consumer calls from a target JVM to throw a configurable exception on a chosen topic so you can test how the application handles Kafka failures.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="vFflCB9o">jvm, </span><span data-option="duDrHj_o">kafka, </span><span data-option="xT0CaeFJ">exception</span></td><td><a href="#pod-jvm-kafka-exception">#pod-jvm-kafka-exception</a></td></tr><tr><td><strong>Pod JVM Kafka Latency</strong></td><td>Pod JVM Kafka Latency adds a configurable delay to Kafka producer or consumer calls from a target JVM on a chosen topic so you can test how the application behaves under slow Kafka messaging.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="vFflCB9o">jvm, </span><span data-option="duDrHj_o">kafka, </span><span data-option="B7kSQ_zy">latency</span></td><td><a href="#pod-jvm-kafka-latency">#pod-jvm-kafka-latency</a></td></tr><tr><td><strong>Pod memory hog</strong></td><td>Pod memory hog consumes memory resources in excess, resulting in a significant spike in the memory usage of a pod.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-memory-hog">#pod-memory-hog</a></td></tr><tr><td><strong>Pod network corruption</strong></td><td>Pod network corruption flips random bits in a configurable percentage of packets on a target container's network path.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-network-corruption">#pod-network-corruption</a></td></tr><tr><td><strong>Pod network duplication</strong></td><td>Pod network duplication injects chaos to disrupt the network connectivity to Kubernetes pods.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-network-duplication">#pod-network-duplication</a></td></tr><tr><td><strong>Pod network latency</strong></td><td>Pod network latency adds a configurable delay to packets on a target container's network path.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-network-latency">#pod-network-latency</a></td></tr><tr><td><strong>Pod network loss</strong></td><td>Pod network loss drops a configurable percentage of packets on a target container's network path.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-network-loss">#pod-network-loss</a></td></tr><tr><td><strong>Pod network partition</strong></td><td>Pod network partition blocks 100% ingress and egress traffic of the target application by creating network policy.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-network-partition">#pod-network-partition</a></td></tr><tr><td><strong>Pod network rate limit</strong></td><td>Pod network rate limit fault generates Traffic Control (tc) rules with Token Bucket Filter (TBF) to assess Kubernetes pod resilience under limited network bandwidth condition.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#pod-network-rate-limit">#pod-network-rate-limit</a></td></tr><tr><td><strong>Redis cache penetration</strong></td><td>Redis cache penetration issues a configurable burst of reads for keys that do not exist against a target Redis instance to test downstream database load and null-cache protection.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="5Slxvgse">redis, </span><span data-option="EgaAbFvo">cache</span></td><td><a href="#redis-cache-penetration">#redis-cache-penetration</a></td></tr><tr><td><strong>Redis cache expire</strong></td><td>Redis cache expire expires a configurable set of keys (or all keys) on a target Redis instance to test cold-cache resilience, refill behavior, and downstream database back-pressure.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="5Slxvgse">redis, </span><span data-option="AfH4YkuP">expire</span></td><td><a href="#redis-cache-expire">#redis-cache-expire</a></td></tr><tr><td><strong>Redis cache limit</strong></td><td>Redis cache limit caps the maximum memory of a target Redis instance to force evictions and out-of-memory write errors, then restores the original limit when the fault ends.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="EgaAbFvo">cache, </span><span data-option="5Slxvgse">redis</span></td><td><a href="#redis-cache-limit">#redis-cache-limit</a></td></tr><tr><td><strong>Time chaos</strong></td><td>Time chaos shifts the wall-clock or monotonic time observed by selected processes inside a target container to test application behavior under clock skew, token expiry, and time-based scheduling errors.</td><td><span data-option="G2t7K70Q">pod</span></td><td><a href="#time-chaos">#time-chaos</a></td></tr><tr><td><strong>Pod Application Function Error</strong></td><td>Pod Application Function Error makes a specific instrumented application function return a configurable error on a chosen percentage of invocations so you can test caller error handling and recovery.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="uLPcIK61">function, </span><span data-option="OlrkfQBZ">error</span></td><td><a href="#pod-application-function-error">#pod-application-function-error</a></td></tr><tr><td><strong>Pod Application Function Latency</strong></td><td>Pod Application Function Latency adds a configurable delay to invocations of a specific instrumented application function so you can test how callers and dependents behave under slow functions.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="uLPcIK61">function, </span><span data-option="B7kSQ_zy">latency</span></td><td><a href="#pod-application-function-latency">#pod-application-function-latency</a></td></tr><tr><td><strong>Pod Application Function Exception</strong></td><td>Pod Application Function Exception throws a configurable exception from a specific instrumented application function so you can test how callers and dependents handle thrown failures, including retry filters and circuit breakers.</td><td><span data-option="G2t7K70Q">pod, </span><span data-option="uLPcIK61">function, </span><span data-option="xT0CaeFJ">exception</span></td><td><a href="#pod-application-function-exception">#pod-application-function-exception</a></td></tr></tbody></table>

#### Kubelet service kill <a href="#kubelet-service-kill" id="kubelet-service-kill"></a>

Kubelet service kill makes the application unreachable on the account of the node turning unschedulable (NotReady).

* Kubelet service is stopped (or killed) on a node to make it unschedulable for a specific duration defined by the `TOTAL_CHAOS_DURATION` environment variable.
* The application node goes back to normal state and services are resumed after the chaos duration.

<details>

<summary>Use cases</summary>

This fault determines the resilience of an application when a node becomes unschedulable, i.e. NotReady state.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/kubelet-service-kill.md" class="button primary">View details</a>

#### Node CPU hog <a href="#node-cpu-hog" id="node-cpu-hog"></a>

Node CPU hog exhausts the CPU resources on a Kubernetes node for the period defined by the `TOTAL_CHAOS_DURATION` environment variable.

<details>

<summary>Use cases</summary>

The fault aims to verify the resiliency of applications whose replicas may be evicted on account of nodes turning unschedulable (Not Ready) or new replicas not being able to schedule due to a lack of CPU resources. The fault causes CPU stress on the target node(s). It simulates the situation of lack of CPU for processes running on the application, which degrades their performance. It also helps verify metrics-based horizontal pod autoscaling as well as vertical autoscale, i.e. demand based CPU addition. It helps scalability of nodes based on growth beyond budgeted pods. It verifies the autopilot functionality of (cloud) managed clusters. It benefits include verifying multi-tenant load issues (when the load increases on one container, it does not cause downtime in other containers).

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-cpu-hog.md" class="button primary">View details</a>

#### Node drain <a href="#node-drain" id="node-drain"></a>

Node drain drains the node of all its resources running on it. Due to this, services running on the target node should be rescheduled to run on other nodes.

<details>

<summary>Use cases</summary>

Node drain fault drains all the resources running on a node. This fault determines the resilience of the application when the application replicas scheduled on a node are removed. It validates the application failover capabilities when a node suddenly becomes unavailable. It simulates node maintenance activity (hardware refresh, OS patching, Kubernetes upgrade). It verifies resource budgeting on cluster nodes (whether request (or limit) settings honored on available nodes), and whether topology constraints are adhered to (node selectors, tolerations, zone distribution, affinity(or anti-affinity) policies) or not.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-drain.md" class="button primary">View details</a>

#### Node IO stress <a href="#node-io-stress" id="node-io-stress"></a>

Node IO stress causes I/O stress on the Kubernetes node. The amount of I/O stress is specified as the size in percentage of the total free space available on the file system using `FILESYSTEM_UTILIZATION_PERCENTAGE` environment variable or in gigabytes(GB) using `FILESYSTEM_UTILIZATION_BYTES` environment variable. When both the values are provided, `FILESYSTEM_UTILIZATION_PERCENTAGE` takes precedence. It tests application resiliency on replica evictions that occur due I/O stress on the available disk space.

<details>

<summary>Use cases</summary>

The fault aims to verify the resilience of applications that share the disk resource for ephemeral or persistent storage purposes during high disk I/O usage. It simulates slower disk operations by the application and nosiy neighbour problems by hogging the disk bandwidth. It also verifies the disk performance on increasing I/O threads and varying I/O block sizes. It checks if the application functions under high disk latency conditions, when I/O traffic is very high and includes large I/O blocks, and when other services monopolize the I/O disks.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-io-stress.md" class="button primary">View details</a>

#### Node memory hog <a href="#node-memory-hog" id="node-memory-hog"></a>

Node memory hog causes memory resource exhaustion on the Kubernetes node for the duration specified by the `TOTAL_CHAOS_DURATION` environment variable.

<details>

<summary>Use cases</summary>

Node memory hog causes memory resource exhaustion on the Kubernetes node. The fault aims to verify resilience of applications whose replicas may be evicted on account on nodes becoming unschedulable (Not Ready) due to lack of memory resources. It simulates the situation of memory leaks in the deployment of microservices, application slowness due to memory starvation, and noisy neighbour problems due to hogging. It verifies pod priority and QoS setting for eviction purposes. It also verifies application restarts on OOM kills.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-memory-hog.md" class="button primary">View details</a>

#### Node network latency <a href="#node-network-latency" id="node-network-latency"></a>

Node network latency causes network latency on the Kubernetes node. The chaos affects the application running on the target node for a duration specified by the `TOTAL_CHAOS_DURATION` environment variable.

<details>

<summary>Use cases</summary>

Node network latency introduces a delay in the network communication of a Kubernetes node. The fault aims to verify the resilience of applications when faced with increased network response times. It is designed to test the behavior of applications under delayed network conditions, especially in systems where timely data transfer and communication are crucial.

It simulates the scenarios of high-latency network connections, such as cross-continental data transfers, or situations where a service is communicating with a slow or overburdened external data source. The fault tests the application's ability to maintain service quality and responsiveness in sub-optimal network conditions. It verifies how well the application handles increased response times, timeouts, and the potential for increased queue lengths or backlogs due to network delays. It can also be used to confirm the correct functioning of timeout settings and retry mechanisms in applications.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-network-latency.md" class="button primary">View details</a>

#### Node network loss <a href="#node-network-loss" id="node-network-loss"></a>

Node network loss causes network loss on the Kubernetes node. The chaos affects the application running on the target node for a duration specified by the `TOTAL_CHAOS_DURATION` environment variable.

<details>

<summary>Use cases</summary>

Node network loss simulates packet loss in the network communication of a Kubernetes node. The fault aims to verify the resilience of applications when faced with disrupted network communication, reflecting real-world scenarios such as unstable connections, network partitions, or infrastructure outages.

It mimics situations where the network becomes unreliable, leading to potential data transmission failures, retries, and extended communication delays. The fault challenges applications by hindering their ability to communicate with other services, data stores, or external APIs effectively. It verifies the robustness of applications in handling network interruptions, ensuring data integrity in the face of packet loss, and the effectiveness of error-handling mechanisms under network failures. Additionally, it can be used to test failover strategies, data synchronization policies, and the efficiency of retry logic in applications.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-network-loss.md" class="button primary">View details</a>

#### Node restart <a href="#node-restart" id="node-restart"></a>

Node restart disrupts the state of the node by restarting it. It tests deployment sanity (replica availability and uninterrupted service) and recovery workflows of the application pod.

<details>

<summary>Use cases</summary>

This fault determines the deployment sanity (replica availability and uninterrupted service) and recovery workflows of the application pod in the event of an unexpected node restart. It simulates loss of critical services (or node-crash). It verifies resource budgeting on cluster nodes (whether request(or limit) settings honored on available nodes), and whether topology constraints are adhered to (node selectors, tolerations, zone distribution, affinity(or anti-affinity) policies) or not.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-restart.md" class="button primary">View details</a>

#### Node taint <a href="#node-taint" id="node-taint"></a>

Node taint taints (contaminates) the node by applying the desired effect. The resources that contain the corresponding tolerations only can bypass the taints.

<details>

<summary>Use cases</summary>

The fault aims to verify the resiliency of applications when a certain taint is added to a node. It simulates loss of critical services (or node-crash). It verifies resource budgeting on cluster nodes (whether request(or limit) settings honored on available nodes), and whether topology constraints are adhered to (node selectors, tolerations, zone distribution, affinity(or anti-affinity) policies) or not.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/node/node-taint.md" class="button primary">View details</a>

#### Container kill <a href="#container-kill" id="container-kill"></a>

Container kill is a Kubernetes pod-level chaos fault that terminates a single container inside a target pod, leaving the pod scheduled so the kubelet restarts the container in place.

* It tests an application's deployment sanity (replica availability and uninterrupted service) and recovery workflow.
* It tests the recovery of pods that possess sidecar containers.

<details>

<summary>Use cases</summary>

It tests an application's deployment sanity (replica availability and uninterrupted service) and recovery workflow when certain replicas are not available.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/container-kill.md" class="button primary">View details</a>

#### Disk fill <a href="#disk-fill" id="disk-fill"></a>

Disk fill is a Kubernetes pod-level chaos fault that consumes a configurable percentage of a target container's ephemeral storage to test eviction and write-failure handling.

* It evicts the application pod if its capacity exceeds the pod's ephemeral storage limit.
* It tests the ephemeral storage limits and ensures that the parameters are sufficient.
* It evaluates the application's resilience to disk stress (or replica) evictions.

<details>

<summary>Use cases</summary>

This fault tests the ephemeral storage limits and determines the resilience of the application to unexpected storage exhaustions.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/disk-fill.md" class="button primary">View details</a>

#### FS fill <a href="#fs-fill" id="fs-fill"></a>

FS fill is a Kubernetes pod-level chaos fault that writes a configurable amount of data into a specific path inside a target container to test mounted-volume capacity and write-failure handling.

<details>

<summary>Use cases</summary>

* Tests the ephemeral storage limits and ensures that the parameters are sufficient.
* Determines the resilience of the application to unexpected storage exhaustion.
* Evaluates the application's resilience to FS stress or replica evictions.
* Verifies file system performance, and thin-provisioning support.
* Verifies space reclamation (UNMAP) capabilities on storage.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/fs-fill.md" class="button primary">View details</a>

#### Pod API block <a href="#pod-api-block" id="pod-api-block"></a>

Pod API block is a Kubernetes pod-level chaos fault that blocks selected API requests or responses on a target pod using path, method, header, query parameter, and source or destination filters (with HTTPS support via supplied TLS certificates).

<details>

<summary>Use cases</summary>

* Simulates single-dependency outages by blocking one upstream hostname.
* Tests path-level rollback by blocking just one URL while the rest serve traffic.
* Exposes mutation vs read-only failure modes by blocking `POST`/`PUT`/`DELETE`.
* Validates tenant-scoped failure paths via header-based filtering.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-block.md" class="button primary">View details</a>

#### Pod API latency <a href="#pod-api-latency" id="pod-api-latency"></a>

Pod API latency is a Kubernetes pod-level chaos fault that adds a configurable delay to selected API calls on a target pod using path, method, header, query, and source or destination filters (with HTTPS support via supplied TLS certificates).

<details>

<summary>Use cases</summary>

* Validates timeout budgets scoped to one dependency hostname.
* Drives path-specific tail latency to expose hot-endpoint slowdowns.
* Tests tenant-scoped degradation via header filtering.
* Adds latency to encrypted gRPC and REST calls that simpler HTTP latency cannot reach.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-latency.md" class="button primary">View details</a>

#### Pod API modify body <a href="#pod-api-modify-body" id="pod-api-modify-body"></a>

Pod API modify body is a Kubernetes pod-level chaos fault that overwrites request or response bodies on selected API calls of a target pod using path, method, header, query, and source or destination filters (with HTTPS support via supplied TLS certificates).

<details>

<summary>Use cases</summary>

* Validates defensive deserialization on corrupted or empty payloads.
* Tests schema-evolution resilience to missing fields.
* Drives write-path validation by corrupting the request body.
* Scopes body corruption to one tenant or one endpoint at a time.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-modify-body.md" class="button primary">View details</a>

#### Pod API modify header <a href="#pod-api-modify-header" id="pod-api-modify-header"></a>

Pod API modify header is a Kubernetes pod-level chaos fault that overrides request or response headers on selected API calls of a target pod using path, method, query, and source or destination filters (with HTTPS support via supplied TLS certificates).

<details>

<summary>Use cases</summary>

* Removes or tampers with `Authorization` on one path to validate clean `401` handling.
* Flips `Cache-Control` directives on a specific endpoint's responses.
* Strips tracing headers on a single upstream to expose observability gaps.
* Tests tenant-scoped header chaos via header-based filtering.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-modify-header.md" class="button primary">View details</a>

#### Pod API modify response custom <a href="#pod-api-modify-response-custom" id="pod-api-modify-response-custom"></a>

Pod API modify response custom is a Kubernetes pod-level chaos fault that combines status code, header, and body modifications on selected API calls of a target pod in a single experiment, with path, method, query, and source or destination filters (with HTTPS support via supplied TLS certificates).

<details>

<summary>Use cases</summary>

* Simulates realistic rate-limited responses (`429` + `Retry-After` + JSON body).
* Models maintenance-window scenarios with custom status, headers, and HTML body.
* Reproduces auth-refresh flows by combining `401`, `WWW-Authenticate`, and an error body.
* Tests backwards-compatibility with `200` plus a body missing an expected field.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-modify-response-custom.md" class="button primary">View details</a>

#### Pod API status code <a href="#pod-api-status-code" id="pod-api-status-code"></a>

Pod API status code is a Kubernetes pod-level chaos fault that overrides the HTTP status code returned by selected API calls of a target pod using path, method, header, query, and source or destination filters (with HTTPS support via supplied TLS certificates).

<details>

<summary>Use cases</summary>

* Tests path-scoped error injection (for example `503` on `/v2/checkout` only).
* Validates retry classification on specific status codes (`429`, `503`, `400`).
* Drives error-budget burn calibrated to a known endpoint.
* Reproduces token expiry by returning `401` on the user-info endpoint.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-api-status-code.md" class="button primary">View details</a>

#### Pod autoscaler <a href="#pod-autoscaler" id="pod-autoscaler"></a>

Pod autoscaler is a Kubernetes pod-level chaos fault that scales a target Deployment or StatefulSet to a configured replica count for a fixed duration to test cluster capacity and node autoscaling.

* It examines the node auto-scaling feature by determining whether the pods were successfully rescheduled within a specified time frame if the existing nodes are running at the specified limits.

<details>

<summary>Use cases</summary>

This fault determines how an application accommodates multiple replicas of a given application pod at unexpected point in time.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-autoscaler.md" class="button primary">View details</a>

#### Pod CPU hog <a href="#pod-cpu-hog" id="pod-cpu-hog"></a>

Pod CPU hog is a Kubernetes pod-level chaos fault that excessively consumes CPU resources, resulting in a significant increase in the CPU resource usage of a pod.

* Simulates a situation where an application's CPU resource usage unexpectedly spikes.

<details>

<summary>Use cases</summary>

* The fault causes CPU stress on the target pod(s). It simulates the situation of lack of CPU for processes running on the application, which degrades their performance.
* It also helps verify metrics-based horizontal pod autoscaling as well as vertical autoscale, i.e. demand based CPU addition.
* It helps scalability of nodes based on growth beyond budgeted pods.
* It verifies the autopilot functionality of (cloud) managed clusters.
* Injecting a rogue process into a target container starves the main microservice (typically pid 1) of the resources allocated to it (where limits are defined). This slows down the application traffic or exhausts the resources leading to eviction of all pods. These faults helps build immunity to such stress cases.
* Its benefits include verifying multi-tenant load issues (when the load increases on one container, it does not cause downtime in other containers).

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-cpu-hog.md" class="button primary">View details</a>

#### Pod delete <a href="#pod-delete" id="pod-delete"></a>

Pod delete is a Kubernetes pod-level chaos fault that removes one or more pods of a target workload through the Kubernetes API to test replica availability, controller recovery, and graceful termination.

* It tests an application's deployment sanity (replica availability and uninterrupted service) and recovery workflow.

<details>

<summary>Use cases</summary>

In distributed systems like Kubernetes, your application replicas may not be sufficient to manage the traffic (indicated by SLIs) when some of the replicas are unavailable due to failures. It is important to ensure that the applications have minimum number of available replicas. One of the common application failures is when the pressure on other replicas increases, and how the horizontal pod autoscaler scales based on the observed resource utilization. It is also important to understand how much time it takes for persistent volume to after rescheduling. This fault helps reproduce such a situation with forced (or graceful) pod failure on specific (or random) replicas of an application resource. It checks the deployment sanity (replica availability and uninterrupted service) and recovery workflow of the application.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-delete.md" class="button primary">View details</a>

#### Pod DNS error <a href="#pod-dns-error" id="pod-dns-error"></a>

Pod DNS error is a Kubernetes pod-level chaos fault that fails DNS lookups from inside the target pod for a list of hostnames (or all hostnames) to test how the application handles upstream lookup failures and cluster DNS outages.

<details>

<summary>Use cases</summary>

* Verifies scoped upstream outages by failing only one hostname's resolution.
* Exposes DNS caching behavior and whether the application re-resolves on failure.
* Tests client retry budgets and surfaces hangs caused by missing lookups.
* Validates service-discovery resilience to `NXDOMAIN`-style failures.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-dns-error.md" class="button primary">View details</a>

#### Pod DNS spoof <a href="#pod-dns-spoof" id="pod-dns-spoof"></a>

Pod DNS spoof is a Kubernetes pod-level chaos fault that redirects DNS lookups for selected hostnames inside the target pod to a different address so the application opens connections to the wrong destination.

<details>

<summary>Use cases</summary>

* Simulates misconfigured service discovery and cache-poisoning scenarios.
* Validates TLS hostname verification by pointing a hostname at a service with a non-matching certificate.
* Tests failover misrouting and regional steering bugs.
* Exposes hard-coded address assumptions in client libraries.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-dns-spoof.md" class="button primary">View details</a>

#### Pod HTTP latency <a href="#pod-http-latency" id="pod-http-latency"></a>

Pod HTTP latency is a Kubernetes pod-level chaos fault that adds a configurable delay to HTTP responses served by a target pod on a chosen service port to test client timeouts, retries, and tail-latency budgets.

<details>

<summary>Use cases</summary>

* Validates client timeout budgets when a dependency slows down.
* Exposes retry-storm behavior driven by elevated response time.
* Drives realistic tail-latency degradation via `TOXICITY` partial-affect probability.
* Tests circuit-breaker tripping on sustained slow responses.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-http-latency.md" class="button primary">View details</a>

#### Pod HTTP modify body <a href="#pod-http-modify-body" id="pod-http-modify-body"></a>

Pod HTTP modify body is a Kubernetes pod-level chaos fault that overwrites the HTTP response body served by a target pod (with the value of `RESPONSE_BODY`) to test client behavior under corrupted, empty, or unexpected payloads.

<details>

<summary>Use cases</summary>

* Validates defensive parsing when the body is corrupted but the status code says success.
* Tests schema-evolution resilience to missing fields.
* Exposes empty-payload handling on success responses.
* Verifies content negotiation by changing `CONTENT_TYPE` alongside the body.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-http-modify-body.md" class="button primary">View details</a>

#### Pod HTTP modify header <a href="#pod-http-modify-header" id="pod-http-modify-header"></a>

Pod HTTP modify header is a Kubernetes pod-level chaos fault that overrides HTTP request or response headers on a target pod (via `HEADERS_MAP`) to test resilience to missing, altered, or unexpected header values.

<details>

<summary>Use cases</summary>

* Removes or tampers with `Authorization` to validate clean auth-error handling.
* Flips `Cache-Control` directives to expose cache-poisoning risks.
* Strips tracing headers (`X-Request-ID`, `traceparent`) to reveal observability gaps.
* Tests content-negotiation logic by changing `Content-Type` on the wire.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-http-modify-header.md" class="button primary">View details</a>

#### Pod HTTP reset peer <a href="#pod-http-reset-peer" id="pod-http-reset-peer"></a>

Pod HTTP reset peer is a Kubernetes pod-level chaos fault that forcibly resets the TCP connection carrying an HTTP request to a target pod after a configurable delay to test client retry, connection-pool, and circuit-breaker behavior on abrupt disconnects.

<details>

<summary>Use cases</summary>

* Tests retry classification: connection reset versus `5xx` error.
* Exposes connection-pool churn when pooled connections drop.
* Drives circuit-breaker tripping on repeated `RST` packets.
* Validates reconnect-with-backoff logic for long-lived streams.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-http-reset-peer.md" class="button primary">View details</a>

#### Pod HTTP status code <a href="#pod-http-status-code" id="pod-http-status-code"></a>

Pod HTTP status code is a Kubernetes pod-level chaos fault that overrides the HTTP response status code returned by a target pod (and optionally overwrites the body) to test client error handling, retry classification, and circuit-breaker behavior on specific HTTP statuses.

<details>

<summary>Use cases</summary>

* Tests retry classification on `503`, `502`, and `429` responses.
* Drives error-budget burn on a calibrated percentage of `500`s.
* Exposes cache-invalidation handling by returning `404` on previously-cached resources.
* Validates token-refresh paths on `401`/`403` responses.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-http-status-code.md" class="button primary">View details</a>

#### Pod IO attribute override <a href="#pod-io-attribute-override" id="pod-io-attribute-override"></a>

Pod IO attribute override rewrites file attributes returned by stat syscalls on a target container's mounted volume to test how the application reacts to changed permissions, ownership, size, or timestamps.

* It can test the application's resilience for the different values of file properties.

<details>

<summary>View fault usage</summary>

It can test the application's resilience for the different values of file properties.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-io-attribute-override.md" class="button primary">View details</a>

#### Pod IO error <a href="#pod-io-error" id="pod-io-error"></a>

Pod IO error makes filesystem syscalls on a target container's mounted volume return a configurable error code so you can validate how the application handles failed reads, writes, and opens.

* It can test the application's resilience for the errors in i/o operations.

<details>

<summary>View fault usage</summary>

It can test the application's resilience for the errors in i/o operations.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-io-error.md" class="button primary">View details</a>

#### Pod IO latency <a href="#pod-io-latency" id="pod-io-latency"></a>

Pod IO latency adds a configurable delay to filesystem syscalls against a target container's mounted volume so you can test how the application behaves under slow storage.

* It can test the application's resilience for the latency in i/o operations.

<details>

<summary>View fault usage</summary>

It can test the application's resilience for the latency in i/o operations.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-io-latency.md" class="button primary">View details</a>

#### Pod IO mistake <a href="#pod-io-mistake" id="pod-io-mistake"></a>

Pod IO mistake seeds wrong bytes into reads or writes against a target container's mounted volume so you can validate how the application detects and recovers from silent data corruption.

* It can test the application's resilience to mistakenly writing or reading invalid data from files.

<details>

<summary>View fault usage</summary>

It can test the application's resilience to mistakenly writing or reading invalid data from files..

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-io-mistake.md" class="button primary">View details</a>

#### Pod IO stress <a href="#pod-io-stress" id="pod-io-stress"></a>

Pod IO stress is a Kubernetes pod-level chaos fault that generates sustained filesystem read and write load inside a target container's mounted volume to test how the application handles disk pressure, slow IO, and ephemeral-storage exhaustion.

<details>

<summary>Use cases</summary>

* Pushes ephemeral storage toward its limit to test pod-eviction behavior.
* Drives the volume toward a target fill level and exposes `ENOSPC` handling.
* Raises read/write latency to test backpressure and fsync-heavy workloads.
* Simulates noisy-neighbor IO contention on shared nodes.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-io-stress.md" class="button primary">View details</a>

#### Pod JVM CPU stress <a href="#pod-jvm-cpu-stress" id="pod-jvm-cpu-stress"></a>

Pod JVM CPU stress drives a configurable number of CPU cores inside a target JVM to test how the application behaves when its Java process is starved of CPU.

<details>

<summary>Use cases</summary>

* Tests the system's ability to handle high payloads.
* Evaluates the application's behavior in high-stress cases.
* Induces CPU consumption and exhaustion on the target Java process JVM executing in a K8s pod.
* Simulates a lack of CPU threads for processes running on the application, which degrades their performance.
* Simulates application slowness due to CPU starvation.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-cpu-stress.md" class="button primary">View details</a>

#### Pod JVM memory stress <a href="#pod-jvm-memory-stress" id="pod-jvm-memory-stress"></a>

Pod JVM memory stress injects JVM memory stress for a Java process executing in a Kubernetes pod by consuming excessive memory resources of the JVM. This sometimes results in an OOM kill (Out-of-memory).

<details>

<summary>Use cases</summary>

* Tests the system's ability to handle high payloads.
* Evaluates the application's behavior in high-stress cases.
* Induces memory consumption and exhaustion on the target Java process JVM executing in a K8s pod.
* Simulates a lack of memory for processes running on the application, which degrades their performance.
* Simulates application slowness due to memory starvation, and noisy neighbour problems due to excessive consumption of memory.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-memory-stress.md" class="button primary">View details</a>

#### Pod JVM method exception <a href="#pod-jvm-method-exception" id="pod-jvm-method-exception"></a>

Pod JVM method exception causes a specific Java method in a target JVM to throw a configurable exception on every invocation so you can test how callers handle the failure.

<details>

<summary>Use cases</summary>

* Determines the performance and resilience of an application (or service) on encountering exceptions.
* Determines how efficiently an application recovers the services.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-method-exception.md" class="button primary">View details</a>

#### Pod JVM method latency <a href="#pod-jvm-method-latency" id="pod-jvm-method-latency"></a>

Pod JVM method latency adds a configurable delay to every invocation of a specific Java method in a target JVM so you can test how callers and dependents behave under slow methods.

<details>

<summary>Use cases</summary>

* Determines the performance bottlenecks of the application.
* Tests the system's ability to handle heavy payloads.
* Evaluates the application's behavior in high-stress cases.
* Determines how quickly an application returns to normalcy after the delay.
* Determines the performance and resilience of the dependant application (or services) running on Kubernetes.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-method-latency.md" class="button primary">View details</a>

#### Pod JVM modify return <a href="#pod-jvm-modify-return" id="pod-jvm-modify-return"></a>

Pod JVM modify return overrides the return value of a specific Java method in a target JVM so you can test how callers behave when a method silently returns wrong data.

<details>

<summary>Use cases</summary>

* Helps test the functionality of snippets of code by replacing specific portions of the request or response body to simulate different scenarios and validate how your application handles different data variations.
* Helps obscure or redact personally identifiable information (PII), such as email addresses or phone numbers, before logging or transmitting the data for security and privacy compliance.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-modify-return.md" class="button primary">View details</a>

#### Pod JVM Solace Latency <a href="#pod-jvm-solace-latency" id="pod-jvm-solace-latency"></a>

Pod JVM Solace Latency adds a configurable delay to Solace publisher or subscriber calls from a target JVM, scoped by topic or queue, to test timeout and back-pressure behavior under slow Solace messaging.

<details>

<summary>Use cases</summary>

* Determines the performance bottlenecks of the application
* Simulate solace calls latency to evaluate how the application handles slower solace calls
* Test the impact of message queue latency on the end-user experience, ensuring the application behaves gracefully under slower response times.
* Determines the performance and resilience of the dependant application (or services) running on Kubernetes.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-solace-latency.md" class="button primary">View details</a>

#### Pod JVM Solace Exception <a href="#pod-jvm-solace-exception" id="pod-jvm-solace-exception"></a>

Pod JVM Solace Exception causes Solace publisher or subscriber calls from a target JVM to throw a configurable exception on a chosen topic or queue so you can test caller error handling.

<details>

<summary>Use cases</summary>

* Determines the performance bottlenecks of the application
* Simulates solace calls exceptions to ensure if application can recover gracefully
* Assess if the monitoring systems and alerting mechanisms can accurately detect and report solace calls exceptions in real-time.
* Determines the performance and resilience of the dependant application (or services) running on Kubernetes.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-solace-exception.md" class="button primary">View details</a>

#### Pod JVM trigger gc <a href="#pod-jvm-trigger-gc" id="pod-jvm-trigger-gc"></a>

Pod JVM trigger gc forces an immediate full garbage collection in a target JVM so you can measure GC pause impact on latency, throughput, and downstream timeouts.

<details>

<summary>Use cases</summary>

* Determines how the application behaves when memory space is freed up randomly for a brief period.
* Determines how efficiently an application recovers and returns to normalcy.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-trigger-gc.md" class="button primary">View details</a>

#### Pod JVM SQL Exception <a href="#pod-jvm-sql-exception" id="pod-jvm-sql-exception"></a>

Pod JVM SQL Exception causes JDBC calls from a target JVM to throw a configurable exception, scoped by table and SQL operation, so you can test how the application handles database failures.

<details>

<summary>Use cases</summary>

* Determines the performance bottlenecks of the application
* Simulates SQL exceptions to ensure if application can recover gracefully
* Assess if the monitoring systems and alerting mechanisms can accurately detect and report SQL query exceptions in real-time.
* Determines the performance and resilience of the dependant application (or services) running on Kubernetes.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-sql-exception.md" class="button primary">View details</a>

#### Pod JVM Mongo Latency <a href="#pod-jvm-mongo-latency" id="pod-jvm-mongo-latency"></a>

Pod JVM Mongo Latency adds a configurable delay to MongoDB calls from a target JVM, scoped by database and collection, so you can test how the application behaves under slow MongoDB operations.

<details>

<summary>Use cases</summary>

* Determines the performance bottlenecks of the application
* Simulate database latency to evaluate how the application handles slower database queries
* Test the impact of mongodb calls latency on the end-user experience, ensuring the application behaves gracefully under slower response times.
* Determines the performance and resilience of the dependant application (or services) running on Kubernetes.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-mongo-latency.md" class="button primary">View details</a>

#### Pod JVM Mongo Exception <a href="#pod-jvm-mongo-exception" id="pod-jvm-mongo-exception"></a>

Pod JVM Mongo Exception causes MongoDB calls from a target JVM to throw a configurable exception, scoped by database and collection, so you can test how the application handles MongoDB failures.

<details>

<summary>Use cases</summary>

* Determines the performance bottlenecks of the application
* Simulates mongodb exceptions to ensure if application can recover gracefully
* Assess if the monitoring systems and alerting mechanisms can accurately detect and report mongodb query exceptions in real-time.
* Determines the performance and resilience of the dependant application (or services) running on Kubernetes.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-mongo-exception.md" class="button primary">View details</a>

#### Pod JVM Kafka Exception <a href="#pod-jvm-kafka-exception" id="pod-jvm-kafka-exception"></a>

Pod JVM Kafka Exception causes Kafka producer or consumer calls from a target JVM to throw a configurable exception on a chosen topic so you can test how the application handles Kafka failures.

<details>

<summary>Use cases</summary>

* Determines the performance bottlenecks of the application
* Simulates Kafka exceptions to ensure the application can recover gracefully
* Assess if the monitoring systems and alerting mechanisms can accurately detect and report Kafka exceptions in real-time.
* Tests circuit breaker patterns and fallback mechanisms when Kafka operations fail.
* Determines the performance and resilience of the dependent application (or services) running on Kubernetes.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-kafka-exception.md" class="button primary">View details</a>

#### Pod JVM Kafka Latency <a href="#pod-jvm-kafka-latency" id="pod-jvm-kafka-latency"></a>

Pod JVM Kafka Latency adds a configurable delay to Kafka producer or consumer calls from a target JVM on a chosen topic so you can test how the application behaves under slow Kafka messaging.

<details>

<summary>Use cases</summary>

* Determines the performance bottlenecks of the application
* Simulate Kafka latency to evaluate how the application handles slower message processing
* Test the impact of Kafka operation latency on the end-user experience, ensuring the application behaves gracefully under slower response times.
* Validates timeout configurations and retry mechanisms when Kafka operations are slow.
* Determines the performance and resilience of the dependent application (or services) running on Kubernetes.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-kafka-latency.md" class="button primary">View details</a>

#### Pod JVM SQL Latency <a href="#pod-jvm-sql-latency" id="pod-jvm-sql-latency"></a>

Pod JVM SQL Latency adds a configurable delay to JDBC calls from a target JVM, scoped by table and SQL operation, so you can test connection-pool exhaustion and timeout handling under slow databases.

<details>

<summary>Use cases</summary>

* Determines the performance bottlenecks of the application
* Simulate database latency to evaluate how the application handles slower SQL queries
* Test the impact of SQL query latency on the end-user experience, ensuring the application behaves gracefully under slower response times.
* Determines the performance and resilience of the dependant application (or services) running on Kubernetes.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-jvm-sql-latency.md" class="button primary">View details</a>

#### Pod memory hog <a href="#pod-memory-hog" id="pod-memory-hog"></a>

Pod memory hog is a Kubernetes pod-level chaos fault that consumes memory resources in excess, resulting in a significant spike in the memory usage of a pod.

* Simulates a condition where the memory usage of an application spikes up unexpectedly.

<details>

<summary>Use cases</summary>

Memory usage within containers is subject to various constraints in Kubernetes. If the limits are specified in their spec, exceeding them results in termination of the container (due to OOMKill of the primary process, often pid 1). This restarts container dependng on policy specified. For containers with no limits on memory, node can be killed based on their oom\_score. This results in a bigger blast radius.

This fault causes stress within the target container, which may result in the primary process in the container to be constrained or eat up the available system memory on the node.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-memory-hog.md" class="button primary">View details</a>

#### Pod network corruption <a href="#pod-network-corruption" id="pod-network-corruption"></a>

Pod network corruption is a Kubernetes pod-level chaos fault that flips random bits in a configurable percentage of packets on a target container's network path, simulating a degraded link that mangles bytes on the wire.

* Tests the application's resilience to lossy (or flaky) network.

<details>

<summary>Use cases</summary>

This fault tests the application's resilience to lossy (or flaky) network.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-corruption.md" class="button primary">View details</a>

#### Pod network duplication <a href="#pod-network-duplication" id="pod-network-duplication"></a>

Pod network duplication is a Kubernetes pod-level chaos fault that duplicates a configurable percentage of packets on a target container's network path, exercising TCP duplicate-segment handling and application-level dedup logic.

* It determines the application's resilience to duplicate network packets.

<details>

<summary>Use cases</summary>

It determines the application's resilience to duplicate network.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-duplication.md" class="button primary">View details</a>

#### Pod network latency <a href="#pod-network-latency" id="pod-network-latency"></a>

Pod network latency is a Kubernetes pod-level chaos fault that adds a configurable delay to packets on a target container's network path, simulating slow upstream dependencies, congested links, or cross-region failover.

* It tests the application's resilience to lossy (or flaky) networks.

<details>

<summary>View fault usage</summary>

The fault degrades the network without the pod being marked as unhealthy (or unworthy) of traffic by kube-proxy (unless there is a liveness probe that measures the latency and restarts or crashes the container). This fault simulates issues within the pod network (or microservice communication) across services in different availability zones or regions.

This can be resolved by using middleware that switches traffic based on certain SLOs or performance parameters. Another way is to set up alerts and notifications to highlight a degradation so that it can be addressed and fixed. Another way is to understand the impact of the failure and determine the last point in the application stack before degradation.

The applications may stall or get corrupted while waiting endlessly for a packet. This fault limits the impact (blast radius) to only the traffic that you wish to test by specifying the IP addresses. This fault helps to improve the resilience of your services over time.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-latency.md" class="button primary">View details</a>

#### Pod network loss <a href="#pod-network-loss" id="pod-network-loss"></a>

Pod network loss is a Kubernetes pod-level chaos fault that drops a configurable percentage of packets on a target container's network path, simulating a flaky NIC, degraded overlay link, or CNI hiccup.

* It tests the application's resilience to lossy (or flaky) network.

<details>

<summary>Use cases</summary>

It tests the application's resilience to lossy (or flaky) network.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-loss.md" class="button primary">View details</a>

#### Pod network partition <a href="#pod-network-partition" id="pod-network-partition"></a>

Pod network partition is a Kubernetes pod-level fault that blocks 100% ingress and egress traffic of the target application by creating network policy.

* It can test the application's resilience to lossy (or flaky) network.

<details>

<summary>Use cases</summary>

It can test the application's resilience to lossy (or flaky) network.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-partition.md" class="button primary">View details</a>

#### Pod network rate limit <a href="#pod-network-rate-limit" id="pod-network-rate-limit"></a>

Pod network rate limit is a Kubernetes pod-level chaos fault that generates Traffic Control (tc) rules with Token Bucket Filter (TBF) to assess Kubernetes pod resilience under limited network bandwidth condition.

* It tests the application's resilience to limited or slow network bandwidth.

<details>

<summary>Use cases</summary>

It tests the application's resilience to limited or slow network bandwidth.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-network-rate-limit.md" class="button primary">View details</a>

#### Redis cache expire <a href="#redis-cache-expire" id="redis-cache-expire"></a>

Redis cache expire expires a configurable set of keys (or all keys) on a target Redis instance to test cold-cache resilience, refill behavior, and downstream database back-pressure.

<details>

<summary>Use cases</summary>

Redis cache expire determines the resilience of Redis-dependant applications against frequent cache expiry.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/redis-cache-expire.md" class="button primary">View details</a>

#### Redis cache limit <a href="#redis-cache-limit" id="redis-cache-limit"></a>

Redis cache limit caps the maximum memory of a target Redis instance to force evictions and out-of-memory write errors, then restores the original limit when the fault ends.

<details>

<summary>Use cases</summary>

Redis cache limit determines the resilience of Redis-dependant applications on frequent cache misses that occur due to a low cache size.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/redis-cache-limit.md" class="button primary">View details</a>

#### Redis cache penetration <a href="#redis-cache-penetration" id="redis-cache-penetration"></a>

Redis cache penetration issues a configurable burst of reads for keys that do not exist against a target Redis instance to test downstream database load and null-cache protection.

<details>

<summary>Use cases</summary>

* Slows down the database for responses to other requests.
* Determines the resilience of Redis-dependant application when cache requests are continuously sent to a Redis database and they result in a cache miss.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/redis-cache-penetration.md" class="button primary">View details</a>

#### Time chaos <a href="#time-chaos" id="time-chaos"></a>

Time chaos is a Kubernetes pod-level chaos fault that shifts the wall-clock or monotonic time observed by selected processes inside a target container by a configurable offset to test application behavior under clock skew, token expiry, and time-based scheduling errors.

<details>

<summary>Use cases</summary>

* Exercises token and TLS certificate expiry handling by shifting time forward.
* Simulates NTP drift to test rate limits, idempotency keys, and signed-request validation.
* Stress-tests distributed-lock and lease-deadline logic under clock skew.
* Validates that scheduled timers fire correctly when the clock jumps.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/time-chaos.md" class="button primary">View details</a>

#### Pod Application Function Error <a href="#pod-application-function-error" id="pod-application-function-error"></a>

Pod Application Function Error makes a specific instrumented application function return a configurable error on a chosen percentage of invocations so you can test caller error handling and recovery.

<details>

<summary>Use cases</summary>

* Simulate third-party API failure by injecting errors into wrapper functions.
* Test application behavior when core business logic functions return unexpected errors.
* Validate retry mechanisms and fallback strategies for critical service methods.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-application-function-error.md" class="button primary">View details</a>

#### Pod Application Function Latency <a href="#pod-application-function-latency" id="pod-application-function-latency"></a>

Pod Application Function Latency adds a configurable delay to invocations of a specific instrumented application function so you can test how callers and dependents behave under slow functions.

<details>

<summary>Use cases</summary>

* Simulate slow function execution to test application behavior under degraded performance.
* Validate timeout, retry, and circuit breaker mechanisms when core functions are delayed.
* Induce latency that can lead to application-level failures, helping identify resilience gaps and failure thresholds.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-application-function-latency.md" class="button primary">View details</a>

#### Pod Application Function Exception <a href="#pod-application-function-exception" id="pod-application-function-exception"></a>

Pod Application Function Exception throws a configurable exception from a specific instrumented application function so you can test how callers and dependents handle thrown failures, including retry filters and circuit breakers.

<details>

<summary>Use cases</summary>

* Validate that unchecked exceptions are caught at request boundaries and surface as clean error responses instead of leaking stack traces.
* Confirm exception-aware fallback paths route correctly when a specific exception type is thrown.
* Test retry-filter and circuit-breaker behavior against thrown exceptions versus returned errors.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/kubernetes/pod/pod-application-function-exception.md" class="button primary">View details</a>

{% @harness-feedback/feedback %}
