Chaoskube

Chaoskube tests how an application responds when one of its running containers disappears. It periodically chooses a Kubernetes Pod and deletes it, letting a team observe whether replicas take over and replacements start as expected. This is useful for checking a specific recovery assumption under controlled conditions. It is a pod-termination experiment, not a simulation of every outage, and its scope must be checked before enabling real deletions.

Deployment and operating notes

The upstream chaoskube README describes periodic random pod termination and shows dry-run operation, namespace and label filters, minimum age and quiet-time controls. That establishes the intended failure model. The old page’s example cannot prove that a different storage system or application remains reliable, and killing a pod does not simulate every node, network or data-loss failure.

Define one hypothesis before enabling termination, such as preserving a request success rate while a replica disappears. Use an explicit allowlist of test namespaces or labels, confirm the candidates in dry-run output and keep an immediate stop mechanism. Review the controller’s RBAC. Chaoskube deletes pods through the Kubernetes Pod deletion API, so PodDisruptionBudgets do not prevent its terminations; do not rely on a disruption budget to limit the experiment. Observe application errors, recovery time and data correctness, rather than only pod readiness. Begin with a disposable workload and expand only after the result is understood. Pin the chosen release and verify its Kubernetes client compatibility; this review did not execute a chaos experiment against a production cluster.