Kubernetes Networking Model — The Flat Network

The IP-per-Pod Model

In traditional container environments (like default Docker bridge networking), containers on the same host share private subnets, but communicating across hosts requires mapping ports to host interfaces and routing packets through Network Address Translation (NAT). This adds routing overhead and makes dynamic scheduling difficult to coordinate.

Kubernetes solves this by establishing a **Flat Network** model (also called the **IP-per-Pod** model). In this model, every Pod in the cluster is assigned a unique, routable IP address. Pods behave exactly like physical hosts or VMs on a shared Local Area Network (LAN).

Three Core Networking Rules

To achieve this flat topology, the underlying cluster network must guarantee three rules:

• All Pods can communicate with all other Pods on any node without using Network Address Translation (NAT).
• All system agents running on a node (such as the kubelet) can communicate with all Pods on that node.
• The IP address a Pod sees as its own address is the exact same IP address that other Pods resolve it to.

How CNI Plugins Configure the Network

Kubernetes defines the networking rules but delegates the actual execution to **CNI (Container Network Interface)** plugins. CNI plugins (like Calico, Flannel, or Cilium) manage IP allocations and write routing rules:

• Overlay Networks (VXLAN / Geneve): Plugins like Flannel encapsulate Pod network packets inside standard UDP packets to cross physical host interfaces, creating an overlay network on top of physical infrastructure.
• Direct Routing (Calico / BGP): Calico can write routes directly to host routing tables using the Border Gateway Protocol (BGP). This routes packets at wire speed without encapsulation overhead.