Kube Monkey

kube-monkey deliberately deletes selected Pods to test whether an application keeps working when one instance disappears. Workloads opt in through configuration, and the tool schedules termination within the chosen operating window. It is useful for testing a specific recovery assumption under controlled conditions, rather than waiting for the first real failure. The outcome is the application's availability and correctness during recovery, not merely whether the tool successfully deleted a Pod.

Current guidance

kube-monkey implements scheduled random pod deletion for opted-in workloads. The current upstream README documents labels, configurable operating windows and a dry-run default. These current defaults should be checked against the exact release installed rather than assumed from the historical article’s older schedule examples.

Define the experiment’s hypothesis and acceptable impact first: for example, whether a replicated service remains available while one instance disappears. Select a disposable environment or a bounded workload with permission from its owner. Verify the labels and namespace scope before enabling actual terminations; a misspelled or inherited label can change which applications participate.

Observe user-facing errors, request latency, readiness and recovery time as well as the controller’s termination log. Check stateful behavior and work-in-progress handling, and define a clear stop condition. Pod deletion does not cover node loss, network partitions or storage corruption, so report the tested failure mode precisely. Pin the chart and controller image, review RBAC and preserve experiment results. This source review did not execute a chaos experiment or validate a workload’s resilience.