On stretched Kubernetes clusters

 November 2, 2026

During conversations at work, and outside it, Kubernetes high availability comes up. And every time that happens, the idea of stretched clusters comes up. The idea is appealing, since stretching clusters across multiple data centers ensures that even if one is lost, Kubernetes keeps running and takes the necessary actions to restore services in the surviving sites. On the surface, it seems like the Holy Grail of HA, since it is simple and highly effective. In practice, this is often not the best setup.

First, there is an obvious aspect of how etcd, the database behind the Kubernetes control plane, works. Etcd uses the Raft consensus algorithm, which needs a majority of members to be online and able to communicate to elect a leader and keep the cluster writable, which is needed to schedule new pods and perform many other operations. I wrote about why control planes use an odd number of members, and the same logic applies here, obviously. To survive the loss of one data center, you need at least three failure domains to be able to lose one and still have your cluster fully functioning. You could also use a 2+1 topology with two data centers and a third site hosting just an etcd member. This preserves quorum after the loss of one site, but losing a data center may still reduce workload capacity and require workload recovery elsewhere. If you have only two sites, you either run only two etcd nodes or run three etcd nodes, with two in one data center. The first design is problematic, since a network partition or one data center going down will force all surviving etcd to read-only mode to avoid split-brain. The latter is equally problematic, since losing the data center with two etcd will immediately make the whole cluster read-only. Multiple organizations have solved those issues, but without enough data centers, there’s no reliable way to run a true active/active cluster. Another key point is that etcd requires the majority of nodes to acknowledge a change before committing it, which means the latency between data centers must be as low as possible for a performant cluster. So, those things are important to remember and explain why, if you choose a stretch cluster approach, it’s critical to design it properly.

In most cases, a good design still doesn’t solve the biggest challenge the stretch-cluster idea tries to address. The goal of a stretch cluster is to enable high availability without adding extra components or multiple clusters. The issue, though, is that in the majority of cases, having multiple clusters and therefore also a tool to orchestrate workloads on them is unavoidable. Once you have those elements in place, the advantage of stretch clusters is less evident, while the design complexity (three failure domains with low latency) persists. Organizations need multiple clusters for various reasons, usually due to scale, failure domains, data regulations, proximity to users, or to segregate dev, test, and production environments. Usually, organizations end up with multiple of those requirements, and the number of clusters can quickly multiply. Once the organization develops ways to manage tens of clusters, managing a few more adds relatively little cost.

Once an organization has multiple clusters, you will need a higher abstraction layer above the single cluster. Operationally, the clusters will need to be observed, backed up, upgraded, and kept compliant. From a developer perspective, workloads will need to land on the right clusters with as little effort as possible. That abstraction layer has to provide a fairly consistent set of capabilities: workload placement and deployment across clusters, unified observability, policy enforcement, traffic distribution and failover between sites, and disaster recovery coordination. These are the same capabilities that a stretched cluster promises to give you “for free”. Since you will need this higher abstraction layer for the rest of the fleet, using two different abstraction layers to achieve the same result adds unnecessary complexity.

At the end of the day, the stretch cluster and the higher abstraction layer are two different ways to solve the same problem. As discussed, since the higher abstraction layer will probably still be required, it is better to use it for all needs. But what if the higher abstraction layer isn’t really needed because all current and reasonable future requirements could be solved with a single stretch cluster? In that case, the question becomes where the complexity should live, since complexity can not magically disappear. Is it better to have fewer clusters to manage, potentially one instead of two or more, but way more complex to manage? Is it better to have a very rigid data center and connectivity layout, or to leverage a flexible data center and connectivity design? Personally, I believe it is far better to have more clusters to handle, manage them like cattle, and have the freedom to make data center decisions based on multiple business needs, instead of being forced into one specific configuration because of a technical decision.