Canonical chaos through Litmus
summary
Centralizes service-level chaos by extending NuCli to call a Clojure control plane that dispatches Litmus experiments across clusters via Tekton workflows and agents, with auth/audit labels and Prometheus/VictoriaMetrics probes required for safety. It supports five experiment types (pod delete, CPU hog, memory hog, network latency, network loss), simplifies inputs (percent CPU instead of engine knobs), and runs in production, already used successfully in staging and some live traffic.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 0:50Canonical approaches at Nubank
- 3:19Canonical stack with Clojure/K8s
- 5:51Introducing Kos and chaos engineering
- 8:45Why Nubank built Kos
- 10:50Simplifying chaos experiments
- 12:56Safety in chaos experiments
- 16:36Authentication in Kos
- 18:02Experiment types in Kos
- 18:44Future plans for Kos
- 21:57Acknowledgments
- 22:43Q&A: Butterfly effects in network experiments
- 24:11Q&A: Prometheus probes
related talks
34mChaos Engineering For Hybrid Targets With LitmusChaos
28mChaos Engineering alongside Litmus and Jenkins
30mBringing Order to Chaos: Make Your Systems More Resilient with Chaos Engineering
39mPracticing Cloud-Native Resliency Is a Challenge: Decoding It with Chaos...
32mChaos Engineering with Litmus and Jenkins
26mUnified Chaos Injection And SLO Validation Experiments In Kubernetes
25mDestroy Your System To Make It More Reliable: An Easy Way To Start Chaos Engineering With LitmusChao
05mProject Lightning Talk: Chaos Unleashed: LitmusChaos and Its Journey Towards CNCF Graduation