From the dream of one perfect cluster to the messy truth of enterprise sprawl
This episode is part of the Azure Kubernetes Chronicles: Multi-Cluster Edition.
Read the series introduction here.
When Kubernetes first entered the enterprise, many platform teams envisioned a single, perfect cluster; a hub where all workloads could reside, scale smoothly, and be governed consistently. The reality turned out very different.
Today, almost no enterprise runs just one cluster. Instead, organizations find themselves managing multiple clusters scattered across regions, cloud providers, and even edge sites. This isn’t random chaos; it’s the result of regulatory demands, business continuity strategies, performance requirements, and the rise of edge computing.
In Europe, in particular, directives such as NIS2 and DORA are reshaping IT strategy. Compliance frameworks now demand resilience, redundancy, and independence from single providers. At the same time, performance expectations, mergers and acquisitions, and operational realities pull enterprises toward a multi-cluster future.
Why Multi-Cluster Kubernetes Matters
At first glance, a single, enterprise-wide Kubernetes cluster appears more straightforward: one control plane, one set of policies, and one monitoring stack. But at scale, that ideal breaks down. Instead, organizations discover that multi-cluster is not a luxury; it is a necessity.
Regulatory compliance is the first and most obvious driver. In the EU, financial institutions and critical infrastructure providers are being forced to demonstrate that their workloads can survive a regional or provider-level outage. A European bank might run its primary workloads on Azure Kubernetes Service in West Europe but operate a secondary cluster in AWS Frankfurt to prove resilience and regulatory independence. Compliance demands have transformed what once looked like an architectural choice into a non-negotiable requirement.
Business continuity and disaster recovery provide an additional boost. Outages in hyperscaler regions are rare, but they do happen. When they do, relying on a single cluster within a single geography can leave an organization exposed to costly downtime. Distributing clusters across regions and providers turns resilience into a built-in feature rather than a bolt-on solution.
Performance considerations also drive multi-cluster adoption. Enterprises serving global users know that latency is critical. Workloads serving customers in Asia-Pacific often perform better when hosted in Singapore on AWS, while European workloads typically run more efficiently from Azure regions in Amsterdam or Dublin. By hosting clusters closer to users, organizations improve responsiveness and provide a smoother customer experience.
Mergers and acquisitions further complicate the picture. When one company buys another, its Kubernetes clusters do not merge overnight. Enterprises may operate with a patchwork of AKS, EKS, and even on-prem clusters for years. Consolidation is rarely simple, and in the meantime, the multi-cluster state becomes the de facto reality.
Some organizations also adopt multi-cluster strategies by design, utilizing them as a means to separate concerns and responsibilities. Development, testing, staging, and production environments often run in distinct clusters to reduce risk and maintain control. Others separate clusters by business unit or geography, ensuring that failures or compliance exceptions remain isolated within their respective areas. What may appear to be duplication is often a deliberate risk management strategy.
Finally, there is the edge. Not all workloads can run in the cloud. Retail stores, hospitals, and manufacturing sites often require systems that continue to function even if the internet connection is lost. Lightweight Kubernetes distributions such as k3s make it possible to run local clusters on devices as small as a Raspberry Pi or as compact as an Intel NUC. In practice, a retail chain may have hundreds of small but critical clusters that keep point-of-sale systems online or run AI models for queue management. Factories use them for machine telemetry and predictive maintenance, while hospitals process sensitive imaging data locally to comply with privacy rules. These clusters are small but strategically vital, and they significantly contribute to the overall cluster count.
The Risks of Cluster Sprawl
The benefits of multi-cluster Kubernetes are apparent, but the risks are just as real. Identity is often the first fracture point. Azure clusters integrate seamlessly with Entra ID, AWS clusters with IAM, and edge clusters with local certificates. The result is a fragmented identity model that makes consistent access control challenging. Policies begin to drift as different clusters enforce different pod security standards, admission controllers, or OPA rules. Compliance teams eventually notice the gaps. Networking complexity soon follows, with each environment relying on different CNIs and service discovery methods, resulting in unreliable cross-cluster communication. Observability suffers too, as Azure Monitor, AWS CloudWatch, and self-managed Prometheus stacks rarely share a common language. To make matters worse, costs escalate quickly because every cluster brings its own control plane, node pools, ingress controllers, and monitoring agents. Without disciplined FinOps practices, a multi-cluster environment can spiral into multiple costs.
Cluster sprawl
Governance Pressure
For enterprise architects, the key question is no longer whether a multi-cluster approach is needed, but how it can be governed effectively. Boards and regulators expect organizations to demonstrate consistent security and compliance across all environments, to produce disaster recovery playbooks that prove workloads can fail over successfully, to provide audit trails for NIS2, DORA, and GDPR, and to show that costs are under control. The pressure to deliver governance at scale is why solutions such as Azure Fleet, Azure Arc, Google Anthos, and open-source service meshes are becoming essential elements of enterprise Kubernetes strategies.
Closing Thought: Multi-Cluster is the Enterprise Reality
No CIO begins a cloud journey by declaring an intention to run three types of Kubernetes clusters across two providers and hundreds of edge sites. Yet that is precisely where most enterprises arrive. They don’t get there by choice, but by necessity. Multi-cluster Kubernetes is the messy truth of enterprise sprawl — and also the foundation of resilience, compliance, and edge innovation.
Next up: Azure Kubernetes Chronicles 8: Fleet in Focus