Troubleshooting Kubernetes CRDs is too damn hard
summary
Argues that the true usability metric for CRDs is the troubleshooting distance — how many kubectl calls it takes to find a root cause — and shows concrete fixes: put reconciliation results into status fields, use the conditions pattern with status true/false/unknown, include observedGeneration, and prefer a few negative-polarity conditions plus a couple positive summaries. Demonstrates failures with Contour’s HTTPProxy (missing secret required two kubectl steps) and how Gateway API bundles listener and address status so one kubectl get often suffices.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 0:22Welcome
- 1:23What are cids
- 1:51The experience of using cids
- 2:16Breaking a HTTP proxy
- 3:43More complicated problems
- 4:30More cucumbers
- 4:52Troubleshooting distance
- 5:18Why is troubleshooting distance important
- 6:11Spec vs Status
- 7:08Example
- 9:09The unhappy path
- 9:56Top tips
- 10:41Specific and conditions
- 13:09Rules for conditions
- 16:02Other recommendations
- 17:39upstream condition struct
- 17:51examples
- 20:26gateway status
- 23:41Conclusions
related talks
35mMaking CRDs Delightful: Beyond the Pitfalls
29mKubernetes Reloaded AKA How to Avoid the Dev Plateau with CRDs
29mKubernetes Reloaded: AKA How to Avoid the Dev Plateau with CRDs
01h 32mTutorial: Debug Your Kubernetes Apps
14mHow to Empower Developers to Troubleshoot K8s Independently
30mStreamlined Troubleshooting in Kubernetes
45mTroubleshooting containerized applications
34mReading 100+ Kubernetes Post-Mortems - lessons learned