AKS Cross-Cluster Networking: 1 GA, 1 Preview [2026]

Microsoft announced general availability of AKS cross-cluster networking through Azure Kubernetes Fleet Manager on November 10, 2026, while keeping AKS multi-NIC pods in public preview, in its KubeCon North America 2026 update. The managed offering runs Cilium Cluster Mesh to give pods in separate AKS clusters direct pod-to-pod communication over a flat network with no overlays or gateways, and Microsoft also announced managed support for the Kubernetes-sigs DRANET driver on RDMA-capable and GPU node pools. Microsoft documentation pages still label cross-cluster networking as Preview and describe multi-NIC pods as not intended for production, caveats that matter to teams running AI and HPC jobs on Azure.

Microsoft announced general availability of AKS cross-cluster networking https://docs.azure.cn/en-us/aks/cross-cluster-networking-fleet-use-cases through Azure Kubernetes Fleet Manager on November 10, 2026, and kept AKS multi-NIC pods in public preview in the same KubeCon North America update. The two features solve different problems. One connects pods across clusters, and the other gives a single pod more than one network interface. Both matter to teams running AI and HPC jobs on Azure, and both carry caveats the headlines skip. Some Microsoft documentation pages still label cross-cluster networking as Preview, and multi-NIC pods remain a preview feature that the documentation reportedly says is not intended for production. Platform teams already tracking a severe flaw in the Azure Kubernetes Configuration service https://shattered.io/azure-kubernetes-configuration-service-cve-2026-83938-cvss-10-2026/ have good reason to read the fine print before they change cluster network topology. Don't miss new tech stories on Google Add Shattered once in the Google app and our stories show up in your news suggestions. Add now https://www.google.com/preferences/source?hl=en&q=https%3A%2F%2Fshattered.io%2F What Microsoft Announced at KubeCon North America on Nov. 10 Microsoft used its KubeCon North America 2026 open-source update, dated November 10, to show where AKS networking is heading. Three items stood out. Cross-cluster networking for Azure Kubernetes Fleet Manager reached general availability as part of Advanced Container Networking Services ACNS . Multi-NIC pods stayed in public preview. And Microsoft announced managed support for the Kubernetes-sigs DRANET driver on RDMA-capable node pools and GPU node pools. DRANET builds on Kubernetes Dynamic Resource Allocation DRA , the upstream mechanism for asking the scheduler for specialized hardware. Microsoft aims it at high-performance networking and RDMA workloads, the kind that distributed AI training and HPC jobs depend on. Because DRA ties scheduling to hardware availability, a pod that requests a particular NIC does not land on a node that cannot supply it. That sounds minor until you have watched a GPU job sit half-started because one worker landed on the wrong node. The timing also matters. Microsoft Ignite runs November 17 to 20, 2026, according to Microsoft’s event page, so the KubeCon posts read as a first wave rather than the full story. Microsoft also cites its 2025 Gartner Magic Quadrant Leader placement for Container Management on its AKS pages the report is dated August 6, 2025 . These networking moves look aimed at holding that position as AI workloads change what buyers expect from a managed Kubernetes service. One framing point helps here. Microsoft did not ship a single AI Kubernetes product. Its current documentation supports networking patterns that fit AI and HPC work, namely large clusters, directly routable pod IPs, multiple interfaces per pod and cross-cluster communication. Nothing on the record shows a separately named AI or HPC plan, SKU or release for AKS, so the AI angle is positioning built on several distinct networking features. AKS Cross-Cluster Networking: How the Managed Cilium Mesh Works The design is simple to state. Azure Kubernetes Fleet Manager runs a managed offering of Cilium Cluster Mesh that gives pods in separate AKS clusters direct pod-to-pod communication. The result is a flat pod network with no overlays and no gateways in the data path, plus multi-cluster observability and consistent security enforcement. Microsoft’s May announcement described the datapath as built on ACNS, Azure CNI, Cilium and eBPF-based direct routing. Teams that built multi-cluster connectivity by hand will recognize the problem it targets. Before a managed option existed, linking clusters meant running your own gateways or proxies, stitching service discovery together, and keeping policy consistent across every cluster. A managed mesh moves that lifecycle into Fleet Manager. According to Microsoft’s documentation, Fleet Manager handles the configuration of cross-cluster networking through a ClusterMesh profile resource, so the mesh is declared once and applied to member clusters. Service-level behavior comes from Cilium. Cilium Global Services use service annotations and offer more granular control over how backends are shared between clusters. Cilium’s own documentation also covers the Kubernetes-standard Multi-Cluster Services API as an alternative model. Microsoft’s description of the AKS feature centers on Cilium’s native approach, so teams already invested in the upstream MCS API should check which model their tooling expects before they commit. Observability is the quieter selling point. Microsoft’s documentation reportedly pairs the mesh with Hubble-based observability across the connected clusters. Debugging cross-cluster traffic is usually where multi-cluster designs fall apart. A packet that crosses two clusters, two sets of policies and possibly two routing domains is hard to trace without shared tooling. Prerequisites and routing limits The requirements narrow the audience. Participating clusters need Azure CNI with the Cilium data plane, Advanced Container Networking Services enabled, and a reachable flat routing domain. Microsoft’s documentation also lists a minimum Kubernetes version of 1.32 for participating clusters, according to the ACNS material, and says connectivity is limited to clusters in the same flat network or in interconnected peered networks. Non-peered virtual networks are not supported. Scale limits show up on two levels, so read both. Microsoft documentation reportedly lists up to 255 member clusters for a cross-cluster networking profile. Upstream Cilium Cluster Mesh also defaults to 255 connected clusters and can be raised to 511 with the maxConnectedClusters setting, at the cost of fewer cluster-local identities. Few teams will hit either ceiling. Teams that plan one cluster per tenant or per region across dozens of regions should still check the numbers early. Cluster version choices also carry risk of their own, as the Kubernetes 1.35 cgroup v1 removal https://shattered.io/kubernetes-1-35-cgroup-v1-removal-2026/ showed when nodes failed to boot. The other multi-cluster option: Application Network Microsoft also documents Azure Kubernetes Application Network as a separate multi-cluster connectivity product, and the documentation reportedly still describes it as Preview. It uses a different model. Clusters that share an explicitly configured network name can reach each other’s pods directly. Clusters on different network names communicate through east-west gateways, and the underlying reachability may come from VNet peering, a VPN or another mechanism. Microsoft’s documentation also warns that merely sharing a VNet or peering node subnets does not guarantee cross-cluster pod-IP reachability. Fleet Manager cross-cluster networking is the flat, gateway-free path. Application Network is the one that tolerates gateways. Pick based on your address plan, not on the product name. GA or Preview: Why Microsoft’s Own Pages Disagree The cleanest reading of the evidence is that cross-cluster networking is generally available according to Microsoft’s November 10 announcement, while parts of Microsoft’s documentation had not caught up. The ACNS overview page fetched on November 6 and 7 still marked Cross Cluster Networking as Preview. The newer announcement says GA. Both cannot be current at once, and the documentation itself offers no way to settle which one wins. This kind of lag is common after a conference-week launch. Product teams publish the announcement on the day, and the reference documentation follows days or weeks later. It still creates real risk for buyers. A support policy, a service-level commitment or an internal change-approval process might key off the word Preview or GA. A team that reads the announcement and skips the reference page may commit to production use on a feature its own documentation still calls preview. History adds context. Microsoft first announced the capability as a public preview on May 22, 2026, powered by ACNS, Azure CNI, Cilium and eBPF-based direct routing. That leaves roughly five and a half months between the preview launch and the November GA announcement. By enterprise standards the gap is short, and it fits a vendor racing to meet AI-driven networking demand. The practical advice is boring and effective. Confirm the status on the current reference page for your region and cluster type. Ask your Microsoft account team to confirm GA in writing if production approval depends on it. And track the documentation until it matches the announcement, because a mismatch between the two is itself a signal about how settled the feature is. AKS Multi-NIC Pods and DRANET: What Ships Today AKS multi-NIC pods let a pod receive one or more secondary network interfaces in addition to the normal CNI-managed eth0 interface. Nodes discover their secondary NICs, and the scheduler attaches them to pods at scheduling time. Microsoft’s Community Hub post of October 9, 2026 announced the feature in public preview, powered by the managed DRANET driver. According to that framing, the approach avoids Multus, custom CNI extensions and manual interface wiring. The network rules are specific. Secondary NICs must sit in the same Azure virtual network as the primary NIC. Different subnets work if you bring your own VNet, but AKS-managed VNets currently restrict secondary interfaces to the primary subnet. For teams that want to separate storage, management and compute traffic onto different subnets, that rule pushes them toward a self-managed VNet design. Microsoft’s configuration documentation reportedly requires a node pool with secondary NICs, a compatible VM size and Linux nodes. The minimum Kubernetes version differs across Microsoft pages, so confirm the current requirement on the configuration page before you plan a cluster upgrade around it. Microsoft’s separate documentation for managed DRANET on RDMA-capable node pools lists its own prerequisites, including quota for an RDMA-capable VM size in the cluster’s region. One more point deserves a flag. Some summaries circulating this week describe AKS as supporting multi-NIC pods, full stop. That overstates the position. The feature is in public preview, and Microsoft’s Azure Local networking documentation, which discusses NIC teaming and dedicated storage subnets, covers a different product and does not confirm multi-NIC pod support in AKS. Limits that matter before production Three limits stand out in the preview documentation. First, each secondary NIC can be assigned to only one pod at a time, so NICs cannot be shared the way a CPU core can be oversubscribed. Second, AKS network policies reportedly apply only to the primary NIC, which means traffic over a secondary interface bypasses AKS network-policy enforcement. Third, the feature is marked preview and, according to the documentation, not intended for production use. The second limit deserves the most attention from security teams. A secondary interface sits outside the policy model most clusters rely on. If a workload uses a secondary NIC for RDMA or storage traffic, the controls must come from somewhere else, such as the VNet layer, network security groups or the application itself. Why AI and HPC Teams Want Secondary NICs Distributed training jobs move huge volumes of gradient data between workers, and they punish latency spikes. A pod with only an eth0 interface forces all traffic through one path. Giving the pod a dedicated high-bandwidth interface for collective operations, while control traffic stays on eth0, is a common design in HPC clusters. AKS multi-NIC pods bring that pattern into managed Kubernetes without custom plumbing. Microsoft’s choice of DRA as the mechanism matters as much as the feature. DRA lets pods declare hardware needs as claims, and the scheduler matches claims to devices. Network interfaces then become schedulable resources, much like GPUs. A pod that needs an RDMA NIC and a GPU on the same node can say so, and the scheduler can refuse nodes that fail either test. Teams that fight placement errors on mixed GPU fleets will feel the difference. Caution applies to the InfiniBand story. Microsoft’s Azure Local documentation describes Azure HPC as a purpose-built capability using HPC-class InfiniBand interconnects. Nothing on the record establishes that multi-NIC pods or cross-cluster networking integrate with Azure HPC or InfiniBand. Teams building on those assumptions should test before they plan around them. Cost pressure sits behind the interest. Clusters running AI jobs burn money when GPUs wait on the network, and idle accelerators are expensive. That is why FinOps teams, already worried about low CPU and GPU utilization in Kubernetes clusters https://shattered.io/kubernetes-cost-optimization-8-percent-cpu-5-percent-gpu-finops-2026/ , should watch how well these networking features keep accelerators busy. Better scheduling and faster interconnects only pay off if utilization actually rises. Overlay vs Pod Subnet: The Network Model Underneath Both Features Neither new feature replaces the base network model. Microsoft’s current guidance recommends Azure CNI Overlay for most scenarios and Azure CNI Pod Subnet when workloads need direct pod IP access from connected networks. Azure CNI Node Subnet is described as the legacy flat model, and kubenet is scheduled for retirement on March 31, 2028. Microsoft’s guidance says workloads on kubenet should migrate to Azure CNI Overlay before that date to avoid losing support. | Network model | Pod reachability | Scale and notes | Microsoft guidance | |---|---|---|---| | Azure CNI Overlay | Pod addresses not directly reachable from outside the cluster, a gateway may be required | Up to 5,000 nodes and 200,000 pods per cluster, supports dual stack | Recommended for most scenarios | | Azure CNI Pod Subnet | Pods get VNet addresses and are reachable from connected networks | Dynamic IP allocation and static block allocation, up to 50,000 application pods per cluster with dynamic allocation | Use when direct pod IP access is required | | Azure CNI Node Subnet | Pods and nodes share one subnet | Flat model | Described as legacy | | kubenet | Separate older AKS model | Retires March 31, 2028 | Migrate to Azure CNI Overlay | | Fleet Manager cross-cluster networking | Direct pod-to-pod across AKS clusters, no overlays or gateways | Needs Azure CNI with Cilium data plane and ACNS | GA per Nov. 10 announcement | The tension is plain once you read the table. Overlay is the scalable default, and its pod addresses stay private to the cluster. Cross-cluster networking wants a flat, reachable routing domain. A team that picked Overlay for address conservation may find that cross-cluster networking pushes it toward flat networking, and the move between models is a real project, not a toggle. Address planning belongs at the start of any multi-cluster design. Microsoft’s guidance for large clusters gives a sense of how this plays out at AI scale. Overlay supports up to 5,000 nodes and 200,000 pods per cluster. Pod Subnet with dynamic IP allocation tops out at 50,000 application pods per cluster, according to Microsoft’s large-cluster performance guidance. For most AI training fleets, node count rather than pod count is the binding constraint, so the Pod Subnet ceiling is unlikely to bite first. The routing requirement is the more common reason to choose it. AKS Networking Status Table: What Is Safe to Use Now A single table keeps the maturity labels straight. Use it as a planning aid and verify each row against the current documentation before you approve production use. | Feature | What it does | Status on Nov. 12, 2026 | Basis | |---|---|---|---| | Cross-cluster networking Fleet Manager, ACNS | Direct pod-to-pod connectivity across AKS clusters via managed Cilium Cluster Mesh | GA per Nov. 10 announcement, some pages still say Preview | Microsoft open-source blog, ACNS overview | | Multi-NIC pods | Attaches secondary NICs to pods through DRA | Public preview | Microsoft Community Hub post, Oct. 9 | | Managed DRANET support | Network driver for RDMA-capable and GPU node pools | Announced Nov. 10 | Microsoft open-source blog | | Azure CNI Overlay | Scalable default pod network | Current, recommended | Azure CNI overview | | Azure CNI Pod Subnet | Flat pod network with VNet addresses | Current | Azure CNI overview | | Azure CNI Node Subnet | Legacy flat model | Legacy | Azure CNI overview | | kubenet | Older AKS networking | Retires March 31, 2028 | Azure CNI overview | Two rows deserve extra scrutiny. The first is the cross-cluster networking row, because of the documentation lag covered above. The second is managed DRANET, where the November 10 announcement covers support for RDMA-capable and GPU node pools but no dated status label exists beyond the announcement itself. Ask Microsoft which regions and VM sizes are covered before you plan around it. Historical Context: How AKS Became a Multi-Cluster Platform AKS started as a single-cluster service, and for years the interesting questions were about nodes, upgrades and cost. The 2026 timeline shows a shift toward fleets and specialized networking. Microsoft announced cross-cluster networking in public preview in May, brought multi-NIC pods to public preview in October and used KubeCon in November to push one to GA and extend DRANET to RDMA and GPU pools. | Date | Event | |---|---| | May 22, 2026 | Cross-cluster networking announced in public preview for Fleet Manager | | Oct. 9, 2026 | Multi-NIC support on AKS powered by DRANET enters public preview | | Oct. 31, 2026 | Azure Linux node image removal begins, affected node pools cannot be scaled afterward | | Nov. 10, 2026 | Cross-cluster networking announced as GA, managed DRANET support announced | | Nov. 17 to 20, 2026 | Microsoft Ignite | | March 31, 2028 | kubenet retirement date | The Azure Linux entry shows that the networking story does not run alone. Microsoft documents that Azure Linux node images are being removed beginning October 31, 2026, after which affected node pools cannot be scaled. Teams that plan networking changes this quarter should check whether node image maintenance is already on their calendar. Two disruptive changes in the same month make for a rough change window. Cilium’s own release cadence adds a third clock. The stable Cilium documentation covers version 1.20.4, and the development branch is 1.21.0-dev. The 1.21 line is not a released version and should not be treated as one. On AKS, Microsoft manages the Cilium data plane through Azure CNI Powered by Cilium, so upstream release timing matters less than what Microsoft ships, but it still shapes which features arrive and when. Security Implications of Flat Networks and Extra NICs Flat networking has a security price. When pods hold routable addresses and clusters talk directly, a compromise in one cluster has a shorter path to another. Microsoft says the cross-cluster design maintains consistent security enforcement, and ACNS includes network-policy enforcement, but the effect depends on correct policy design. A team that adopts the mesh without revisiting its zero-trust network policy model https://shattered.io/kubernetes-network-policy-zero-trust-2026/ may end up with a broader blast radius than before. Secondary NICs raise a separate issue. Because AKS network policies reportedly cover only the primary interface, any traffic on a secondary NIC needs controls elsewhere. That includes network security groups on the VNet, application-level authentication and monitoring that watches the secondary interface directly. Security teams should add the secondary NIC to their asset inventory the day the first pod uses one. Routing control matters too. Cilium’s BGP Control Plane https://docs.cilium.io/en/latest/network/bgp-control-plane/bgp-control-plane/index.html can advertise pod and service routes to connected routers, but its documentation says it does not program the datapath and should not be used to establish reachability inside a cluster. Teams that mix BGP with a managed mesh should keep the roles separate and document who owns which routes. Recent Azure container incidents show why caution is warranted. Platform teams reading the new Azure container security changes around Defender and AKS flex nodes https://shattered.io/azure-container-apps-security-defender-cspm-aks-flex-nodes-2026/ and the Brotli bug that forced Azure image rebuilds https://shattered.io/brotli-cve-2026-111497-azure-container-image-rebuild-acr-metrics-2026/ face the same lesson. New connectivity features expand the surface that needs patching, monitoring and review, and the busiest teams tend to fall behind on exactly that work. Market Impact: Microsoft Against EKS and GKE Microsoft’s announcement is a bet that managed Kubernetes buyers will choose the platform that handles AI networking with the least custom work. The sources behind this analysis cover Microsoft’s features, not those of Amazon or Google, so a feature-by-feature comparison with EKS and GKE would need facts that are not on the record. What can be said is directional. All three major managed Kubernetes services now compete on how well they handle accelerators, high-bandwidth interconnects and multi-cluster operations, and Microsoft has staked out a position on all three fronts in one week. The multi-cluster angle may matter most to enterprises. Regulated firms often run many clusters across regions and business units, and a managed flat network between them removes a long list of bespoke work. Fleet Manager also reaches beyond AKS, according to its documentation, which lists Azure Arc-enabled Kubernetes, K3s, OpenShift, EKS, GKE and Rancher among supported or member cluster types, though the Arc extension is reportedly still in preview. Cross-cluster networking itself, as documented, targets AKS clusters on Azure CNI with Cilium. For buyers weighing AI platforms more broadly, Kubernetes networking is one layer of a larger decision. Anyone comparing Bedrock, Microsoft Foundry and Vertex AI https://shattered.io/bedrock-vs-azure-ai-foundry-vs-vertex-ai-2026/ will weigh model access and pricing first, and cluster networking second. Teams that train or serve their own models on Kubernetes will flip that order. Multi-cloud teams should also keep risk in view. A GKE multi-cloud flaw with cross-project risk https://shattered.io/gke-multi-cloud-flaw-cross-project-risk-2026/ showed how connectivity features can widen exposure across projects. Managed meshes inherit that lesson. The more clusters a platform links, the more a single identity or policy mistake can spread. Cost and Pricing: What Microsoft Has Not Said Microsoft has published no official prices for AKS multi-NIC pods, managed DRANET, Fleet Manager cross-cluster networking or Application Network in the documentation behind this analysis. Azure CNI is documented as an AKS networking capability and not as a separately priced product. ACNS has no separately named pricing tier in the available documentation. That does not mean the features are free. Underlying costs, such as VM sizes with RDMA capability, extra NICs and cross-cluster data movement, still show up on an Azure bill. AKS itself has three cluster-management tiers, Free, Standard and Premium, according to current documentation. Standard targets production workloads up to 5,000 nodes, and Premium adds an uptime SLA and 24-month Long-Term Support coverage. Which tier a given networking feature requires is not stated in the documentation reviewed. Ask before you budget. Finance teams should model three buckets. Compute for RDMA-capable and GPU node pools will dominate. Network egress between clusters and regions can surprise teams that assume a flat network is free. And the engineering time to redesign address plans, which rarely appears in a cloud bill, often costs more than any line item. Teams that track unit economics across managed cloud services https://shattered.io/category/cloud-computing/ should start capturing cross-cluster traffic as its own cost dimension now. What Platform Teams Should Do Before Ignite Start with an inventory. List every AKS cluster, its network plugin and mode, its Kubernetes version and whether it uses the Cilium data plane. Clusters on kubenet need a migration plan to Azure CNI Overlay before March 31, 2028. Clusters on Node Subnet should be reviewed because Microsoft calls it legacy. Only clusters on Azure CNI with the Cilium data plane qualify for cross-cluster networking. Next, run a lab. A small multi-cluster test is cheap and teaches more than any announcement. Teams that want a safe place to practice can build clusters locally with a kind-based Kubernetes lab https://shattered.io/kubernetes-tutorial-kind-1-37-local-cluster-12-steps-2026/ to rehearse policy and service design, then repeat the exercise on AKS with cross-cluster networking enabled. Test failure cases, such as a peered network dropping out, as well as the happy path. Third, ask Microsoft direct questions. Request written confirmation of GA status for cross-cluster networking. Ask which regions and VM sizes support managed DRANET, which Kubernetes versions each feature needs, and whether multi-NIC pods will gain network policy coverage on secondary interfaces. Partner briefings, such as the Partner Radar summary of AKS networking changes https://partner-radar.com/news/p55q8u , can help frame the questions, though the primary record remains Microsoft’s documentation. Finally, hold production approval on multi-NIC pods until the preview label comes off. Use them in labs and benchmark runs where a failure costs time but not revenue. That approach keeps your learning curve moving without tying a customer-facing service to a feature the documentation says is not ready. Predictions: 5 Calls for the Next Two Quarters These are analysis, not reporting, and none rests on a confirmed Microsoft date. - Documentation catches up. Expect the ACNS overview and related pages to align with the GA announcement, likely around Ignite week, because vendors usually clean up reference pages after a major event. - Multi-NIC pods stay in preview longer than cross-cluster networking did. The gap in network policy coverage on secondary interfaces is a hard problem, and Microsoft is unlikely to drop the preview label until it has a credible answer. - Overlay becomes the assumed default. With kubenet scheduled for retirement and Node Subnet called legacy, expect more migration guidance and tooling as the March 31, 2028 date approaches. - Rivals answer with their own accelerator-networking announcements. Amazon and Google face the same AI buyers, and a managed RDMA and DRA story is easy to match in marketing even if the engineering differs. - Buyers demand per-feature maturity labels. The gap between a conference announcement and a documentation update has become too costly to ignore, so expect procurement teams to ask for maturity status in writing. FAQ Is AKS cross-cluster networking generally available? Microsoft’s November 10, 2026 announcement says cross-cluster networking for Azure Kubernetes Fleet Manager reached general availability as part of Advanced Container Networking Services. Some documentation pages fetched in early November still labeled it Preview, so confirm the status on the current reference page before approving production use. Are AKS multi-NIC pods ready for production? No. The feature entered public preview on October 9, 2026, and remained in preview in Microsoft’s November 10 update. Use it for labs and benchmarks until Microsoft removes the preview label. What does DRANET do on AKS? DRANET is a Kubernetes-sigs network driver that uses Dynamic Resource Allocation to attach network interfaces to pods. Microsoft announced managed support for it on RDMA-capable and GPU node pools, aimed at high-performance networking workloads. Which Azure CNI model should I use? Microsoft recommends Azure CNI Overlay for most scenarios. Choose Azure CNI Pod Subnet when pods need direct private-IP reachability from connected networks. Azure CNI Node Subnet is described as legacy. When does kubenet retire on AKS? Microsoft says kubenet networking for AKS will be retired on March 31, 2028. Workloads on kubenet should migrate to Azure CNI Overlay before that date to avoid losing support. What do clusters need to join cross-cluster networking? Clusters need Azure CNI with the Cilium data plane, Advanced Container Networking Services enabled and a reachable flat routing domain. Microsoft documents the mesh as managed Cilium Cluster Mesh delivered through Azure Kubernetes Fleet Manager. Does Microsoft charge extra for these features? Microsoft has published no separate prices for them in the documentation reviewed. Underlying compute, network interfaces and data transfer still appear on the Azure bill, so check the Azure pricing pages and test costs in a small deployment.