How Does Kubernetes Networking Really Work? A Visual Deep Dive

If you have already used Kubernetes for testing or production services, you may have felt its revolutionary impact; if you haven’t, you should start quickly because it is a clear technology trend.

Although many tools exist to set up and manage clusters, understanding what happens under the hood—especially the network—is essential for troubleshooting and solving real problems.

Kubernetes Network Model

The core design principle of Kubernetes networking is that each Pod has a unique IP address shared by all containers in the Pod and routable to every other Pod. 每个Pod都有唯一的IP。 These IPs are kept in a sandbox (pause) container that preserves the network namespace, so the IP remains stable even if containers are recreated. The only requirement is that every Pod IP must be reachable from all other Pods, regardless of the node they run on.

Intra‑Node Communication

Each Kubernetes node (a Linux machine) has a root network namespace with the primary interface eth0. Every Pod gets its own network namespace and a virtual Ethernet pair (veth) that connects the Pod namespace to the root namespace. One end of the pair appears as eth0 inside the Pod, while the other end has a name like vethxxxx.

The Linux bridge cbr0 (similar to Docker’s docker0) links all these veth interfaces, allowing Pods on the same node to communicate.

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

Retain the packet in pod1 's eth0 and the root namespace side in vethxxx.

Pass it to cbr0, which uses ARP to discover the destination IP.

The bridge learns that vethyyy owns the destination IP.

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

Inter‑Node Communication

Pods must also be reachable across nodes. Kubernetes does not dictate the mechanism; it can be L2 (ARP) or L3 (IP routing) overlays, or any CNI plugin. Each node is assigned a unique CIDR block for Pod IPs, ensuring no IP conflict between nodes.

In cloud environments, the cloud provider’s routing tables usually handle cross‑node traffic. Proper routing on each node directs packets to the node that owns the destination Pod’s CIDR.

When a packet travels from pod1 on node 1 to pod4 on node 2, the process is:

Retain the packet in pod1 's eth0 and the root side in vethxxx.

Pass it to cbr0, which ARPs for the destination.

Since the destination IP is not on node 1, the packet is forwarded to the node’s primary interface eth0.

The packet leaves node 1 with source pod1 and destination pod4.

The node’s routing table, configured with CIDR routes, forwards the packet toward the node whose CIDR contains pod4 's IP.

On node 2, the bridge receives the packet, ARPs, discovers the owning vethyyy, and forwards it through the veth pair to pod4.

This overview covers the fundamentals of Kubernetes networking.