Exploring Strimzi’s Implementation of Rolling Updates
summary
Strimzi uses KafkaRoller to coordinate rolling restarts by reading Kafka metrics, Admin API and Kubernetes API, running reconciliation every 2 minutes (configurable), and deleting pods with kubectl then waiting for readiness. Default timeouts include operation timeout 5 minutes and maxAttempts = 10 for log recovery. Current roller restarts one broker at a time (slow for clusters of hundreds), checks ISR and quorum to avoid data loss, and has a proof‑of‑concept Roller 2.0 that supports parallel broker restarts when partitions don’t overlap.
AI-written summary · about
chapters (13)
- 0:00Strimzi rolling updates intro
- 1:07Triggers for Kafka updates
- 3:40Kafka Roller coordination
- 6:27Pod readiness in Strimzi
- 8:19Handling unready pods
- 13:36Triggers for pod restarts
- 15:03Safety checks before restart
- 18:36Rolling update process
- 21:25Step-by-step example
- 25:36Kafka Roller shortcomings
- 28:04Kafka Roller 2.0
- 31:39Summary
- 31:59Q&A
related talks
30mFrom Running to Operating: Real-World Strimzi in Production
31mSimplifying Apache Kafka on Kubernetes With Strimzi
33mManaging a Kafka cluster in KRaft mode with Strimzi
32mStretching Strimzi: Exploring Multi-Cluster Kafka for High Availability
29mMastering Kafka Workload Balancing With Strimzi’s Cruise Control Integration
28mPhased upgrades of Strimzi managed Kafka fleets
21mKeynote: Strimzi past, present and future
04mProject Lightning Talk: Strimzi – What's New and What's Next