To Crd, or Not to Crd, That is the Question
summary
Argues for using Kubernetes CRDs as the app datastore and API surface: teams publish intent as CRDs and run controllers that store state in etcd via CRDs and controllers reconcile desired to observed to enact changes. Gives a concrete home‑automation example wiring Room -> Light CRDs, controllers talk to bulbs, and controllers can run outside the cluster. Notes it works for loosely coupled workflows but hits limits: not a relational DB, etcd performance under noisy write loads, versioning/migration and complex domain models are painful.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 2:45The Kubernetes API
- 7:01Understanding the Kubernetes API
- 10:35Custom Resource Definitions
- 12:29Timeline of extensibility
- 15:26Example service
- 22:08Overview
- 22:50Storage
- 24:06Availability
- 25:14Performance
- 28:14Collaboration
- 29:15Other API Features
- 31:11Conclusion
related talks
38mTo Crd, or Not to Crd, That is the Question
27mDemystifying Why the World Is Built on Kubernetes: Learning To Leverage Bespoke CRDs and Controllers
36mThe future of CRDs in a post-cluster world
19mKeynote: CRDs, No Longer 2nd Class Thing!
29mKubernetes Reloaded: AKA How to Avoid the Dev Plateau with CRDs
29mKubernetes Reloaded AKA How to Avoid the Dev Plateau with CRDs
47mContent Addressable CRDs: Type Uniqueness Across Kubernetes Clusters
26mWriting Kubernetes Controllers for CRDs: Challenges, Approaches and Solutions