Apache Kafka on Kubernetes with Strimzi

Running Apache Kafka on Kubernetes with Strimzi, and who owns what

A platform team that wants Kafka managed as declarative Kubernetes resources can use the Strimzi operator, which turns Kafka cluster, topic, user, Kafka Connect and MirrorMaker definitions into custom resources that the operator reconciles. The Kafka brokers and tools still run Apache Kafka itself. Strimzi is a separate open-source project from Apache Kafka, with its own release cycle, documentation and governance, so the team should confirm which Strimzi release supports the Kafka version it plans to run before writing any manifests. Kafka's own project documentation, including the Apache Kafka downloads page, remains the source for broker behavior and supported Kafka releases.

The operator automates the lifecycle of the objects it manages: creating brokers and controllers in KRaft mode, applying topic and user definitions, and rolling changes through the cluster. It does not decide how many partitions a topic needs, how long data is retained, which listeners are exposed to which networks, or how many replicas and failure domains the cluster spans. Those remain design decisions for your team, and they belong in the plan before the first Kafka resource is applied. The operator also does not provide backups of topic data, cross-site recovery or capacity planning. Mirroring to a second site is a separate design, and the reader should confirm how MirrorMaker resources are configured against the Kafka geo-replication guidance rather than assuming the operator handles failover.

Ownership is split in practice. The platform team owns the Kubernetes layer, including node pools, storage classes, network policy, certificate issuance and the operator's upgrade path. The Kafka owners own topic design, ACLs, quotas and consumer behavior. Security owns the listener and authentication choices. Write this split down as a responsibility matrix before go-live, and list which operator upgrades, Kafka version changes and Kubernetes version changes each team must approve. Kubernetes version support is limited to a short window, so the upgrade calendar for the cluster and the operator should be planned together.

What you need before installing Strimzi

Strimzi runs Kafka as Kubernetes resources, so the cluster, its storage, its certificates and its network paths have to be settled before the operator is installed. Each card below names one of those inputs and the check to make before any custom resource is applied.

A conformant Kubernetes cluster

Strimzi needs a Kubernetes cluster you already operate, with the control plane, nodes and networking in place. Confirm the cluster version against the Strimzi documentation, since the operator supports a range of Kubernetes releases. Check that the Kubernetes version is still within the project's support window, because the upstream project maintains only its three most recent minor releases. Pick a cluster that runs on your own infrastructure and is kept up to date on a planned schedule.

Kafka version on KRaft only

Plan the Kafka version around KRaft, because ZooKeeper mode has been removed in Kafka 4.0 and later. Any ZooKeeper-based cluster must migrate to KRaft before it moves to 4.x. The supported Kafka releases are listed on the downloads page, so pick one of them and confirm that the Strimzi release you choose supports that exact Kafka version. Brokers and Kafka Connect need Java 17 when running 4.x.

Persistent storage classes

Kafka brokers keep their log segments on disk, so each broker needs a persistent volume that survives pod rescheduling. Identify the storage class that your cluster will use, confirm its performance and its reclaim policy, and decide how volumes are resized later. Ask your storage team whether volumes are replicated at the storage layer, because that changes how you reason about Kafka's own replication factor.

Certificate and identity sources

Decide where the certificate authority for listener TLS will come from before you define any listener. Strimzi can generate cluster certificates, but you must decide whether your organization's internal CA signs them and how rotation is handled. Also decide which identity source will back client authentication, such as SCRAM credentials, Kerberos or OAuth tokens from an identity provider you run. Write these choices down, since changing them later affects every client.

Network paths for clients and replication

Map every network path before installation: clients inside the cluster, clients outside it, and the route used for cross-site replication with MirrorMaker 2. Decide whether external listeners will use load balancers, node ports or an ingress layer that your platform team already runs. Confirm firewall rules for the Kafka listener ports and for the replication link between sites, because MirrorMaker 2 needs a reachable path to both clusters.

GitOps and operator ownership

Decide who owns the Strimzi operator, the Kafka custom resources and the topic and user resources before the first install. Store these manifests in a Git repository that your platform team controls, and agree on which pipeline applies them. Confirm the namespace layout and the role-based access that lets application teams request topics without granting them cluster-wide rights.

