How Does Kubernetes Networking Really Work? A Deep Dive into Pod Communication

If you have already used Kubernetes and run tests or production services, you may have felt the revolutionary impact of K8s; if you haven’t, you should start quickly as it is a technology trend.

Although many tools exist to set up and manage clusters, understanding what happens under the hood is essential, especially when troubleshooting problems.

Kubernetes is complex at its core with many components, and its networking is one of the most intricate and critical parts.

Kubernetes Network Model

Kubernetes networking is based on a fundamental design principle: Each Pod has a unique IP. This Pod IP is shared by all containers in the Pod and is routable to every other Pod. The “pause” container, also called a sandbox container, holds the network namespace (netns) for the Pod, ensuring the IP remains constant even if containers are recreated.

Kubernetes requires that these Pod IPs be reachable from all other Pods, regardless of the node they reside on.

Intra‑node Communication

The first step is to ensure Pods on the same node can communicate, then extend this to cross‑node and Internet communication.

Each Kubernetes node (a Linux machine) has a root network namespace (root netns). The primary network interface eth0 lives in this root netns.

Each Pod also has its own network namespace and is connected to the root network via a virtual Ethernet pair (veth). The Pod‑side interface is named eth0, while the host‑side appears as vethXXX.

You can list these interfaces with ifconfig or ip a.

All Pods on the node are linked by the Linux bridge cbr0, similar to Docker’s docker0 bridge. brctl show lists the bridge.

When a packet travels from pod1 to pod2 on the same node, the steps are:

It leaves pod1 via its eth0 and enters the host‑side veth pair.

The packet is handed to bridge cbr0, which uses ARP to discover the destination IP.

The appropriate veth interface (vethYYY) claims the IP, so the bridge forwards the packet.

The packet traverses the veth pair and arrives at pod2’s network namespace.

This illustrates the simplest intra‑node communication path.

Inter‑node Communication

Pods must also be reachable across nodes. Kubernetes itself does not dictate how this is achieved; it can use L2 (ARP) or L3 (IP routing) overlay networks, and cloud provider routing tables usually handle cross‑node traffic.

Each node is allocated a unique CIDR block for its Pod IPs, ensuring no overlap.

In most cloud environments, the provider’s routing tables ensure packets reach the correct destination node. Proper routing configuration on each node can achieve the same result, and many CNI plugins implement these mechanisms.

Consider two nodes, each with its own network namespaces, interfaces, and bridges.

When a packet moves from pod1 on node1 to pod4 on node2, the process is:

It leaves pod1 via eth0 and enters the host‑side veth pair.

The packet reaches bridge cbr0, which ARPs for the destination.

Since node1 lacks pod4’s IP, the packet is sent to the node’s primary interface eth0.

The packet exits node1 with src=pod1 and dst=pod4.

Node routing tables, configured with each node’s CIDR, forward the packet toward the node whose CIDR contains pod4’s IP.

Upon reaching node2, the packet arrives at eth0; IP forwarding sends it to cbr0, which ARPs and discovers the veth interface for pod4.

The bridge forwards the packet, which traverses the veth pair into pod4.

This covers the fundamentals of Kubernetes networking.