Phased upgrades of Strimzi managed Kafka fleets
summary
Deploy two adjacent Strimzi operator versions side‑by‑side, keep one cluster‑scoped set of CRDs at the newest version, and partition which Kafka CRs each operator manages using the custom resource selector label so upgrades only roll labeled clusters. Use kustomize nameSuffix and small patches to isolate RBAC, deployments and leader leases, hand CRs between operators by changing labels, and roll back by relabeling. Caveats: only adjacent versions are tested, never delete CRDs, and handle CRD API transitions in stages.
AI-written summary · about
chapters (17)
- 0:00Strimzi fleet upgrades intro
- 1:47How Strimzi upgrades work
- 4:37Large-scale upgrade challenges
- 6:03Why phased upgrades needed
- 6:44Pause annotations limitations
- 8:08Namespace-scoped deployments drawbacks
- 9:11Custom resource selectors power
- 10:35Phased upgrades considerations
- 12:19Isolating Strimzi resources
- 13:44Kustomize multi-version setup
- 16:34Deploying dual Strimzi operators
- 17:38Rolling upgrades in practice
- 19:23CRD upgrade safety
- 20:03CRD API version changes
- 21:50Key takeaways
- 23:11Advanced resource selector use cases
- 24:33Q&A on upgrade coordination
related talks
31mSimplifying Apache Kafka on Kubernetes With Strimzi
30mFrom Running to Operating: Real-World Strimzi in Production
04mProject Lightning Talk: Strimzi – What's New and What's Next
29mBeyond the Install: Take Full Ownership of Your Strimzi Cluster
29mMastering Kafka Workload Balancing With Strimzi’s Cruise Control Integration
34mHow to Survive Managing Strimzi in an Enterprise
42mTransition to Apache Kafka on Kubernetes With Strimzi
26mProduction Grade Kafka on K8s