Chaos Mesh

A chaos engineering platform for Kubernetes: you describe a fault such as a killed pod, network latency or clock skew as a custom resource, and a privileged daemon on each node injects it and takes it away again.

CNCF · Incubating

What it is: Chaos engineering
Type: Open source
Made by: Cloud Native Computing Foundation
Foundation: Cloud Native Computing Foundation, incubating, joined July 2020. Part of the Linux Foundation
License: Apache 2.0
Facts checked: 24 October 2026

What it is

Chaos Mesh runs inside a Kubernetes cluster and is driven through the Kubernetes API. Each kind of fault has its own custom resource: PodChaos kills pods or containers, NetworkChaos adds latency, loss, duplication, corruption, bandwidth limits or a partition, and others cover stress, file I/O, time, DNS, HTTP, kernel, block devices and the JVM, plus AWS, Azure and Google Cloud faults through their APIs. A resource names its targets with namespaces and label selectors, a mode (one random pod, all, a fixed number or a percentage) and a duration.

Three components do the work. The Chaos Controller Manager watches the resources, validates them through admission webhooks and schedules injection and recovery. The Chaos Daemon runs as a privileged DaemonSet on every node and enters a target pod’s namespaces to change its network devices, file system, processes and clock. The optional Chaos Dashboard is a web UI and HTTP API on top. Schedule resources repeat an experiment on a cron expression, and Workflow resources chain experiments in series or in parallel with status checks between them. A separate tool, chaosd, brings the same faults to physical machines outside Kubernetes.

Why teams pick it

Faults are ordinary Kubernetes resources, so they can be applied with kubectl, kept in Git and limited with Kubernetes RBAC
Wide range of faults, from pod kills to per-container clock skew, I/O errors and HTTP response changes, without changing the application
Schedules and workflows cover recurring experiments and multi-step scenarios with health checks
Used as the Kubernetes fault engine by Azure Chaos Studio for AKS, and AWS FIS can create its resources in EKS clusters

Watch out for

The Chaos Daemon is privileged on every node, so a compromised Chaos Mesh is a compromised cluster: in 2025 four CVEs (three rated 9.8) let anyone with in-cluster network access run commands through it, fixed in 2.7.3
Network faults need the NET_SCH_NETEM kernel module on the nodes, and if the controller loses contact with the daemon during injection, the fault can’t be recovered automatically
pod-kill assumes a controller such as a ReplicaSet brings the pod back, and pod-failure swaps in a pause image, which containers without probes may still report as Ready
Built for Kubernetes: hosts outside a cluster need chaosd, and cloud-level faults are limited to a few AWS, Azure and Google Cloud actions

Alternatives

What all chaos engineering have in common →Compare side by side →

LitmusChaosOpen sourceA chaos engineering platform for Kubernetes with a web control plane, ChaosCenter, that designs, schedules and scores experiments, and an execution plane of operators and Kubernetes custom resources that runs the faults in target clusters.

How it fits with other technologies

What Chaos Mesh uses

What uses Chaos Mesh

AWS Fault Injection Servicecan start experiments ofChaos MeshChaos engineering

Kill one random TiKV pod, then add 10 ms of latency to web-show for 30 seconds · yaml

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-example
  namespace: chaos-mesh
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces: [tidb-cluster-demo]
    labelSelectors:
      'app.kubernetes.io/component': 'tikv'
---
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: delay
spec:
  action: delay
  mode: one
  selector:
    namespaces: [default]
    labelSelectors:
      app: web-show
  delay:
    latency: '10ms'
    jitter: '0ms'
  duration: '30s'

See it in a real stack

No architecture uses Chaos Mesh yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2019–2026

PingCAP builds TiDB, a distributed SQL database, and tested it with fault injection from early on. As those tests grew, the team wanted a platform not tied to TiDB; CTO Ed Huang said “traditional deterministic testing has fallen short of our expectations” for distributed systems on Kubernetes. PingCAP open-sourced Chaos Mesh under Apache 2.0 on December 31, 2019, and the CNCF accepted it into its Sandbox in July 2020.

Chaos Mesh 2.0, generally available in July 2021, added a native Workflow engine, the CronJob-like Schedule resource, HTTP and JVM faults, and chaosd for physical machines. The CNCF moved the project to Incubating on February 16, 2022, by then with adopters such as ByteDance, DataStax, Percona and RabbitMQ, and with Azure Chaos Studio using it for AKS. In 2025 JFrog reported a set of flaws in the controller’s debugging GraphQL server, fixed in 2.7.3; the project kept releasing through 2026, with 2.8.6 in October.

Why it’s built this way

One custom resource per fault type: Separate CRDs such as PodChaos, NetworkChaos and IOChaos keep each fault’s definition apart from its logic and let each have its own controller, built with controller-runtime, instead of one object that knows every fault.
A privileged daemon per node: Changing a container’s network, cgroups, file system or clock means entering its namespaces on the node, which needs root. One DaemonSet does that for every pod on the node, so applications need no changes.
General purpose, not TiDB-only: PingCAP wanted “a universal chaos testing platform, not just for TiDB, but also for other distributed systems”, so the faults target any Kubernetes workload.

Timeline

2019
PingCAP open-sources Chaos Mesh on December 31
2020
Accepted into the CNCF Sandbox in July
2021
Chaos Mesh 2.0: Workflow, Schedule, HTTPChaos and chaosd
2022
Moves to CNCF Incubating on February 16
2025
2.7.3 fixes the “Chaotic Deputy” GraphQL vulnerabilities
2026
2.8.6 released in October

Sources9 · facts checked 24 October 2026

Improve this page on GitHub