Network Models
Azure Kubernetes Service (AKS) supports multiple networking models that determine how pods are assigned IP addresses and how traffic flows within and outside the cluster. Choosing the right model is critical — it affects scalability, performance, IP address management, and integration with other Azure services.
At a high level, AKS supports two primary networking models:
- Flat Networking: Pods receive IP addresses directly from the Azure Virtual Network (VNet).
- Overlay Networking: Pods receive IPs from a separate, private CIDR that is overlaid on top of the VNet.
Each model is implemented through a specific Container Network Interface (CNI) plugin, and each has its own strengths and trade-offs.
Flat Networking
In flat networking, each pod is assigned an IP address from the same address space as the VNet. This means:
- Pods are directly routable from other Azure resources.
- No Source Network Address Translation (SNAT) is required for outbound traffic.
- Easier integration with on-premises networks or services that need to reach pods directly.
Flat networking is implemented using the Azure CNI plugin, in the Azure CNI with Pod Subnet mode. This mode allows pods to receive IPs from a dedicated subnet within the VNet, which is separate from the node subnet.
Benefits:
- Simplified IP management, as pods receive IPs from the VNet directly.
- No need for additional overlay networking components.
Considerations:
- Requires careful IP planning to avoid exhaustion.
- Can be limited by subnet size and Azure IP address constraints.
Overlay Networking
Overlay networking introduces a virtual network layer on top of the Azure VNet. Pods are assigned IPs from a private CIDR that is not part of the VNet address space. Traffic is encapsulated and routed through the Azure SDN fabric.
This model is implemented using the Azure CNI plugin in one of its overlay modes:
- Azure CNI Overlay
- Azure CNI Powered by Cilium
Benefits:
- Greatly reduces IP consumption from the VNet.
- Scales to thousands of nodes and tens of thousands of pods.
- No need for custom route tables (UDRs).
Considerations:
- Pod IPs are not directly accessible from outside the cluster.
- SNAT is required for outbound traffic.