How to build the Strimzi deployment in sequence

This sequence takes an empty Kubernetes namespace to a KRaft Kafka cluster with secured listeners, declared topics and users, Connect and MirrorMaker 2 running from the same manifests, and GitOps delivery that reconciles them. Each step closes with a check you can run before moving on.

Install the Strimzi operator into the cluster
A platform engineer installs the Strimzi operator into a dedicated namespace, typically with the Helm chart or the release bundle, and confirms that the Strimzi custom resource definitions for Kafka, KafkaNodePool, KafkaTopic, KafkaUser, KafkaConnect and KafkaMirrorMaker2 exist. Confirm the operator version against the Strimzi compatibility matrix for your Kubernetes and Kafka targets before you install, since operator and Kafka versions are paired. The step is done when the operator pod is running and its logs show no reconciliation errors. Check: kubectl get crd | grep strimzi lists the expected resources and kubectl get pods -n strimzi shows the operator in Running state.
Define the KRaft cluster and node pools
Write a Kafka custom resource with KRaft enabled, no ZooKeeper section, and one or more KafkaNodePool resources that assign the controller and broker roles. Keep controller nodes separate from broker nodes where your sizing calls for it, and set storage, replica counts and the Kafka version explicitly. Set the replication and minimum in-sync replica settings to match the number of brokers you plan to run, not the defaults. The step is done when the operator reports the cluster as ready. Check: kubectl get kafka -n kafka shows the cluster Ready condition, and kubectl get pods lists every controller and broker pod as Running and ready.
Configure listeners and TLS on the cluster
Declare each listener in the Kafka resource with its intended audience: an internal listener for pods in the cluster and, if needed, an external listener through an ingress, load balancer or node port. Choose TLS and a SASL mechanism per listener, such as SCRAM-SHA-512 for workloads that authenticate with passwords, or OAUTHBEARER when you have an OIDC provider. Avoid leaving a plaintext listener open to clients you do not control. Confirm the authorization block uses the Kafka ACL authorizer that stores ACLs in the metadata log and that unmatched resources are denied by default. The step is done when every listener reports a bootstrap address. Check: kubectl get kafka -o yaml shows listener status addresses for each declared listener.
Declare topics and users as custom resources
Create KafkaTopic resources with partition count, replication factor and retention settings taken from your sizing plan, and KafkaUser resources with the authentication type and ACLs each application needs. Give each user the narrowest set of topic and consumer group permissions. Store generated user secrets in your secret management path and do not commit them to the Git repository. The step is done when the topic and user operators have reconciled both resource types. Check: kubectl get kafkatopic and kubectl get kafkauser show Ready, and running kubectl exec into a broker pod with kafka-topics.sh --describe shows the expected partition count, replicas and configuration.
Run a test produce and consume with an authenticated user
Using a KafkaUser that has write access to a test topic and read access to a test consumer group, run a producer and a consumer from a pod on the same cluster with the listener, TLS and SASL settings that the application will use. Confirm the consumer receives the message and that the same user is denied on a topic it has no ACL for. This check proves the authentication path and authorization rules together, which the earlier readiness checks do not. The step is done when the authorized exchange succeeds and the unauthorized attempt fails with an authorization error. Record the commands and output in the change record so the test can be repeated after upgrades.
Add Kafka Connect and MirrorMaker 2
Create a KafkaConnect resource that points at the cluster, with the connector plugins you have approved and their own TLS and SASL credentials, then create KafkaMirrorMaker2 resources for any cross-cluster replication. MirrorMaker 2 is built on Kafka Connect, so the same credential and listener design applies to both. Set replication policy and topic and group filters explicitly. Plan who owns connector configuration, since Connect and MirrorMaker resources are often the most frequently changed part of the platform. The step is done when the Connect REST service and the MirrorMaker 2 connectors report running. Check: kubectl get kafkaconnect and kubectl get kafkamirrormaker2 show Ready, and kubectl get kafkaconnector shows the connectors in RUNNING state.
Wire GitOps delivery and reconcile from the repository
Store every custom resource in a Git repository organized by environment, then connect a GitOps controller such as Argo CD to that repository so that the cluster is reconciled from it. Keep credentials out of the repository by using an external secret store or sealed secrets. Require review on changes to listeners, ACLs and retention, because those changes affect who can reach data and how long it is kept. The step is done when a test change to a non-sensitive setting, such as a topic retention value, is applied by the controller and visible in kubectl describe kafkatopic, and a manual drift in the cluster is reverted. Confirm the sync status before any production change.

