CNI and Pod Networking

The Container Network Interface and Pod Networking

Kubernetes 5,150 requires that every Pod has its own IP and can reach every other Pod without NAT. The Container Network Interface (CNI) defines how the runtime asks a plugin to wire up a sandbox: containerd 234,762 reads a configuration from /etc/cni/net.d and runs plugin binaries from /opt/cni/bin with ADD and DEL. The controller manager gives each node one /24 of the cluster CIDR 10.244.0.0/16:

kind's CNI configuration and the routes it produces on the workerShell

docker exec l3-booknest-worker cat /etc/cni/net.d/10-kindnet.conflist \
  | jq -c '.plugins[] | {type, ipam: .ipam.type, subnet: .ipam.ranges[0][0].subnet}'
docker exec l3-booknest-worker ip route

Output

{"type":"ptp","ipam":"host-local","subnet":"10.244.1.0/24"}
{"type":"portmap","ipam":null,"subnet":null}
default via 172.18.0.1 dev eth0 
10.244.0.0/24 via 172.18.0.2 dev eth0 
10.244.1.26 dev veth7d2cd07c scope host 
10.244.1.27 dev vethe264c571 scope host 
172.18.0.0/16 dev eth0 proto kernel scope link src 172.18.0.3

The ptp plugin gives each Pod one end of a veth pair and puts a /32 host route to it on the node; the host-local IPAM plugin hands out addresses from the node's /24; portmap implements hostPort. kindnetd, running on every node, adds one route per other node (10.244.0.0/24 via 172.18.0.2): because all kind 14,561 nodes share one Docker 514 network, plain routing is enough, with no overlay or encapsulation.

Pod networking in the kind cluster: per-node /24s, veth pairs and node-to-node routes

Where networks do not route Pod CIDRs, plugins tunnel Pod traffic over VXLAN or Geneve, or program cloud routing (the AWS 24 VPC CNI gives Pods real VPC addresses).

MENU