Powering multi-cluster workloads with seamless cross-cluster networking for Azure Kubernetes Fleet Manager

Running Kubernetes at scale often means distributing workloads across multiple clusters—whether for high availability, disaster recovery, or geographic distribution. But managing networking across clusters has traditionally been complex and fragmented. Microsoft’s latest announcement brings Cilium-based cross-cluster networking to Azure Kubernetes Fleet Manager, creating a unified network fabric that treats multiple clusters as a single, logical system. This addresses a real pain point: teams previously had to cobble together networking solutions or accept the operational burden of managing cluster-to-cluster communication manually.

Here’s how it works technically. Cilium is an open-source, eBPF-based networking engine that Microsoft has integrated into Fleet Manager. Instead of relying on traditional overlay networks or complex service mesh configurations, Cilium establishes direct, high-performance connections between pods across different clusters. When a pod in Cluster A needs to communicate with a pod in Cluster B, the network stack handles routing transparently—applications don’t need to know or care which cluster their dependencies live on. Fleet Manager manages the Cilium control plane centrally, handling service discovery, network policies, and load balancing across the entire fleet. The magic here is eBPF (extended Berkeley Packet Filter), which allows kernel-level networking enforcement without the overhead of traditional virtual networking layers.

From a practical standpoint, this changes how you architect multi-cluster systems. A common scenario: you’re running your payment processing service in one region for compliance, your API layer in another for latency, and keeping a standby cluster for failover. Previously, you’d need explicit network peering, DNS workarounds, or a service mesh like Istio—each adding operational complexity and performance tax. With Fleet Manager’s integrated networking, services discover and communicate across clusters as if they were running on the same network. You also get consistent network policies across your entire fleet, meaning security teams can define rules once instead of managing them cluster-by-cluster. For teams handling millions of requests per second, eliminating extra hops and reducing orchestration overhead directly impacts costs and performance.

The broader implication is that multi-cluster Kubernetes becomes more accessible to teams that previously couldn’t justify the complexity. You can now treat your fleet as a unified compute platform rather than managing multiple isolated clusters. If you’re building resilient systems on Azure using Kubernetes, this is worth exploring—it removes barriers that have historically made multi-cluster setups feel like an advanced-only feature.