litmus-chaos
Configures LitmusChaos for Kubernetes-native chaos engineering - installs via Helm, picks ChaosExperiments from the ChaosHub (`pod-delete`, `network-latency`, `node-cpu-hog`, etc.), authors a ChaosEngine CR scoping the experiment + steady-state probes, runs as part of the cluster, exports Prometheus metrics for the verdict. Use when the platform is Kubernetes (CNCF-hosted; cloud-native). Prefer over chaos-mesh when the team wants a ChaosCenter web UI for workflow scheduling and ChaosHub catalog browsing; use chaos-mesh for fine-grained network-fault policies via its own CRD family.
Install with skills.sh (any agent)
npx skills add testland/qa --skill litmus-chaoslitmus-chaos
Overview
Per litmus-home (opens in new window):
"LitmusChaos is a CNCF-hosted, open-source Chaos Engineering platform that helps teams identify infrastructure weaknesses through safe, controlled chaos tests."
"Kubernetes developers & SREs use Litmus to manage chaos in a declarative manner." (litmus-home (opens in new window))
The architecture: Litmus runs as a Kubernetes operator; experiments are CRDs; results export to Prometheus.
When to use
Step 1 - Install
Per litmus-home (opens in new window):
helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
helm install litmuschaos litmuschaos/litmus -n litmus --create-namespaceThe Litmus operator + ChaosCenter (web UI) deploy.
Step 2 - Pick a ChaosExperiment from the Hub
Per litmus-home (opens in new window), the ChaosHub is "a repository hosting most of the chaos experiments that are needed for a quick start in Chaos Engineering." Common experiments:
| ChaosExperiment | Effect |
|---|---|
pod-delete | Kill random pods |
pod-network-latency | Inject network latency on the pod |
pod-network-loss | Drop a percentage of packets |
pod-cpu-hog | Spike CPU on the pod |
pod-memory-hog | Spike memory on the pod |
node-cpu-hog | Spike CPU on the node |
node-drain | Drain a node |
disk-fill | Fill the pod's writable disk |
kubelet-service-kill | Kill kubelet on a node |
Install per-experiment:
kubectl apply -f https://hub.litmuschaos.io/api/chaos/2.14.0?file=charts/generic/pod-delete/experiment.yamlStep 3 - Author a ChaosEngine
The ChaosEngine CR runs an experiment against a target:
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
name: checkout-pod-delete
namespace: app
spec:
appinfo:
appns: app
applabel: 'app=checkout'
appkind: deployment
chaosServiceAccount: pod-delete-sa
experiments:
- name: pod-delete
spec:
components:
env:
- name: TOTAL_CHAOS_DURATION
value: '60' # seconds
- name: CHAOS_INTERVAL
value: '20' # seconds
- name: PODS_AFFECTED_PERCENTAGE
value: '50'
probe:
- name: 'check-checkout-availability'
type: httpProbe
httpProbe/inputs:
url: 'http://checkout.app.svc:8080/health'
insecureSkipVerify: false
method:
get:
criteria: '=='
responseCode: '200'
mode: 'Continuous'
runProperties:
probeTimeout: 5
interval: 2
retry: 3
probePollingInterval: 1Per litmus-home (opens in new window), probes "create complete chaos scenarios close to the real application experience upon failure." The probe is the steady-state check per the chaos principles.
Step 4 - Run
kubectl apply -f checkout-pod-delete.yamlLitmus runs the experiment for TOTAL_CHAOS_DURATION seconds, checking the probe continuously. The verdict (Pass / Fail) lands in chaosengine.status.experimentStatus.verdict.
Step 5 - Read the verdict
kubectl get chaosengine checkout-pod-delete -o jsonpath='{.status.experimentStatus.verdict}'
# Output: Pass | FailStep 6 - Probe types
| Probe type | Use |
|---|---|
httpProbe | HTTP endpoint health + status code |
cmdProbe | Run a shell command; check exit code |
k8sProbe | Check Kubernetes resource state |
promProbe | Query Prometheus metric; assert threshold |
Probes can run in different modes: SOT (start of test), EOT (end of test), Edge (both), Continuous (every N seconds during the experiment).
Step 7 - Observability
Per litmus-home (opens in new window): "chaos observability by exporting Prometheus metrics that highlight and quantify the impact of chaos on the applications or infrastructure in real time."
Key metrics:
Wire to Grafana for dashboards.
Step 8 - CI integration
- name: Run chaos experiment
run: |
kubectl apply -f experiments/checkout-pod-delete.yaml
kubectl wait --for=condition=Complete chaosengine/checkout-pod-delete --timeout=10m
VERDICT=$(kubectl get chaosengine checkout-pod-delete -o jsonpath='{.status.experimentStatus.verdict}')
echo "Verdict: $VERDICT"
[ "$VERDICT" = "Pass" ]Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Running ChaosEngine without probe | No steady-state check; verdict meaningless. | Always include httpProbe / promProbe (Step 3). |
PODS_AFFECTED_PERCENTAGE: 100 | Kills all pods; service down. | Start at 25-50%; increase per blast-radius principle. |
| Running in default namespace | Could affect cluster components. | Dedicated app namespace target. |
| One-shot experiment; never re-run | Per chaos principle 4: automate continuously. | Schedule via CronJob (Step 8 in cron form). |
Skipping chaosServiceAccount | RBAC blocks experiment execution. | Define ServiceAccount with appropriate permissions. |
Limitations
References
Related skills
chaos-drill-protocol
Run protocol for a chaos experiment that has already been designed: the four pre-flight gates (non-production target, measured healthy baseline, live observability, a rollback that has actually been exercised), how to pick a conservative blast-radius bound, the sampling cadence and abort criteria fixed in writing before injection, and the recovery-validation step with its tolerance and timeout. Owns execution safety only, not experiment design: the steady-state hypothesis, the fault to inject, and the experiment file come from elsewhere. Use when an experiment definition exists and a fault is about to be injected into a running system, and the go/no-go gates, abort thresholds, and recovery check still need to be agreed and written down before the fault starts.
chaos-experiment-author
Build-an-X workflow for a chaos experiment per the Principles of Chaos Engineering - defines steady-state hypothesis, picks the variables (real-world events: network latency, node failure, region outage), sets the blast radius (which percentage / namespace / user cohort), automates execution, and emits the verdict (steady-state held / didn't hold). Use to scope a chaos experiment before running it via Litmus / Chaos Mesh / Gremlin / Toxiproxy.
chaos-mesh
Configures Chaos Mesh for Kubernetes-native chaos engineering - picks fault types (PodChaos, NetworkChaos, StressChaos, IOChaos, TimeChaos, DNSChaos, KernelChaos, HTTPChaos), targets via label selectors, controls blast radius via namespace whitelists + selector filters, schedules via CronJobs, observes via dashboard. Distinct from Litmus by architecture (Chaos Mesh has its own dashboard + workflow orchestration; Litmus uses ChaosCenter UI). Use when the target system runs on Kubernetes and fault experiments should be declared as CRDs in the cluster alongside the workloads they target.
chaos-results-reporter
Aggregates chaos drill verdicts over time into a resilience trend report - per-experiment hypothesis-held / blast-radius / time-to-detect / time-to-recover, degradation trends across runs, action items, and a stakeholder summary. Use when a team has completed one or more chaos drills and needs a structured trend report showing whether resilience is improving, degrading, or stable across iterations.
failure-injection-test-author
Orchestrates WireMock fault stubs (HTTP-level fault: 500s, malformed JSON, slow responses) with Toxiproxy (TCP-level: latency, packet loss, reset) into a single resilience test scenario - the test starts both, applies fault per scenario, runs the SUT against the impaired endpoints, verifies the SUT's resilience patterns. Use when one test must reproduce a combined network + HTTP failure - a cross-layer failure mode from an incident postmortem that neither pure HTTP fault stubs nor pure TCP chaos can cover alone, because most real failures span both layers.
gremlin-chaos
Configures Gremlin (commercial) for cross-platform chaos engineering (fault injection, resilience testing) - installs the Gremlin agent on Linux / Windows / Kubernetes, picks attack types (resource, network, state, request), chains attacks into Scenarios (chaos experiments), integrates with the Reliability Score for forward-looking metrics. Use when the platform spans multiple environments (bare metal + cloud + serverless) and the team needs a commercial-supported solution per Gremlin's multi-platform support.
steady-state-hypothesis-validator
Validates a chaos experiment's steady-state hypothesis before execution: checks that each probe metric is measurable and observable, that a recent baseline exists, that tolerances are numerically meaningful and SLI-backed, that the measurement window is defined, and that the chosen metrics would actually move under the target failure mode. Use when a chaos experiment has been authored (via chaos-experiment-author) and the team needs a pre-flight verdict before running the drill in any environment.
toxiproxy-chaos
Configures Toxiproxy for TCP-level fault injection - runs as a sidecar / proxy between client and upstream, applies toxics (latency, bandwidth, slow_close, timeout, slicer, limit_data, reset_peer) via control API. Focused on the proxy itself rather than an API-level chaos runner, including non-test usage (chaos in dev environments, integration tests, pre-prod simulation). Use when the team needs TCP-precise fault injection in development / integration environments without K8s or commercial tooling.