Running Kafka requires ongoing work around brokers, configuration, certificates and version changes. Strimzi provides Kubernetes operators that manage Kafka deployments from declared resources, giving platform teams a consistent way to operate that lifecycle. It is useful when Kafka belongs in a Kubernetes environment and the team is prepared to own the service. The operator does not remove responsibility for broker storage, recovery or client compatibility; those need explicit checks alongside each supported operator and Kafka upgrade.
Separate operator and cluster upgrades
Review the supported Kafka and Kubernetes versions for the selected Strimzi release. Plan the operator change, Kafka changes, metadata and configuration transitions as distinct steps. An operator upgrade is not permission to skip supported intermediate steps for every existing Kafka cluster.
Test the data contract
Exercise producer acknowledgements, consumer offsets, authorization, certificates, partition placement and recovery after broker replacement. Confirm that monitoring detects unavailable partitions and client failures rather than only pod health. Retain backups or replication appropriate to the workload's recovery objectives.
Choose a managed Kafka service if the operating burden exceeds the team's scope; compare its network, identity and cost constraints explicitly. The operator guide explains the ownership obligations behind these controllers.
Sources & further reading
Spotted something that needs another look?
Help improve this page →