How to run Apache Kafka across multiple Kubernetes clusters

Updated November 2026: We have rewritten this guide into a question-led format and checked the Strimzi status against the project’s current releases. Stretch cluster support is still not part of a released Strimzi operator, so treat the approach below as an advanced pattern that needs your own validation.

A single Kafka cluster inside one Kubernetes cluster still has a single point of failure: the Kubernetes cluster itself. A control plane outage, a bad upgrade or the loss of a region takes every broker down together. Running Kafka across multiple Kubernetes clusters, sometimes called a Kafka multi region cluster when the sites are in different regions, is one way to remove that risk.

This guide explains why teams consider it, which problems you have to solve, how a Strimzi-based design addresses them, and what to check before you rely on it. For the wider picture of running Kafka on Kubernetes, see our Strimzi Kafka operator guide.

Why run Kafka on Kubernetes at all?

Kubernetes gives Kafka declarative configuration, automated rescheduling and repeatable scaling, but Kafka is stateful, so it needs more than a plain deployment.

Kafka brokers need persistent storage, coordinated scaling, careful failure detection and controlled rolling updates. A Kubernetes operator handles that work in software: it watches broker health, rolls changes out one broker at a time and keeps configuration consistent. Strimzi is the open-source operator most teams reach for.

What problems do you solve when Kafka spans Kubernetes clusters?

Spanning clusters is not just deploying more brokers in more places. Four problems have to be solved together.

Key takeaway: Multi-cluster Kafka only works when networking, controller quorum placement and security are designed together, not added one at a time.

How does Strimzi help run Kafka across clusters?

Strimzi describes brokers and controllers declaratively, which makes it a natural base for a stretched design.

Two Strimzi features matter most. Kafka node pools let you define groups of Kafka nodes independently, each with its own role, storage and placement. StrimziPodSet resources control how those pods are created inside each Kubernetes cluster. Combined, they let one set of definitions place brokers and controllers in several clusters while Kafka sees a single logical cluster.

Be clear about the current status. As of November 2026, stretch cluster support is not part of a released Strimzi operator. A community prototype exists, and a working three-cluster demonstration has been published, but it is experimental and has not been adopted into the main operator. If you need this in production today, plan to validate the design yourself or work with engineers who have done it.

How do you connect the Kubernetes clusters?

You connect them with a cross-cluster networking layer so that pods in one cluster can reach pods in another by stable names.

Submariner creates secure tunnels between clusters and supports the Multi-Cluster Services API. Cilium Cluster Mesh offers eBPF-based connectivity with visibility and policy control. Either can provide the service discovery that brokers need.

Two Kafka settings then have to describe the distributed topology correctly:

• Controller quorum voters: list controllers from several clusters so the quorum survives the loss of any one of them.
• Advertised listeners: give each broker an address that clients and other brokers can resolve across clusters, with TLS certificates that cover those names.

What happens when one Kubernetes cluster fails?

If the design is right, Kafka keeps running on the remaining clusters, because brokers and controllers are not concentrated in one place.

With three clusters and controllers spread across them, losing one cluster leaves a controller majority, so a new leader can be elected and partitions with replicas elsewhere stay available. Set min.insync.replicas and replication factor so that every partition has in-sync replicas in more than one cluster. With only two clusters you cannot keep a controller majority after losing one, which is why three failure domains is the practical minimum.

One caveat: in a Strimzi-style setup, one cluster runs the full operator and the others reconcile only their pod sets. Know how you would recover that central operator, and rehearse it.

How does this compare with MirrorMaker replication?

Stretching one cluster and replicating between separate clusters solve different problems, and the choice depends on latency and recovery goals.

Teams with strict recovery point targets and low-latency links lean towards a stretched cluster. Teams spread across distant regions usually replicate between clusters instead.

How do you test a multi-cluster Kafka design?

Test performance and failure before production, because the failure modes only show up under load.

1. Benchmark with a tool such as the Open Messaging Benchmark and compare against a single-cluster baseline to see the latency cost of crossing clusters.
2. Terminate every pod in one cluster at once and confirm producers and consumers carry on.
3. Watch cross-cluster network metrics, controller election time and operator logs.
4. Rehearse restoring the central operator and re-joining a recovered cluster.

Who needs Kafka across multiple Kubernetes clusters?

Teams with strict availability targets and regulated industries are the main candidates.

Finance, healthcare and telecoms often have data sovereignty rules that keep some workloads on premises. A multi-cluster or hybrid layout can give them resilience across sites without moving everything to one cloud. If you are weighing this against a hosted option, our guide to best managed Kafka services compares the alternatives, and our Kafka services and Kafka support teams can help you design and run it.

Frequently asked questions