AKS (Azure CNI) – Why are Pod and Node CIDR ranges different?

Question

AKS (Azure CNI) – Why are Pod and Node CIDR ranges different?

Varma 1,560

I created an AKS cluster using Azure CNI with the following commands:

az network vnet create -g RG -n aks-vnet --address-prefix 10.10.0.0/16 az network vnet subnet create -g RG --vnet-name aks-vnet -n aks-node-subnet --address-prefixes 10.10.1.0/24 az aks create \ --resource-group RG \ --name manual-aks \ --node-count 2 \ --network-plugin azure \ --vnet-subnet-id $(az network vnet subnet show -g RG --vnet-name aks-vnet -n aks-node-subnet --query id -o tsv) \ --enable-managed-identity

Observation:

Nodes are getting IPs from VNet subnet: 10.224.0.x
Pods are getting IPs from a different range: 10.0.0.x

Question: As I am using Azure CNI, I expected both nodes and pods to get IPs from the same VNet subnet. Why are pods assigned a different CIDR range in this case?

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Marcin Policht 86,455 MVP Volunteer Moderator

AFAIK, this happens because by default, when you create an AKS cluster using Azure CNI without specifying a pod CIDR, AKS automatically allocates a separate range for pod IPs from an internal pool, rather than using the node subnet directly. In Azure CNI, nodes receive IPs from the subnet you specify (in your case 10.10.1.0/24), but pods get IPs from a secondary CIDR range that AKS manages. This range is often drawn from 10.0.0.0/8 or another large internal block, which is why your pods are getting 10.0.0.x addresses.

If you want pods to get IPs directly from the same subnet as nodes, try explicitly defining a pod IP range that overlaps the node subnet or extend the node subnet to include additional IPs for pods. This is done using the --pod-cidr parameter when creating the AKS cluster. For example:

az aks create \
  --resource-group RG \
  --name manual-aks \
  --node-count 2 \
  --network-plugin azure \
  --vnet-subnet-id $(az network vnet subnet show -g RG --vnet-name aks-vnet -n aks-node-subnet --query id -o tsv) \
  --enable-managed-identity \
  --pod-cidr 10.10.1.0/24

However, note that the subnet must have enough free IPs to accommodate both node IPs and pod IPs, because Azure CNI assigns a unique IP to every pod from the subnet.

Since you didn’t specify a pod CIDR, AKS automatically created the 10.0.0.x range for pod allocation. That’s why you see nodes and pods on different IP ranges even with Azure CNI.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Varma 1,560 Reputation points

2026-04-02T11:33:31.2766667+00:00

Hi Marcin ,

Case 1:

Without specifying a Pod CIDR, pods and nodes receive IP addresses from different CIDR ranges. I also observed that these CIDRs can belong to different virtual networks—for example, 10.0.0.0/24 for pods and 10.10.0.0/16 for nodes. Is that true ?

Case 2:

When a Pod CIDR is specified, pods always receive IP addresses from the defined Pod CIDR, while node IPs are assigned from the same virtual network. In this case, both pod and node IPs are allocated within the VNet, based on the configured CIDR ranges. Is that true ?
Marcin Policht 86,455 Reputation points MVP Volunteer Moderator

2026-04-02T11:39:57.7766667+00:00

For Case 1, it is not exactly true that pods get IPs from a different virtual network. What actually happens is that if you do not specify a pod CIDR when creating an AKS cluster with Azure CNI, AKS automatically allocates a pod IP range from an internal address space managed by the cluster, which may appear to be a different subnet like 10.0.0.0/24. This range is still routable within the same VNet as the nodes, but Azure internally reserves it and assigns it to pods. So the pods are not in a separate VNet - they are just in a different IP range within the same VNet or from a reserved internal range if no pod CIDR is specified.

For Case 2, this is true. When you explicitly specify a pod CIDR using --pod-cidr, AKS allocates pod IPs from that defined range, which must be a subset of the VNet or at least routable within it. Node IPs continue to be assigned from the subnet you specify with --vnet-subnet-id. In this scenario, both nodes and pods are within the VNet, and the IP allocation is predictable, because you control the ranges for pods and nodes explicitly.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin
Varma 1,560 Reputation points

2026-04-02T11:58:03.49+00:00

So when using azure cni - —> pod ip & node ip always in same network ( it does not matter whether we specify pod ip or not ) am I right ?

And i heared about azure cni and azure cni overlay ? What’s the unique difference?
Marcin Policht 86,455 Reputation points MVP Volunteer Moderator

2026-04-02T12:00:20.7366667+00:00

Yep - when using Azure CNI, both pod IPs and node IPs are within the same VNet. The difference is in how the IPs are allocated. If you don’t specify a pod CIDR, AKS automatically selects a range of IPs from the VNet or from a reserved internal pool that is routable within the VNet. If you specify a pod CIDR, AKS will assign pod IPs from that specific range. In either case, pods are reachable via the VNet, so nodes and pods exist logically in the same network, even if the pod range looks like a separate subnet. The point is that Azure CNI gives pods real VNet IPs, unlike kubenet where pods are NATed behind node IPs.

Azure CNI and Azure CNI Overlay differ in how IPs are assigned and routed. Standard Azure CNI assigns each pod a direct IP from the VNet subnet. This is efficient and fully routable but requires enough IPs in the subnet to accommodate all pods plus nodes, which can limit scalability. Azure CNI Overlay, on the other hand, assigns pods IPs from an internal, private overlay network and uses encapsulation (VXLAN) to route pod traffic over the VNet. This reduces the requirement for large subnets because the overlay network can be much larger than the physical subnet, but it adds a small encapsulation overhead and slightly more complex routing. The difference is direct VNet IPs vs. overlay network IPs with encapsulation, affecting scalability and subnet planning.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Share via

AKS (Azure CNI) – Why are Pod and Node CIDR ranges different?

0 additional answers

Your answer