Azure Fleet Manager Gets Cross-Cluster Networking

Microsoft is adding Cilium-based cross-cluster networking to Azure Kubernetes Fleet Manager, aimed at teams powering multi-cluster workloads across AKS fleets without building their own web of VPNs, gateways, and manual service discovery.

The useful part is not the phrase “seamless.” The useful part is what Microsoft says the managed layer now handles: east-west pod connectivity across clusters, global service discovery through Kubernetes service annotation, multi-cluster observability, and security policy enforcement that can follow workloads beyond a single cluster boundary.

What changed#

Azure Kubernetes Fleet Manager already covered parts of the multi-cluster control problem: workload propagation across member clusters and staged update orchestration. Microsoft’s new blog post says the remaining pain point is networking between those clusters.

The announced capability uses Cilium-based cross-cluster networking through Advanced Container Networking Services. Microsoft describes it as a managed network that can span an AKS fleet, allowing services and workloads to communicate across cluster boundaries “as if they were local,” while preserving cluster-level isolation and governance.

The core pieces named in the source are concrete:

• east-west connectivity using eBPF-based routing with Azure CNI powered by Cilium
• no proxy or gateway requirement for pod-to-pod cross-cluster communication, according to Microsoft
• global service discovery by adding service.cilium.io/global=true to a standard Kubernetes Service
• automatic endpoint discovery across joined member clusters
• transparent load balancing and failover across those endpoints
• aggregated metrics, logs, and flow visibility across clusters
• network policy and observability through Advanced Container Networking Services
• managed lifecycle work for certificates and network configuration

That is a meaningful shift if your current multi-cluster design depends on hand-built connectivity glue. It moves part of the problem from bespoke infrastructure into a managed Azure and Cilium-based model.

It does not remove the need to design the system. It changes where the design pressure moves.

Why powering multi-cluster workloads is hard#

Multi-cluster Kubernetes is usually not a vanity architecture. Teams split clusters for regulatory boundaries, disaster recovery, regional latency, capacity management, tenancy, or blast-radius control. Those reasons are often valid. The cost appears later, when services need to talk across those boundaries.

A single Kubernetes cluster gives developers a familiar service model. Multiple clusters break that illusion. Discovery becomes more complex. Failover becomes more explicit. Network policy has to match a wider reality than “inside this cluster.” Observability tools need to explain traffic paths that now cross administrative and regional lines.

Microsoft’s framing is that Fleet Manager should make the cluster boundary less visible to application teams. That is attractive for platform teams. Developers can keep using standard Kubernetes service patterns while the platform layer handles cross-cluster routing and endpoint discovery.

The trade-off is obvious: abstraction can reduce toil, but it can also hide failure modes. If a service becomes global with an annotation, the operational checks around that annotation matter. A small configuration change can widen the reachable surface of a workload. That is not automatically a privacy risk or security incident, but it is a change in exposure and dependency.

For security operations, this is where the announcement matters most. Multi-cluster networking is not just transport. It is identity, policy, telemetry, certificate handling, failure behavior, and incident scoping.

Why it matters for security operations#

Cilium is a serious open source security and networking foundation, and eBPF has become a core building block for modern Kubernetes networking and observability. Microsoft’s use of that foundation is a positive signal for portability and ecosystem alignment. It also means teams will need people who understand how Cilium behavior maps into Azure’s managed implementation, not only people who understand Kubernetes Services in the abstract.

The security promise in the blog is unified policy and governance across the fleet. That is the right direction. Policies that stop at a cluster boundary are weaker in a world where workloads, failover paths, and shared services cross that boundary.

But “unified” needs testing. Security teams should not assume that policy intent, enforcement, logging, and alerting are equivalent across local and cross-cluster paths until they verify it in their own environment. The interesting questions are practical:

• Does a deny policy behave the same way for local and remote endpoints?
• Are cross-cluster flows visible in the tools the incident team already uses?
• Can responders identify which cluster, namespace, service, and workload handled a request?
• Are certificate lifecycle events visible enough to debug failures without unsafe workarounds?
• Does global service discovery create paths that were not reviewed in the original threat model?

These checks are not objections to the feature. They are the price of using a managed abstraction in production.

This also fits a broader open source security pattern: artifacts and foundations matter only when they become operational. Cilium and other CNCF projects give transparency and a stronger shared base, but production safety still depends on how the platform is configured, observed, and patched. See also: OpenSSF’s April signal: make security artifacts operational.

What to check before using it#

Start with topology. Identify which clusters are eligible to join the fleet, which namespaces should ever expose global services, and which teams can apply the annotation that makes a Service global. Treat that annotation as a controlled capability, not just a convenience flag.

Then test policy behavior with real cases. Build a small matrix: same-cluster allowed, same-cluster denied, cross-cluster allowed, cross-cluster denied, failover during endpoint loss, and traffic during partial cluster health. If the policy story is weaker across clusters than inside one cluster, fix that before expanding adoption.

Observability should be tested before reliability claims. Microsoft points to aggregated metrics, logs, and flow visibility through Advanced Container Networking Services and Cilium telemetry. That is useful only if your operators can answer concrete questions during an incident: what talked to what, from where, under which policy, and what changed before the failure.

Review privacy and data boundary assumptions. Cross-cluster networking can make regional and tenant separation easier to operate, but it can also blur boundaries if service exposure is too broad. If clusters exist for regulatory or data locality reasons, do not let a “global” service label bypass the reason those clusters were separated in the first place.

Capacity and failure behavior also need rehearsal. Transparent load balancing and failover sound clean in a diagram. In production, failover can move load into a region or cluster that was not sized for it. If the architecture depends on shifting workloads across regions for capacity or latency, the capacity plan has to match the routing plan.

Finally, document rollback. A managed network can reduce setup cost, but teams still need an escape path when a global service behaves badly. Know how to remove global exposure, isolate a member cluster, and confirm traffic has stopped crossing the fleet.

What not to overclaim#

The Microsoft post is an announcement and positioning piece, not an independent benchmark or a security audit. It says the network is managed and high-performance. It says eBPF-based routing avoids proxies and gateways. It says Fleet Manager handles certificate and network configuration lifecycle. Those claims are relevant, but they should be validated against your workload shape, region layout, and existing security controls.

Do not treat cross-cluster networking as a replacement for application resilience. If an application cannot tolerate remote latency, inconsistent dependencies, or partial failure, a global service abstraction will not make it resilient by itself.

Do not treat open source foundations as automatic safety. Open source security improves inspectability and ecosystem review, but the operational result depends on configuration, update discipline, policy coverage, and telemetry. For a related example on why coverage needs to become a real control, not a slogan, see 100% package test coverage is the point, not the slogan.

And do not treat managed lifecycle as no lifecycle. Certificates, networking configuration, cluster membership, and service exposure are still part of the control plane. They just move into a different operating model.

Practical takeaway#

This is a useful Azure Kubernetes Fleet Manager addition for organizations already running AKS fleets or planning multi-region, shared-services, or failover-heavy Kubernetes designs. It targets a real pain: powering multi-cluster workloads without forcing every platform team to build its own cross-cluster network stack.

The adoption path should be controlled. Start with non-critical services, prove policy and observability, rehearse failover, and decide who can create global services. The feature may reduce networking toil. It should not reduce scrutiny.