Azure CNI or Kubenet: The AKS Networking Decision You Can't Walk Back

Here is a sentence that has cost more weekend migrations than almost any other in AKS: "we'll figure out networking later." You can resize node pools later. You can swap ingress controllers later. You cannot change a cluster's CNI later, not without building a new cluster and moving everything to it.

So this is the decision to slow down for.

What you're actually choosing

Azure CNI gives every pod a real IP address from your virtual network. Pods are first-class citizens of the VNet: directly routable, reachable from peered networks, visible to Azure-native firewalls and network appliances. The cost is arithmetic: every pod consumes a VNet IP, and you must size your subnets for nodes times max-pods-per-node, not just node count. Get the subnet too small and you can't add nodes, which is a spectacular way to discover capacity limits during an incident.

Kubenet is thrifty. Nodes get VNet IPs; pods get addresses from a separate, overlay-style range and NAT out through the node. You burn far fewer real IPs. The cost is capability: pods aren't directly routable from outside, some Azure networking features and appliances don't see pod IPs cleanly, and you inherit user-defined routes that get fiddly at scale.

The CNI question is really an IP-address-planning question wearing a technical costume.

How to actually decide

Walk these in order; stop at the first one that forces your hand.

1. Do pods need to be directly reachable from the VNet or peered networks? On-prem systems connecting in, Azure firewalls inspecting pod traffic, service-to-service across VNets, if yes, you want Azure CNI. NAT'd pods make these painful or impossible.
2. Do you have the IP space? Azure CNI's appetite is real. Count nodes × max-pods at your peak, add headroom for upgrades (which surge extra nodes), and confirm your subnet, and your overall VNet plan, can absorb it. If your address space is already tight, that constraint may make the decision for you.
3. Do you need Azure Network Policy, or are you fine with Calico? Your CNI choice shapes which network-policy engines are available. Decide your policy story now, not after a security review demands one.

For most teams building production platforms that integrate with the rest of their Azure estate, Azure CNI (and increasingly its overlay mode, which buys back much of the IP thrift without losing routability) is the default worth defending. Reach for plain kubenet when the cluster is genuinely standalone and IP space is the binding constraint.

The trap inside the trap

Even teams that pick Azure CNI often under-size the subnet because they planned for steady-state node count and forgot that upgrades and scale-out events surge additional nodes, each demanding its full pod-IP allotment at once. The cluster runs fine for months, then refuses to upgrade because there aren't enough IPs to stand up the surge node. Plan for the peak, not the average.

The takeaway

Almost everything in AKS networking is a dial you can turn later. The CNI is a door you walk through once. Treat it like the architectural decision it is: start from your IP plan and your integration needs, decide deliberately, and write down why, because the person who inherits this cluster will want to know.