Choosing listener security options in Strimzi

Internal listeners carry traffic between brokers and controllers, and between the cluster and the components that run inside it. Only workloads in the same cluster should reach them, so the main decisions here concern keeping these ports off any path that users or external systems can use. Kafka's security overview treats encryption and authentication as optional settings that can differ per listener, so a cluster can mix secured and unsecured listeners. Use that flexibility deliberately, and be able to justify any internal listener that runs without TLS.

Who can connect: Brokers, controllers and operator-managed components, plus any workload that network policy admits. Network policy, not the listener itself, usually limits that set.
Certificate handling: Confirm how Strimzi issues and rotates inter-broker and controller certificates in your version, and who controls the cluster certificate authority key.
Encryption settings: Confirm which internal listener TLS and client authentication options Strimzi exposes, and whether controller traffic is encrypted by default in your release.
Authorization: Internal listeners still rely on Kafka's authorization decisions for any client identity that connects through them.

Check that network policies restrict each internal listener port to the pods that need it, and record every internal listener that runs without TLS along with the reason.

How GitOps changes topic and user ownership

Keeping Strimzi resources such as Kafka, KafkaTopic and KafkaUser in Git means every change to a broker setting, a topic's partition count or a principal's ACLs goes through a reviewed commit that can be reverted. That is the main gain. The main risk is that the operator and the repository can disagree. If someone runs kubectl edit on a KafkaTopic during an incident, the live object and the manifest diverge, and the next sync either reverts a fix or silently keeps an unreviewed change. Decide up front whether your GitOps controller will self-heal drift, and make sure the on-call team knows which setting is in force before they touch a live resource. The ownership split is the design decision that matters most. Platform engineers should own the Kafka cluster resource, node pools, listeners, authorization configuration and the cluster-wide defaults that determine security. Application teams should own their KafkaTopic and KafkaUser resources in their own namespaces or repositories, within limits the platform sets through admission policy or repository review. Write down which fields a team may change (retention, partitions, replication settings within agreed bounds) and which require a platform review, such as listener changes, superuser creation or ACL scope.

Secrets need separate handling. Kubernetes stores Secrets unencrypted in etcd by default, so encryption at rest for the etcd datastore, restricted list and watch RBAC, and a plan for external stores through the Secrets Store CSI Driver all need to be settled before the first user credential is generated. Strimzi-generated user secrets must not be copied into Git, and the repository must not hold client passwords or TLS private keys in plain form. Confirm with your platform team whether an external secret manager or sealed-secret approach fits your controls, and confirm how Git history will be cleaned if a secret is committed by mistake, since reverting the file does not remove it from history.

Security controls for Kafka on Kubernetes

Running Kafka on Kubernetes with Strimzi moves security into three places at once: the Kafka listeners and identities, the Kubernetes API that edits them, and the cluster's own storage and pod configuration. The cards below take one control each and say what to verify in your own environment before go-live.

TLS on Kafka listeners

Each Strimzi listener can be configured with TLS, and the choice of which listeners carry encryption is a design decision you should record per audience. Internal listeners used by brokers and clients inside the cluster and external listeners exposed through routes, load balancers or node ports need separate review. Verify that no plaintext listener is reachable from networks outside the cluster, and confirm how certificates are issued, rotated and trusted by clients.

SASL users as Kubernetes resources

Strimzi manages Kafka users as custom resources, so authentication credentials can be declared, versioned and reviewed like other cluster configuration. Confirm which SASL mechanism each listener accepts, such as SCRAM-SHA-512 or OAUTHBEARER, and that generated passwords are stored in Kubernetes Secrets rather than in Git. Check who can read those Secrets, since a readable credential Secret is a direct path to producing or consuming data.

