Azure Kubernetes Chronicles 8: Fleet in Focus
Azure’s multi-cluster powerhouse — and where it falls short
This article is part of the Azure Kubernetes Chronicles: Multi-Cluster Edition.
Read the series introduction here.
When Microsoft introduced Azure Kubernetes Fleet Manager, it was met with both excitement and curiosity. For years, platform teams running multiple AKS clusters had been piecing together governance with scripts, policies, and half-baked federation approaches. Fleet arrived with the promise of simplification: a central way to govern clusters, propagate policies, and even distribute workloads across Azure regions.
For enterprises already committed to Azure, it is the missing piece. Suddenly, a native tool emerged that could provide consistency, reduce duplication, and offer a global perspective on cluster operations. The value proposition was straightforward: configure once, apply everywhere, and finally gain the kind of multi-region resilience that regulators and boards increasingly expect.
Fleet does much of this well. It enables enterprises to manage multiple AKS clusters as if they were part of a single fleet, rather than isolated islands. Governance policies can be defined once and automatically applied across clusters, eliminating the manual drift that so often plagues operations. Workloads can be scheduled with awareness of geography and health, ensuring that users are directed to the nearest or most reliable cluster. Shared resources such as ConfigMaps or Secrets can be pushed fleet-wide, bringing a level of cohesion that previously required heavy lifting from operations teams. And because Fleet integrates tightly with Azure-native services such as Entra ID, Azure Policy, and Azure Traffic Manager, it feels less like a separate product and more like an organic extension of Azure itself.
From a strategic lens, Fleet strengthens Azure’s story. For the CIO of a company running exclusively on Azure, it provides three key benefits: consistency, efficiency, and resilience. Consistency comes from the ability to unify governance across all AKS clusters. Efficiency stems from eliminating the need to configure each cluster independently. Resilience comes from native support for multi-region failover, turning complex architecture patterns into first-class capabilities. Within Azure’s walls, Fleet feels like the perfect answer to the multi-cluster challenge.
But here is where the picture becomes more complicated. Fleet today is an Azure-first, AKS-only solution. It assumes that governance occurs through Entra ID, that policies are defined through Azure Policy, and that observability is enabled through Azure Monitor. For organizations that live entirely in Azure, this alignment is powerful. For those that also run workloads on AWS EKS, GCP GKE, or at the edge with lightweight distributions like k3s, Fleet cannot extend its reach.
Consider a European retailer that operates its online platform on AKS in Amsterdam, while regulators require a backup cluster in AWS Frankfurt. At the same time, every store in its chain runs local K3S clusters on Raspberry Pi devices to keep point-of-sale systems functioning. Inside Azure, Fleet delivers order and control. Outside of Azure, it offers little visibility. The AWS cluster and the dozens of store-level clusters remain disconnected, leaving governance teams with a fragmented picture.
This limitation is not a surprise. Fleet is still a relatively young service, and Microsoft initially built it to address Azure’s internal sprawl, rather than the broader multi-cloud landscape. Compared with more established platforms such as Google Anthos, it lacks features like unified cross-cloud policy enforcement or native hybrid observability. It is less a universal tool and more a competent Azure-native solution.
For enterprises deciding whether to adopt Fleet, the dividing line is clear. If the business is fully committed to Azure, Fleet makes perfect sense. It brings simplicity, removes operational noise, and builds resilience into the heart of AKS operations. However, if the business must operate across multiple clouds, sovereign environments, or edge scenarios, Fleet is insufficient on its own. In those contexts, it becomes a valuable component in a larger strategy, complemented by tools such as Azure Arc, service meshes, or open-source governance frameworks.
Fleet, in other words, is both powerful and limited. It shines in the world it was designed for, and within that world, it may become indispensable. But as soon as the enterprise strategy expands beyond Azure, Fleet alone cannot tell the whole story. That does not make it irrelevant; instead, it cements its role as a cornerstone for Azure-first enterprises, even as Microsoft signals plans to integrate it more closely with Arc.
The story of Fleet is the story of Azure’s strength and its boundaries. It serves as a reminder that in multi-cluster Kubernetes, no single tool can solve every challenge. Fleet is a step forward, but only part of the journey.
For the more technical details, check my post Azure Kubernetes Chronicles 6: Managing Multiple AKS Clusters with Azure Fleet.
Previous: Azure Kubernetes Chronicles 7: The Multi-Cluster Reality
️Next up: Azure Kubernetes Chronicles 9: EKS in the Enterprise