Networking Models¶

AKS networking determines pod IP assignment, routability, subnet pressure, and now the dataplane used for packet forwarding and policy enforcement. It is one of the hardest platform choices to change later, so design the IP model and the dataplane together.

Main Content¶

flowchart TD
    A[Networking Choice] --> B[Azure CNI Overlay]
    A --> C[Azure CNI Pod Subnet]
    A --> D[Kubenet]
    B --> E[Large pod density with overlay addressing]
    C --> F[Direct VNet-routable pod IPs]
    D --> G[Legacy route-table based model]
    A --> H[Dataplane Choice]
    H --> I[kube-proxy oriented dataplane]
    H --> J[Azure CNI Powered by Cilium]

Comparison summary¶

Model	Pod IP Behavior	Best Fit	Main Caution
Azure CNI Overlay	Pods use overlay addresses while nodes stay in VNet	Most new AKS clusters	Requires understanding overlay routing behavior
Azure CNI Pod Subnet	Pods get IPs from delegated subnets	Deep VNet integration and direct routability	Subnet sizing becomes critical
Kubenet	Pods use private address space with NAT through nodes	Legacy or transitional clusters only	Retirement planning and migration constraints matter

CNI selection decides pod addressing and routability. Outbound networking decides how traffic leaves the cluster and who owns SNAT capacity. After choosing the CNI model, review Outbound Networking for loadBalancer, NAT Gateway, and UDR decisions.

Dataplane choice after the CNI mode comparison¶

The IP model answers where pod IPs come from. The dataplane answers how packets are forwarded and how policy is enforced on the node.

Common operator combinations¶

IP model	Typical dataplane posture	Notes
Azure CNI Overlay	Often paired with Azure CNI Powered by Cilium	This is the default virtual-network posture for AKS Automatic
Azure CNI Pod Subnet	Can stay on a non-Cilium dataplane or move to Cilium	Useful when direct pod routability matters
Azure CNI Node Subnet	Can move to Cilium without changing IPAM mode	Still needs careful subnet planning
Kubenet	Cannot move directly to Cilium dataplane	Must migrate to Azure CNI Overlay first

Practical decision rule¶

If you are designing a new AKS platform, prefer choosing both the IP model and the dataplane deliberately up front.
If you are changing an existing cluster, remember that an IPAM migration and a dataplane migration are separate operations with separate blast radius.

What to decide early¶

Required pod-to-VNet routability.
Subnet size and IP growth model.
Network policy engine and private-cluster requirements.
Whether the organization standardizes on overlay for simpler IP planning.
Whether the cluster should adopt Azure CNI Powered by Cilium now or only as part of a later migration.

Example cluster creation¶

az aks create \
    --resource-group "$RG" \
    --name "$CLUSTER_NAME" \
    --location "$LOCATION" \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --pod-cidr 192.168.0.0/16 \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --generate-ssh-keys

Command	Purpose
`az aks create`	Create a Cilium cluster with explicit service networking.
`--resource-group`	Resource group that contains the AKS cluster.
`--name`	Name of the AKS cluster.
`--location`	Azure region for the cluster.
`--network-plugin`	Container networking plugin.
`--network-plugin-mode`	Network plugin mode such as overlay.
`--network-dataplane`	Dataplane technology, Cilium for eBPF.
`--pod-cidr`	CIDR range for pod addresses.
`--service-cidr`	CIDR range for Kubernetes services.
`--dns-service-ip`	Cluster DNS service IP inside the service CIDR.
`--generate-ssh-keys`	Generate SSH keys if none are provided.

Confirm the active network profile¶

az aks show \
    --resource-group "$RG" \
    --name "$CLUSTER_NAME" \
    --query "networkProfile.{plugin:networkPlugin,mode:networkPluginMode,dataplane:networkDataplane,policy:networkPolicy,serviceCidr:serviceCidr,dnsServiceIp:dnsServiceIP}" \
    --output yaml

Command	Purpose
`az aks show`	Show the full network profile including service CIDR.
`--resource-group`	Resource group that contains the AKS cluster.
`--name`	Name of the AKS cluster.
`--query`	Selects plugin, dataplane, policy, and service networking.
`--output`	Output format for the result.