How Does Kubernetes Enable Container‑to‑Container Networking? A Deep Dive

Kubernetes relies on plug‑in based container networking, requiring three basic principles: pods on any node must communicate directly without NAT, nodes and pods must be able to talk to each other, and each pod must have an independent network stack shared by its containers.

Container Network Basics

A Linux container’s network stack lives in its own network namespace, which includes a network interface, loopback device, routing table, and iptables rules. Key Linux features for container networking are network namespaces, veth pairs, iptables/netfilter, bridges, and routing.

On a single host, Docker creates a docker0 bridge and connects each container via a veth pair. The container’s eth0 is one end of the veth pair, while the other end appears on the host and is attached to docker0. Routing tables show eth0 as the default gateway, directing traffic for the 172.17.0.0/16 subnet.

docker run -d --name c1 hub.pri.ibanyu.com/devops/alpine:v3.8 /bin/sh

docker exec -it c1 /bin/sh
# ifconfig
# route -n

Launching a second container and pinging its IP demonstrates that packets are forwarded through the bridge after an ARP broadcast resolves the destination MAC address.

For cross‑host communication, Docker’s default setup cannot connect containers on different hosts. Kubernetes introduces the CNI (Container Network Interface) API, allowing plugins such as Flannel, Calico, Weave, and Contiv to provide network connectivity.

Cross‑Host Networking Models

CNI plugins implement three models:

Overlay: uses tunnels (e.g., VXLAN, IPIP) to encapsulate container traffic, independent of the underlying network.

Layer‑3 routing: relies on routing tables without tunnels, requiring the hosts to be on the same L2 network.

Underlay: leverages the existing L3 network directly, without creating bridges.

Flannel’s host‑gw mode configures a route on each node pointing to the pod subnet of the destination node, avoiding encapsulation overhead but requiring L2 connectivity between nodes. 10.244.1.0/24 via 10.168.0.3 dev eth0 Calico uses BGP to distribute routing information. Its components include the Calico CNI plugin, Felix (maintains host routes), BIRD (BGP daemon), and Confd (configuration manager). Instead of a bridge, Calico creates a veth pair for each pod and installs a host route for the pod’s IP. 10.92.77.163 dev cali93a8a799fe1 scope link Calico’s default node‑to‑node mesh scales quadratically with node count, so for clusters larger than ~50 nodes a Router‑Reflector (RR) topology is recommended to reduce BGP peer connections.

When nodes are on different L2 segments, Calico can fall back to IPIP overlay mode, encapsulating traffic in a tunnel device ( tunnel0) before routing it to the destination node.

In summary, Kubernetes networking can be built on Docker’s bridge for single‑host scenarios, while cross‑host connectivity is achieved through CNI plugins employing overlay, host‑gw, or underlay strategies, each with trade‑offs in performance and complexity.