Kafka ACLs in the metadata log

In KRaft clusters the StandardAuthorizer keeps ACLs in the cluster metadata log, and any resource without an ACL is restricted to super users unless allow.everyone.if.no.acl.found is set to true. Keep that default and grant access per principal, topic and consumer group, so a new topic is closed until someone opens it. Verify that the setting is not changed in the broker configuration and that ACL changes are reviewed as carefully as user changes.

Kubernetes RBAC for Kafka resources

Anyone who can edit a Kafka, KafkaTopic or KafkaUser resource can change listeners, create topics or grant access, even without Kafka credentials. Limit create, update and patch rights on these custom resources to the platform team, and give application teams read access or a request path through GitOps. Verify the bindings with a regular review, and confirm that the operator's own service account has only the permissions it needs.

etcd encryption at rest

Kubernetes Secrets, including the credentials Strimzi generates, are stored unencrypted in etcd by default. Configure encryption at rest for the API server, restrict list and watch access to Secrets with least-privilege RBAC, or source credentials from an external store through the Secrets Store CSI Driver. Verify that encryption is active on the control plane you run, and that etcd backups are encrypted as well.

Pod Security Standards and CIS review

Broker pods, the operator and Connect or MirrorMaker workloads should run under the restricted Pod Security Standard where the workload allows it, with no privileged containers and restricted volume use. Use the CIS Kubernetes Benchmark as a reference checklist for the cluster itself, mapping each result to an owner and a decision. Verify with a scan on a staging cluster and record any deviation the Kafka workload needs.

Mapping Kubernetes resources to Kafka objects

This table maps each Strimzi custom resource to the Kafka object it manages, the team usually responsible for it, and the field that needs review before it reaches production. Use it as a checklist when splitting ownership between platform and data teams. Confirm exact field names against the Strimzi version you deploy, since the API evolves between releases.

Custom resource	Kafka object it manages	Owner and field to review
Kafka	The Kafka cluster: listeners, authentication, authorization and broker configuration	Platform team. Review listeners and their TLS and authentication settings before any client connects.
KafkaNodePool	Broker and controller node groups, including roles, replica counts and storage	Platform team. Review roles and storage, because volume settings are hard to change after data exists.
KafkaTopic	A Kafka topic with its partition count, replication factor and topic configuration	Data or application team, approved by platform. Review partitions, replication factor and retention.msor equivalent retention settings.
KafkaUser	A Kafka principal, its authentication credentials and its ACL authorizations	Application owner, approved by platform. Review the authentication type and the ACL list for least privilege.
KafkaConnect	A Kafka Connect cluster that runs connectors, including its workers and plugins	Data platform team. Review the plugin images and the connector configuration storage topics.
KafkaConnector	A single connector instance running on a Kafka Connect cluster	Pipeline owner. Review connector class, task count and the topics it reads or writes.
KafkaMirrorMaker2	A MirrorMaker 2 deployment that replicates topics and consumer offsets between clusters	Platform team with the disaster recovery owner. Review source and target cluster aliases, topic patterns and replication direction.

What the Strimzi operator does not take off your hands

Strimzi reconciles Kafka clusters, topics, users, Connect and MirrorMaker from custom resources, but it does not decide how much capacity you need, how long data should be kept, or where failover happens. The platform team still owns partition counts and capacity planning, which determine broker sizing, and retention decisions per topic, which determine how much storage the cluster consumes and how long consumers can replay history. Confirm these with the teams that produce and consume the data before the first topic custom resource is applied, because changing partition counts later affects key ordering for existing consumers. Storage performance is also yours to verify: the persistent volumes behind the brokers need sustained write throughput and fsync behavior that the operator cannot test for you.

The Kubernetes control plane stays outside the operator's scope. Your team must run etcd backups with a tested restore procedure, plan control plane upgrades that respect the Kubernetes version skew policy, and monitor node and kubelet health. A failed etcd restore can take the Strimzi custom resources with it, so the backup is only useful after a restore has been rehearsed. Identity provider integration is another platform task: you choose the OIDC or Kerberos setup, manage client secrets and certificate rotation, and decide which principals map to which ACLs. Monitoring of brokers, consumer lag, and operator health is also yours to build, including alert routing.

