Content Addressable CRDs: Type Uniqueness Across Kubernetes Clusters
summary
Proposes making CRD definitions globally unique by packaging CRDs plus controllers as OCI content-addressable packages and using digests to verify type identity; Crossplane packages and package revisions provide dependency checks, single-controller guarantees and a human-friendly package revision activation workflow. Demonstrates installing a configuration (platform-ref-aws) that resolves provider dependencies, exposes XRDs/compositions, and records digest metadata; optional admission webhooks validate instantiation. Live demo installs succeed after registry delays, showing the approach works end-to-end.
AI-written summary · about
chapters (9)
- 0:00Start
- 3:49What is a type?
- 14:53User-Facing Types are Namespace Scoped
- 22:10Issue #1: Opaque Type Instantiation
- 26:41Applying to Kubernetes Types
- 28:10Crossplane Packages as a Reference
- 30:09Solution #1: Verified Type Instantiation
- 31:11Solution #2: Verified Type Composition
- 32:30Crossplane Package Revisions
related talks
38mTo Crd, or Not to Crd, That is the Question
38mTo Crd, or Not to Crd, That is the Question
26mWriting Kubernetes Controllers for CRDs: Challenges, Approaches and Solutions
19mKeynote: CRDs, No Longer 2nd Class Thing!
19mKeynote: CRDs, No Longer 2nd Class Thing!
27mDemystifying Why the World Is Built on Kubernetes: Learning To Leverage Bespoke CRDs and Controllers
36mThe future of CRDs in a post-cluster world
29mKubernetes Reloaded: AKA How to Avoid the Dev Plateau with CRDs