One Operator To Rule Them All? CRD Management Strategies for Cloud Native Apps!
summary
Compares one-CRD-per-operator versus multi-CRD-per-operator with concrete measurements: an experiment shows a single-CRD setup producing ~640 goroutines versus ~585 when controllers share a pod, and adding controllers increases goroutines by roughly +15 each from a ~30 baseline; shared informer cache cuts redundant memory but packing controllers risks OOM and CPU throttling, especially when caches watch all resources; tuning maxReconcilers controls parallelism; RBAC for Prometheus and alert manager forces overprivileged operators unless separated; tested with up to 3 internal CRDs (references show up to 10).
AI-written summary · about
chapters (10)
- 0:00CRDs and Kubernetes Operators
- 3:10Custom Resource Controllers
- 9:34One or multiple CRDs per pod
- 11:40CRD management strategies
- 18:21Go routines and reconciliation performance
- 20:47Operator stability and failure isolation
- 23:45Role-Based Access Control Considerations for Operators
- 27:36Lifecycle and team coordination
- 29:22Recommendations and testing
- 30:28Q&A
related talks
46mOperators Live in the Past: Designing Reliable Kubernetes Controllers
55mIntroduction to Kubernetes Operators
19mSimplify Kubernetes Operator Development With a Modular Design Pattern
38mTo Crd, or Not to Crd, That is the Question
32mManaging CRDs and Operators in Practice
32mMinimalist Best Practices in Kubernetes Operators
45mKubernetes Operators: Operating Cloud Native services at scale
36mThe future of CRDs in a post-cluster world