Cross-site failover design remains a platform decision. Strimzi can deploy MirrorMaker 2 as a custom resource, but choosing the replication topology, the failover runbook, and how consumer offsets are translated after a switch is your responsibility. Kafka version upgrades are the most time-sensitive item. The Kafka release plan supports rolling upgrades from each of the last three releases to the latest version, so a cluster on an older release must be stepped forward through supported versions rather than jumped. Check the current Kafka upgrade notes for your starting version and the Java runtime each release requires before changing the version field in the Kafka resource. Plan the upgrade window, test it in a non-production cluster, and confirm the operator release supports your target Kafka version.

Common Strimzi failures and how to fix them

This table lists the failures teams most often hit when running Kafka with Strimzi, with the likely cause and the first fix to try for each. Read it as a triage order: check the operator and Kafka versions first, then certificates, then resource and access problems. Most of these failures trace back to a mismatch between what the Kafka custom resources declare and what the operator or a client actually expects.

Failure	Likely cause	First fix to try
Operator and Kafka version mismatch	The Strimzi operator does not support the Kafka version set in the Kafka resource, or the operator was upgraded without planning the Kafka upgrade path	Compare the operator release notes with the Kafka version in the cluster spec, then align them before changing anything else
Certificates expired or not trusted by clients	Cluster CA or client certificates reached expiry, or clients still hold the old CA after renewal	Check certificate validity in the cluster secrets, then distribute the current CA certificate to clients and restart them
Topic rejected or left unmanaged	KafkaTopic resource missing the cluster label, partition or replication settings outside broker limits, or topic operator disabled	Confirm the strimzi.io/cluster label matches the Kafka resource name, then read the KafkaTopic status conditions for the reason
ACL denials after enabling authorization	Authorization turned on without ACLs for existing clients, or KafkaUser authorization block missing the needed operations on topics and groups	Review the KafkaUser authorization rules, add read on the consumer group and describe on topics, then retry the client
GitOps drift overwriting operator-managed fields	Git manifests set fields the operator also manages, such as replicas, listeners or the entity operator, so sync reverts operator changes	Limit the managed fields in Git, use ignore rules for operator-owned fields in the sync tool, and reconcile one resource at a time
Connect or MirrorMaker tasks failing on credentials	Secret referenced by the KafkaConnect or KafkaMirrorMaker2 resource was renamed, rotated without a restart, or lacks the needed user or certificate keys	Verify the referenced secret name and keys, then check the connector task status and restart the affected connector or task after correction
Broker pods stuck or restarting	Insufficient storage, resource limits below JVM needs, or a persistent volume that cannot be attached in the target zone	Describe the pod events and the Kafka status, then correct storage class, memory limits or volume zone before retrying

Questions buyers ask before running Strimzi

Can our team run Kafka on Kubernetes with Strimzi without outside help?

Yes, many teams can, provided they already operate Kubernetes well and have engineers who understand Kafka's storage, replication and security model. The operator automates cluster, topic and user resources, but it does not replace that knowledge. Ask yourself whether you have owners for broker sizing, partition planning, certificate rotation and upgrades, and whether those people have time for a first build and for the first upgrade cycle. A partner is most useful where those skills or hours are missing, or where a fixed-scope build and handover is preferred over learning on production traffic.

What makes a Strimzi engagement take more or less effort?

Effort follows the number of clusters, how many listeners are exposed outside the cluster, how identity is integrated, and how mature your GitOps practice is. Each additional cluster multiplies configuration, monitoring and upgrade work. External listeners add network design, TLS and access testing. Identity integration, whether through SASL mechanisms, OAuth or your existing directory, adds design decisions and client changes. Teams with established GitOps pipelines need less custom tooling than teams starting from manual deployments. Ask for each of these factors to be listed separately in the written scope so the quote can be compared across options.

How long does a Strimzi implementation take?

