How Kubernetes Moves Packets: Inside Pods, CNI, and Network Namespaces

Kubernetes Network Requirements

Before diving into packet flow, Kubernetes defines three basic network rules: Pods can communicate with any other Pod without NAT, processes on a node can communicate with any Pod on that node without NAT, and each Pod has its own IP address reachable by all other Pods.

These requirements do not mandate a specific implementation; they merely describe the desired network characteristics.

Linux Network Namespaces in Pods

A Pod with two containers (busybox and nginx) is defined as:

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-Pod
spec:
  containers:
    - name: container-1
      image: busybox
      command: ['/bin/sh', '-c', 'sleep 1d']
    - name: container-2
      image: nginx

When the Pod is created:

The Pod receives its own network namespace on the node.

An IP address is assigned to the Pod, and the two containers share that address.

Both containers share the same network namespace and can see each other locally. Linux network namespaces are isolated logical spaces that contain their own interfaces, routing tables, firewall rules, and other network resources. The root network namespace holds the physical interfaces; each pod’s namespace is created on top of it. Namespaces can be listed with ip netns list and inspected with ip netns exec <ns> ip a .

Created network namespaces appear under /var/run/netns , and CNI plugins create files such as cni-xxxx .

Pause Container Creates the Network Namespace

Every Pod has an additional hidden container called the pause container. It holds the network namespace while other containers join it. Listing containers on a node shows a pause container for each Pod:

$ docker ps | grep pause
fa9666c1d9c6   k8s.gcr.io/pause:3.4.1   "/pause"   k8s_POD_kube-dns-...
...

The container runtime (containerd or CRI‑O) creates the namespace before the user containers start; manual ip netns commands are not required.

Assigning an IP Address to a Pod

The Pod’s IP can be retrieved with:

$ kubectl get pod multi-container-Pod -o jsonpath={.status.podIP}
10.244.4.40

On the node, the corresponding network namespace file (e.g., cni-0f226515‑e28b‑df13‑9f16‑dd79456825ac ) can be inspected:

$ ip netns exec cni-0f226515-e28b-df13-9f16-dd79456825ac ip a
3: eth0@if12: ... inet 10.244.4.40/32 ...

The veth pair connects the pod namespace to the root namespace; the host side of the pair is attached to a bridge.

Pod‑to‑Pod Traffic

Two cases exist: communication on the same node and across different nodes. On the same node, the pod’s eth0 sends packets through its veth peer to the root namespace, where a bridge forwards them to the destination pod after ARP resolves the MAC address. Across nodes, the packet is first sent to the node’s default gateway; the gateway forwards it to the remote node, where the same bridge and veth mechanisms deliver it to the target pod.

Virtual Ethernet (veth) Pairs and Bridges

A veth pair acts as a tunnel between two namespaces. One end resides in the pod namespace, the other in the root namespace. The root ends of all pod veths are attached to a Linux bridge, which functions as a virtual switch.

$ ip link add veth1 netns pod-ns type veth peer name veth2 netns root

The bridge enables pods on the same node to exchange traffic without leaving the host.

Container Network Interface (CNI)

CNI plugins automate the steps above. Popular implementations include Calico, Cilium, Flannel, and Weave Net. CNI supports four commands: ADD, DEL, CHECK, and VERSION. When a pod is scheduled, kubelet hands a JSON configuration to the CNI plugin, which then creates the namespace, veth pair, assigns an IP, and updates the bridge. Example Calico configuration file ( /etc/cni/net.d/10-calico.conflist ) shows the plugin type, IPAM settings, and additional capabilities.

Pod‑to‑Service Traffic

Services provide a stable virtual IP (ClusterIP) that maps to a set of pods. iptables/netfilter rules perform DNAT to rewrite the service IP to the target pod’s IP, and conntrack ensures the return path is SNAT‑ed back to the service IP. # iptables-save The NAT rules are applied in the PRE_ROUTING chain (DNAT) and POST_ROUTING chain (SNAT).

Conntrack tracks connections so that responses are correctly routed back to the original client.

Summary

How containers communicate within a pod and across pods.

Pod‑to‑pod traffic on the same node and across nodes.

Pod‑to‑service flow using iptables, netfilter, and conntrack.

Key concepts: network namespaces, veth pairs, bridges, CNI plugins, overlay networks, and Linux networking tools.