Azure CNI provides true network isolation for your AKS pods, meaning they get their own IP addresses from your virtual network, while Kubenet uses a bridge and NAT for pod IPs.
Let’s see this in action. Imagine you have two pods, pod-a and pod-b, running on AKS.
With Kubenet, both pods might have internal IPs like 10.240.0.4 and 10.240.0.5. When pod-a wants to talk to pod-b, the traffic goes from pod-a’s IP, through the AKS node’s network interface, gets NATted to the node’s IP (e.g., 192.168.1.100), and then routed to pod-b. The destination sees the traffic coming from the AKS node, not directly from pod-a.
With Azure CNI, if your AKS subnet is 10.1.0.0/16, pod-a might get 10.1.1.5 and pod-b might get 10.1.2.10. When pod-a talks to pod-b, the traffic originates from 10.1.1.5 and is routed directly to 10.1.2.10 within your virtual network. The destination pod sees the actual pod IP.
Here’s a typical configuration for Kubenet:
apiVersion: aks.azure.com/v1
kind: ManagedCluster
metadata:
name: my-aks-cluster
spec:
networkProfile:
networkPlugin: kubenet
serviceCidr: 10.0.0.0/16
dnsServiceIP: 10.0.0.10
dockerBridgeCidr: 172.17.0.1/16
And for Azure CNI:
apiVersion: aks.azure.com/v1
kind: ManagedCluster
metadata:
name: my-aks-cluster
spec:
networkProfile:
networkPlugin: azure
networkPolicy: azure # Or Calico
serviceCidr: 10.0.0.0/16
dnsServiceIP: 10.0.0.10
podCidr: 10.240.0.0/16 # This is an example, it's often dynamically allocated or defined by a separate IP address pool
The core problem Azure CNI solves is enabling direct VNet integration for pods. This means your pods can have IPs that are routable on your Azure Virtual Network, just like VMs. This unlocks several capabilities:
- Network Security Groups (NSGs): You can apply NSGs directly to pod IPs. This is impossible with Kubenet, as traffic is NATted through the node.
- Service Endpoints/Private Endpoints: Pods can directly access Azure PaaS services (like Azure SQL, Storage) using Service Endpoints configured on your VNet, or connect to private endpoints.
- On-premises connectivity: If your AKS cluster is connected to your on-premises network via VPN or ExpressRoute, pods with Azure CNI can communicate directly with on-premises resources using their VNet IPs.
- IP Address Management: With Azure CNI, you have more granular control over IP address allocation for your pods, which can be crucial in large-scale deployments.
Internally, Azure CNI leverages the Azure VNet’s routing capabilities. Each pod is assigned an IP address from a dedicated IP address pool (often a secondary CIDR block associated with the AKS node’s subnet). The Azure VNet fabric then routes traffic directly to these pod IPs. This is achieved by creating network interfaces (vNICs) for each pod or by using IP address management (IPAM) that integrates with Azure’s networking.
When you choose Azure CNI, you’re essentially treating your pods as first-class network citizens within your Azure VNet. The AKS nodes themselves act as gateways or routers for their assigned pod IPs, but the routing logic is handled by the Azure VNet.
The most surprising mechanical detail about Azure CNI is how it handles the IP address exhaustion for nodes. When you create an AKS cluster with Azure CNI, you’re typically required to specify a podCidr for the cluster, or have it dynamically assigned. This podCidr is then sub-allocated to each node. Each node gets a smaller CIDR block from this overall podCidr, and pods on that node get IPs from the node’s allocated block. The maximum number of pods per node is determined by the size of this secondary CIDR block assigned to the node, and this is a hard limit you need to plan for.
The next concept you’ll encounter is advanced network policies using Calico with Azure CNI for fine-grained pod-to-pod communication control.