The future of CRDs in a post-cluster world
summary
Argues that CRDs alone are insufficient and proposes a post-operator model where service providers publish an API export and clusters consume it via an API binding; bindings keep clusters operator-free, provider-owned CRDs handle lifecycle, and access is constrained by permission claims and sealed status fields. Describes a working prototype in kcp (months-old, used in practice) that creates CRD objects in-cluster without running operators and routes secret and service creation back to the provider.
AI-written summary · about
chapters (5)
- 0:00Introduction to post-cluster world
- 10:20Current challenges with operators
- 19:39Proposed API binding solution
- 27:12Manifesto for future CRDs
- 34:38Q&A on service providers
related talks
36mTowards Something Better Than CRDs In a Post-Operator World
38mTo Crd, or Not to Crd, That is the Question
38mTo Crd, or Not to Crd, That is the Question
32mManaging CRDs and Operators in Practice
47mContent Addressable CRDs: Type Uniqueness Across Kubernetes Clusters
29mExtending Kubernetes Resource Model (KRM) Beyond Kubernetes Workloads
17mDedicated Cluster management using Cluster API and Kube-Bind
27mDemystifying Why the World Is Built on Kubernetes: Learning To Leverage Bespoke CRDs and Controllers