No duration can be stated without a written scope, because the schedule depends on the cluster count, listener design, identity integration, the number of Connect or MirrorMaker deployments and the state of your Kubernetes platform. Fixed-scope engagements agree deliverables and timelines in writing before work starts. Ask for a phased plan that separates platform readiness checks, a non-production build, security validation, a production cutover and handover. Ask which items depend on your teams, such as network approvals, identity provider changes or change-board reviews, since those often set the critical path more than the Kafka work itself.

What does the work need from our Kubernetes and security teams?

Your Kubernetes team needs to provide cluster access, namespace and node pool decisions, storage classes suitable for Kafka, network policies and the load balancer or ingress approach for external listeners. Your security team needs to approve the TLS certificate authority model, the authentication mechanism for clients, the authorization model and how secrets are stored. Kubernetes stores Secrets unencrypted in etcd by default, so confirm encryption at rest and least-privilege RBAC for Kafka namespaces. Plan these reviews early, because changes to listeners, identity or secrets handling usually require sign-off outside the project team.

Are Strimzi and Apache Kafka free to use under their licenses?

Apache Kafka is an Apache Software Foundation project released under the Apache License 2.0, and the project itself offers no paid edition. Kubernetes is also open source under Apache 2.0. Confirm the license of the Strimzi operator and its images in its own repository before you commit, and check the terms of any container images, base images or add-ons you choose. Licensing is only one cost line. Your bill will still include infrastructure, staff time, implementation work and ongoing support, so request a quote from a written scope to compare those costs fairly.

What recurs after go-live, and what is one-time work?

The build is largely one-time work: architecture, initial deployment, listener and identity setup, GitOps repository structure and handover. Recurring work includes Kafka and operator upgrades, Kubernetes upgrades that must respect the version skew policy, certificate rotation, topic and user changes, capacity reviews, backup and restore testing, and monitoring of brokers and consumers. Kubernetes releases roughly three times a year, so plan for regular platform change. Decide before go-live whether your team will own this work, or whether a retainer for support and upgrades is better suited to your operating model.

Does the operator remove all day-two Kafka operations?

No. Strimzi automates many declarative tasks, but it does not decide partition counts, retention periods, consumer behavior or application-level delivery guarantees. Your team still needs to interpret broker metrics, handle consumer lag, plan capacity, validate restores and approve upgrade sequences. Kafka upgrades must follow the upgrade notes, and rolling upgrades are supported from the last three releases to the latest. Confirm the exact operator and Kafka version pairing with the Strimzi documentation before any change.

How DeployOpen scopes and supports a Strimzi deployment

DeployOpen scopes a Strimzi deployment as a fixed-scope engagement, with the scope, deliverables and timelines agreed in writing before any work starts. For a Kafka-on-Kubernetes project, that written scope should name the clusters and namespaces involved, the Kafka version and KRaft mode setup, the node pools and storage classes, which Strimzi custom resources will be delivered (Kafka, KafkaNodePool, KafkaTopic, KafkaUser and, where needed, KafkaConnect and KafkaMirrorMaker2), the listener and authentication design, and the GitOps repository layout. Each of these is a decision the client has to make or confirm before the build begins, so the scope document is where those decisions get recorded.

All work is carried out inside the client's own Kubernetes clusters, whether those run in their cloud accounts, data centers or restricted networks. DeployOpen does not host the cluster or hold the client's broker data, and the scope should state who holds cluster-admin access, who owns the operator installation and which container registry and Git repositories the images and manifests come from. Documentation and handover are part of the agreed deliverables: runbooks for topic and user changes, upgrade steps for the Strimzi operator and Kafka versions, and the operational work the operator does not perform for you. Ask for the handover acceptance criteria in writing so that the client's platform team knows when ownership has passed.

Ongoing work is available as an optional retainer covering Strimzi and Kafka upgrades, support and periodic review of listener and access configuration. A retainer is recurring, while the initial build is one-time, and the recurring part is priced from the agreed scope of support. DeployOpen does not publish a price list. A quote follows from the written scope, so bring your cluster count, environments, compliance obligations and expected change volume to the first conversation and ask for the quote to separate one-time build effort from recurring support.