Inside Kubernetes: How Containers Talk via Network Namespaces, Veth Pairs & CNI

Container Network Basics

In Kubernetes, container communication depends on the Linux network stack, which is isolated in a separate network namespace containing a network interface, loopback device, routing table, and iptables rules.

Pods on any node can communicate directly without NAT.

Nodes and pods can talk to each other, and pods can access any network.

Each pod has its own network stack; the address seen inside the pod is the same as seen from outside, and all containers in a pod share the same stack.

The essential Linux networking features for container networking are:

Network Namespace : isolates a complete network protocol stack.

Veth Pair : a pair of virtual Ethernet devices that connect two network namespaces.

Iptables/Netfilter : kernel‑level packet filtering and manipulation.

Bridge : a layer‑2 virtual device that forwards frames based on MAC addresses, similar to a switch.

Routing : Linux uses routing tables to decide where to forward IP packets.

On a single host, Docker creates the docker0 bridge. Containers attached to this bridge communicate through it using a veth pair on each side.

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

Inspecting the container’s interfaces shows the eth0 veth device:

# docker exec -it c1 /bin/sh
/ # ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:AC:11:00:02
          inet addr:172.17.0.2  Bcast:172.17.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500
# route -n
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.17.0.1      0.0.0.0         UG    0      0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0

On the host, the other end of the veth pair appears as a virtual interface (e.g., veth20b3dac) attached to docker0:

# brctl show
docker0        8000.02426a4693d2    no        veth20b3dac

Two containers on the same host can ping each other because the destination IP matches a direct route (gateway 0.0.0.0) and the bridge forwards the frames at layer 2 after an ARP lookup.

Cross‑Host Network Communication

Docker’s default setup cannot reach containers on different hosts. Kubernetes solves this with the CNI (Container Network Interface) API, allowing various plugins (Flannel, Calico, Weave, Contiv, etc.) to provide cross‑host networking.

CNI plugins typically replace the docker0 bridge with a dedicated cni0 bridge (overlay mode) or use routing without a bridge (host‑gw and underlay modes).

Overlay : encapsulates the entire container network over the underlying network (e.g., Flannel VXLAN, Calico IPIP).

Host‑gw : each node adds a route to every pod CIDR; traffic stays in layer 2, requiring the hosts to be on the same LAN.

Underlay : pods keep their own IPs; routes are installed on the host without a bridge, relying on the underlying network (e.g., Calico BGP).

Flannel host‑gw example:

When a pod on node1 sends traffic to a pod on node2, the node’s routing table contains an entry such as: 10.244.1.0/24 via 10.168.0.3 dev eth0 Calico’s architecture consists of the CNI plugin, felix (maintains host routes), BIRD (distributes routes via BGP), and confd (configuration management). Calico does not create a bridge; instead, it installs a route for each pod’s veth pair on the host: 10.92.77.163 dev cali93a8a799fe1 scope link Calico uses BGP to share routing information among all nodes (node‑to‑node mesh). In large clusters, a Route Reflector (RR) topology is recommended to reduce the O(N²) BGP sessions.

If the hosts are not on the same layer‑2 network, Calico can fall back to IPIP encapsulation (overlay) by adding a tunnel route: 10.92.203.0/24 via 10.100.1.2 dev tunnel0 Thus, Kubernetes networking can be implemented with simple bridge‑based Docker networking, Flannel host‑gw for small LANs, or Calico with BGP for larger, more flexible deployments.

References

https://github.com/coreos/flannel/blob/master/Documentation/backends.md

https://coreos.com/flannel/

https://docs.projectcalico.org/getting-started/kubernetes/

https://www.kancloud.cn/willseecloud/kubernetes-handbook/1321338