In Search Of A `kubectl blame` Command
Talkat KubeCon + CloudNativeCon North America 2020 Virtual · on Friday, 2020-11-20· at 17:05· Intrado Virtual Event Platform,·
summary
Attempts try to attribute which apply caused which pod change and most fail or trade correctness for performance. Approaches shown: naive injected labels that trigger unwanted restarts, kubectl rollout and Helm status checks that can’t see pod-level causes, kubespy’s heavy watch every pod and top‑down plus bottom‑up tables, and Tilt’s workable mix of ownerReferences + UID matching and content-based template-hash labels. Result: a workable debugger exists but is complex, slow, and brittle for custom controllers.
AI-written summary · about
chapters (15)
- 0:00Intro
- 1:31Outline
- 2:17What this talk is NOT
- 3:02Control Loops
- 4:34Declarative Systems are
- 6:18The Sample App
- 8:16Naive Approach (crash)
- 10:13kubectl rollout (crash)
- 12:32helm upgrade --wait (crash)
- 12:58helm upgrade --wait --debug
- 15:12kubespy trace (crash)
- 19:53Tilt up (crash)
- 20:51Rant Time
- 22:09What Does Kubernetes Give You?
- 23:44Cascading Kubernetes Specs
related talks
36mKubernetes Confessions: Real Mistakes We’ve All Made (and What They Teach Us)
34mBecoming an Expert of Diagnosing a Kubernetes Control Plane Problem
35mThe Art of Debugging Inside K8s Environment
35mKubectl Said What?
30mStreamlined Troubleshooting in Kubernetes
24mDebugging at Scale in Production - Deep into your Containers
26mHow to Debug the Pod Which is Hard to Debug
34mReading 100+ Kubernetes Post-Mortems - lessons learned