Stage 6 · Operate
Reliability Testing & Chaos Engineering
Chaos Tooling
LitmusChaos, Chaos Mesh, Gremlin, fault injection, and Kubernetes failure scenarios.
Chaos Tools Overview
Chaos engineering tools automate failure injection. They provide controlled, repeatable experiments with safety mechanisms. Choose a tool that matches your infrastructure, team size, and maturity level.
| Tool | Approach | Best For | Tradeoffs |
|---|---|---|---|
| LitmusChaos | Kubernetes-native, open source | K8s teams wanting full control | Requires K8s expertise |
| Chaos Mesh | Kubernetes-native, open source | K8s teams with complex scenarios | Limited to K8s |
| Gremlin | Commercial SaaS | Teams wanting managed solution | Cost, vendor lock-in |
| ToxiProxy | Network proxy | Network fault injection | Manual, limited scope |
LitmusChaos
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
name: pod-delete-experiment
namespace: production
spec:
appinfo:
appns: production
applabel: app=user-api
appkind: deployment
chaosServiceAccount: litmus-admin
experiments:
- name: pod-delete
spec:
components:
env:
- name: TOTAL_CHAOS_DURATION
value: "30"
- name: CHAOS_INTERVAL
value: "10"
- name: FORCE
value: "false"
probe:
- name: pod-health-check
type: httpProbe
httpProbe/inputs:
url: http://user-api.production.svc:8080/healthz
method:
get:
criteria: ==
responseCode: "200"
mode: Edge
retryProperties:
timeout: 60
retry: 10
delay: 5
---
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
name: network-chaos-experiment
namespace: production
spec:
appinfo:
appns: production
applabel: app=user-api
appkind: deployment
chaosServiceAccount: litmus-admin
experiments:
- name: network-chaos
spec:
components:
env:
- name: TOTAL_CHAOS_DURATION
value: "60"
- name: NETWORK_INTERFACE
value: "eth0"
- name: NETWORK_LATENCY
value: "200"
- name: JITTER
value: "100"Chaos Mesh
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
name: network-delay
namespace: production
spec:
action: delay
mode: all
selector:
namespaces:
- production
labelSelectors:
app: user-api
delay:
latency: "200ms"
correlation: "100"
jitter: "100ms"
duration: "5m"
---
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
name: pod-kill
namespace: production
spec:
action: pod-kill
mode: one
selector:
namespaces:
- production
labelSelectors:
app: user-api
scheduler:
cron: "@every 5m"
---
apiVersion: chaos-mesh.org/v1alpha1
kind: IOChaos
metadata:
name: io-delay
namespace: production
spec:
action: delay
mode: all
selector:
namespaces:
- production
labelSelectors:
app: user-api
delay: "100ms"
volumePath: /var/log
duration: "5m"
---
apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
name: cpu-stress
namespace: production
spec:
mode: one
selector:
namespaces:
- production
labelSelectors:
app: user-api
stressors:
cpu:
workers: 4
load: 80
duration: "5m"Fault Injection
fault_scenarios:
pod_failures:
description: "Kill or restart pods"
tools: ["LitmusChaos", "Chaos Mesh", "kubectl delete pod"]
risk: "Low — Kubernetes restarts pods automatically"
validation: "Verify pod recovery and request success"
network_faults:
description: "Inject latency, packet loss, or DNS failures"
tools: ["Chaos Mesh", "ToxiProxy", "iptables"]
risk: "Medium — may cause cascading failures"
validation: "Verify circuit breakers and retry logic"
disk_faults:
description: "Fill disk, corrupt files, or slow I/O"
tools: ["LitmusChaos", "dd", "stress-ng"]
risk: "Medium — may affect node stability"
validation: "Verify disk cleanup and alerting"
cpu_stress:
description: "Consume CPU resources"
tools: ["LitmusChaos", "stress-ng", "Chaos Mesh"]
risk: "Low-Medium — may affect co-located pods"
validation: "Verify autoscaling and resource limits"
memory_stress:
description: "Consume memory resources"
tools: ["LitmusChaos", "stress-ng", "Chaos Mesh"]
risk: "Medium — may trigger OOM kills"
validation: "Verify OOM handling and recovery"
time_skew:
description: "Shift system clock"
tools: ["Chaos Mesh", "faketime"]
risk: "High — may break TLS, auth, and scheduling"
validation: "Verify time-dependent systems handle skew"Kubernetes Failure Scenarios
kubernetes_failures:
node_failure:
description: "Simulate node going down"
method: "Cordon and drain node, or use cloud API to stop instance"
impact: "Pods rescheduled to other nodes"
validation: "Verify pod scheduling and service availability"
dns_failure:
description: "Block DNS resolution"
method: "Delete kube-dns pod or block DNS traffic"
impact: "Service discovery fails"
validation: "Verify DNS redundancy and fallback"
etcd_failure:
description: "Disrupt etcd cluster"
method: "Stop etcd pod (single-node) or inject latency"
impact: "Kubernetes control plane becomes unavailable"
validation: "Verify etcd backup and recovery"
storage_failure:
description: "Simulate PVC or storage class failure"
method: "Delete PVC or block storage access"
impact: "Stateful services lose data access"
validation: "Verify backup and restore procedures"
rbac_failure:
description: "Remove service account permissions"
method: "Delete or modify RoleBinding"
impact: "Service cannot access Kubernetes API"
validation: "Verify RBAC least privilege"Choosing the Right Tool
- Kubernetes-native: Use LitmusChaos or Chaos Mesh for full K8s integration.
- Managed solution: Use Gremlin if you want SaaS and support.
- Network testing: Use ToxiProxy for fine-grained network fault injection.
- Simple testing: Use kubectl and shell scripts for basic pod failures.
- Enterprise: Use Gremlin or混沌 engineering platform for compliance and support.
Before investing in chaos tooling, start with kubectl. Delete a pod, block a port, fill a disk. These simple experiments validate your system's resilience without requiring additional tooling.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.