How Kubernetes Achieves Pod Networking: IPAM, Native Routing, Overlay, and BGP Explained

Preface

Network is the foundation of container communication. Kubernetes only defines two basic requirements: pods can communicate across nodes without NAT, and node agents can talk to all pods on that node.

IPAM

Kubernetes requires each pod to have a unique IP address; IP Address Management (IPAM) is responsible for allocating these IPs and is a core part of CNI plugins. A common IPAM approach assigns a CIDR block to each node and then allocates pod IPs from that block.

apiVersion: v1
kind: Node
metadata:
  name: node01
spec:
  podCIDR: 192.168.1.0/24
  podCIDRs:
  - 192.168.1.0/24
---
apiVersion: v1
kind: Node
metadata:
  name: node02
spec:
  podCIDR: 192.168.2.0/24
  podCIDRs:
  - 192.168.2.0/24

Thus node01 provides pod IPs 192.168.1.1‑192.168.1.254, and node02 provides 192.168.2.1‑192.168.2.254.

Linux VETH & Bridge

After a pod receives an IP, Linux uses virtual Ethernet (veth) pairs and a bridge (cni0 or docker0) to connect the pod’s network namespace to the host namespace. Direct veth connections work for pods on the same node, but scaling across many pods requires a bridge to avoid a combinatorial explosion of veth pairs.

Overlay Networks

If the underlying node network cannot route pod IPs, an overlay such as VXLAN encapsulates the original pod packet inside an outer Ethernet frame with the node’s IP. The encapsulated packet traverses the node network and is decapsulated at the destination node, enabling cross‑node pod communication.

BGP

For multi‑cluster or hybrid‑cloud scenarios where pods must be reachable from outside the cluster, Border Gateway Protocol (BGP) can advertise pod CIDRs as routes. Treating the cluster as an autonomous system allows external routers to learn pod prefixes, but BGP lacks programmable data‑path control and is generally not recommended for intra‑cluster networking.

Conclusion

The article covered three CNI networking models: Native‑Routing (requires routable pod IPs), Overlay (VXLAN/IP‑in‑IP), and BGP‑based routing. Native‑Routing works only when the underlying network can route pod IPs; otherwise most CNI plugins fall back to overlay encapsulation methods. In complex scenarios, BGP can provide external pod reachability.