AKS Pod CIDR Expansion Is GA: Fix Pod IP Exhaustion on Azure CNI Overlay Without Rebuilding the Cluster

Running out of pod IP addresses used to mean rebuilding an AKS cluster from scratch. Azure CNI Overlay assigns pods a small, fixed CIDR block, and until recently that block was locked in for the life of the cluster. A cluster that grew faster than expected, or that was originally sized for a workload that later expanded, could hit a hard IP exhaustion wall with no in-place fix. Microsoft made Pod CIDR Expansion for Azure CNI Overlay generally available, and it changes that. You can now grow the pod address space on a live cluster with an az aks update call, no migration, no downtime for the control plane, no recreating node pools.

How you actually find out you have this problem

Pod CIDR exhaustion does not announce itself with a clear error days in advance. It shows up as pods failing to schedule or start, often first on the most densely packed nodes in the cluster, because a node running close to its pod capacity can tip a nearly-full subnet over the edge with just a few additional pods. If you are seeing intermittent pod scheduling failures that do not correlate with CPU or memory pressure, checking pod IP allocation should be on your list of things to rule out, especially on clusters that have grown node count or pod density since they were first sized.

If you never explicitly set a pod CIDR when the cluster was created, AKS defaulted it to 10.244.0.0/16. That sounds generous until you do the math against actual pod density on real node pools at scale, which is exactly how clusters end up here without anyone deliberately under-provisioning.

Expanding the pod CIDR

The expansion is a single command against an existing Azure CNI Overlay cluster:

az aks update \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --pod-cidr 10.244.0.0/15

There are real constraints worth knowing before you run it. The new CIDR has to be a larger superset that fully contains the original range, you cannot shrink the range or move to a discontinuous block, and the feature currently supports Linux nodes only, Windows nodes and hybrid node scenarios are not supported. Plan the new range with room to actually grow into, not just enough to clear the current exhaustion, since you are still choosing a fixed target even though the operation itself is non-disruptive.

Verifying the expansion actually applied

After the update completes, confirm every node pool picked up the new range before assuming you are done:

kubectl get nnc -A

This queries the NodeNetworkConfig objects across the cluster. Every node pool listed should reflect the new pod CIDR block. If any node pool still shows the old range, do not treat the migration as finished, investigate that node pool specifically before relying on the expanded space.

Why this matters beyond just fixing today’s exhaustion

Before this feature reached general availability, the standard remediation for pod CIDR exhaustion on Azure CNI Overlay was creating a new cluster with a larger range and migrating workloads over, a real project with real risk, not a quick fix. Being able to expand in place removes a category of forced cluster migrations that had nothing to do with the actual workload and everything to do with an address planning decision made early in the cluster’s life. It also changes the calculus for initial sizing: since the range can now be grown later without a rebuild, there is less pressure to over-provision a huge pod CIDR up front just to avoid this exact problem down the road.

Frequently asked questions

Does expanding the pod CIDR cause any downtime?
The operation is designed to update the running cluster without requiring a rebuild or full redeployment. Existing pods are not disrupted by the CIDR expansion itself, though you should still validate the change in a non-production cluster first if you are risk-averse about networking changes on a live cluster.

Can I shrink the pod CIDR later if I over-expand?
No. Shrinking or changing to a non-superset range is not supported. Plan the expanded range deliberately rather than treating it as freely reversible.

Does this work on Azure CNI with a dedicated pod subnet instead of Overlay mode?
This specific expansion capability applies to Azure CNI Overlay. Clusters using Azure CNI with pod subnet assignment from a dedicated subnet have a different IP model and different remediation options for exhaustion, including dynamic IP allocation, check the networking mode your cluster actually uses before assuming this procedure applies.