Anti-patterns for Kubernetes Operators
summary
OpenShift moves core components into 40+ operators and reports concrete lessons: build an start small MVP that first installs the app, then watches for config changes, then upgrades and backups; expose only app‑specific fields instead of the full podTemplate to hide Kubernetes complexity; avoid assuming custom node types or storage classes exist and rely on cluster defaults, letting admins supply restrictions; and separate admin and machine config so controllers never fight over the same fields.
AI-written summary · about
chapters (7)
- 0:00Start
- 0:34deploy and manage your application on kubernetes
- 5:11install your application on kubernetes
- 7:47migrating over from our historical cluster topology to the new
- 8:26rely on the clusters
- 11:43define all the storage classes
- 13:11separate the parts of the configuration
related talks
20mLessons Learned Using the Operator Pattern to Build a Kubernetes Platform
32mMinimalist Best Practices in Kubernetes Operators
43mLessons learned writing 10+ Kubernetes Operators
36mLessons learned writing 10+ Kubernetes Operators - Lars Francke and Jannik Heyl
32mMinimalist Best Practices in Kubernetes Operators
36mEssential Patterns For Designing And Implementing Your Operator
39mKubernetes Operators: Managing Complex Software with Software
45mHyper-Automate your Cloud Native Journey
