Strimzi Kafka Operator: Running Kafka on Kubernetes in Production

Teams that want Apache Kafka on Kubernetes often reach for Strimzi first. It turns brokers, controllers, topics and users into declarative custom resources, so the cluster follows the same GitOps path as the rest of the platform. That removes a lot of day-two work. It does not remove the need to understand Kafka storage, replication and upgrades.

This guide covers how the operator works, how to design storage and node pools, how upgrades and KRaft fit together, how to secure a Strimzi cluster, what fails in production and when a managed service is the better fit. Facts come from strimzi.io, the Strimzi overview and the 0.46.0 release notes, checked on 5 November 2026.

What is Strimzi and how does the operator work?

Strimzi is an open-source project that runs Apache Kafka on Kubernetes. The CNCF project page shows it was accepted to the CNCF on 28 August 2019 and moved to the Incubating maturity level on 8 February 2024. As of this writing it has not graduated.

Three operators do the work:

• Cluster Operator watches Kafka, KafkaNodePool, KafkaConnect, KafkaMirrorMaker2 and KafkaBridge resources and reconciles the underlying pods, services and certificates.
• Topic Operator manages topics from KafkaTopic custom resources.
• User Operator manages credentials and ACLs from KafkaUser custom resources.

The Topic and User operators usually run together as the Entity Operator, which the Cluster Operator deploys with the Kafka cluster. Strimzi also ships Drain Cleaner, a helper that annotates pods during a node drain so the Cluster Operator can roll them safely instead of Kubernetes killing them outright.

You describe the desired state in YAML. The Cluster Operator reconciles until reality matches. A production KRaft cluster needs both a Kafka resource (version, listeners, cluster-wide config) and one or more KafkaNodePool resources (roles, replicas, storage). Current Strimzi releases use the kafka.strimzi.io/v1 API for those resources.

The latest stable operator release on strimzi.io/downloads is 1.3.1. It supports Apache Kafka 4.2.0, 4.2.1, 4.2.2, 4.3.0, 4.3.1 and 4.3.2, and has been tested on Kubernetes 1.32 to 1.37.

For the broader Kubernetes design choices around brokers, networking and multi-cluster setups, see our guide to running Kafka on Kubernetes and the follow-up on Kafka across multiple Kubernetes clusters.

How do you design storage and node pools?

KafkaNodePool became generally available in Strimzi 0.41 and is permanently enabled. Each pool groups nodes that share a role, replica count and storage layout. Cluster-wide settings stay on the Kafka resource; anything not set on the pool is inherited from there.

In production, separate controller and broker pools. Controllers hold the KRaft metadata quorum. Brokers hold topic data. Mixing both roles on every node works for labs, but it couples controller health to broker load and makes capacity planning harder.

Storage is the decision that is hardest to undo:

Pick a storage class with the IOPS and throughput your peak produce rate needs, and size PVCs with headroom for retention plus compaction. Rack awareness usually comes from Kubernetes topology labels (for example topology.kubernetes.io/zone) mapped into Kafka’s broker.rack, so partition replicas spread across failure domains.

Cruise Control can rebalance partitions after you scale a pool or change retention. Our Cruise Control guide covers goals, anomaly detection and how Strimzi wires it in.

How do Strimzi upgrades and KRaft work?

From Strimzi 0.46.0 onwards the operator is KRaft-only. The 0.46.0 release notes removed support for ZooKeeper-based clusters, for KRaft migration and for MirrorMaker 1. You must finish any ZooKeeper-to-KRaft migration on an older Strimzi release before you upgrade to 0.46 or newer.

Upgrade order matters:

1. Upgrade the Strimzi Cluster Operator to a release that still supports your current Kafka version.
2. Upgrade the Kafka version (and metadata version where required) through the Kafka custom resource, one supported step at a time.
3. Confirm the Cluster Operator has rolled every node pool cleanly before the next jump.

Always read the release notes for the exact supported pairs before you move. Skipping a Kafka minor that Strimzi never shipped together is a common cause of stuck rolling updates.

How do you secure Kafka on Strimzi?

Strimzi encrypts traffic between its own components by default. Client access is configured per listener on the Kafka resource. Typical production listeners use TLS encryption with one of:

• mTLS (TLS client authentication), with certificates issued through KafkaUser
• SASL SCRAM-SHA-512, with passwords stored in Kubernetes Secrets managed by the User Operator
• OAuth 2.0, when you already run a central identity provider

Authorisation is usually simple ACL rules declared on the KafkaUser, or a custom authorizer when you need something beyond the built-in ACL model. The Cluster Operator renews cluster and clients CA certificates on a configurable schedule, so certificate expiry is an operator concern rather than a manual cron job — as long as you monitor the CA secrets and the operator stays healthy.

NetworkPolicy objects and private listeners keep brokers off the public internet. External access, when you need it, should terminate TLS at a load balancer or ingress that you control, with the same authentication story as internal clients. For a broader checklist that is not Strimzi-specific, see how to secure your Apache Kafka cluster.

What goes wrong with Strimzi in production?

Most Strimzi outages we see are Kafka problems expressed through Kubernetes objects, not operator bugs.

PVC full. Brokers stop accepting produces when a volume hits its limit. Watch filesystem usage and kafka_log_Log_Size style metrics per volume, and alert before retention can no longer free space.

Node drains without Drain Cleaner. A plain kubectl drain can evict a broker before its replicas are caught up. Deploy Drain Cleaner so the Cluster Operator rolls the pod and keeps under-replicated partitions under control.

Stuck rolling updates. A bad config, an unsupported Kafka version jump or a failing readiness probe leaves one pod down and the roll paused. Read the Cluster Operator logs and the Kafka resource status before you force another annotation-based roll.

Cruise Control rebalances at the wrong time. A rebalance during a deploy or a zone outage adds disk and network load when you can least afford it. Schedule rebalances, cap concurrent partition movements and pause them during incidents.

When a Strimzi platform is already fragile, an in-place upgrade can stack too many risks. For IKEA, OSO’s investigation led to a blue-green IKEA Strimzi rebuild on KRaft rather than upgrading the failing cluster in place. Hyperoptic took a different path: it kept brokers on MSK and moved connectors to Kafka Connect on Strimzi at Hyperoptic.

Key takeaway: Strimzi automates Kafka operations on Kubernetes, but it does not remove the need to understand Kafka storage, replication and upgrades.

When is Strimzi the wrong choice?

Strimzi is a strong default when your organisation already runs Kubernetes, wants Kafka as code and has (or can hire) people who understand both. It is the wrong default when those conditions are missing.

Prefer a managed service when:

• Nobody on the team owns Kafka day-two work. Disk, rebalances and upgrades still need a human, even with an operator.
• You want a vendor SLA on the brokers themselves, not only on the Kubernetes control plane.
• Your platform standard is a cloud-managed Kafka such as Amazon MSK or Confluent Cloud, and running a second operational model adds cost without leverage.
• Compliance or data residency pushes you toward a specific managed region or certification set that your self-hosted estate does not meet.

Use Strimzi when you need custom listener auth, precise storage layout, Kafka Connect and MirrorMaker 2 as first-class Kubernetes resources, or one GitOps path across clouds. Our comparison of best managed Kafka services is the place to start if you are weighing MSK, Confluent Cloud and others. If you already run Strimzi and need hands-on help, our Kafka support engineers build and support these platforms in production.

Frequently asked questions