How Does Kubernetes Really Handle Networking? A Deep Dive

Container‑to‑Container Networking

Kubernetes runs distributed clusters, making networking a core component. In Linux each process runs in a network namespace that provides its own routing, firewall rules, and network devices, effectively giving every namespace a separate network stack.

Network namespaces can be created with the ip command, e.g.: $ ip netns add ns1 The namespace appears under /var/run/netns and can be listed with:

$ ls /var/run/netns
ns1
$ ip netns list
ns1

Docker implements a pod as a group of containers sharing a network namespace, so all containers in a pod have the same IP address and can reach each other via localhost.

The root network namespace connects to each pod’s namespace via a virtual Ethernet (veth) pair. One end of the pair is placed in the root namespace, the other in the pod’s namespace, and a Linux bridge links all veth ends together.

Pod‑to‑Pod Networking

Each pod receives a unique IP address and communicates directly with other pods. On the same node, pods are linked through veth pairs and a bridge (cbr0). The bridge learns MAC addresses via ARP and forwards frames accordingly.

When a pod sends a packet, it travels from its eth0 to the veth pair, reaches the bridge, and the bridge forwards it to the destination pod’s veth pair, ultimately arriving at the destination pod’s eth0.

Across different nodes, each node is allocated a CIDR block for its pods. Packets destined for a pod’s IP are routed to the node that owns the corresponding CIDR, then delivered via the same bridge/veth mechanism.

Pod‑to‑Service Communication

Kubernetes Service objects provide a stable virtual IP (ClusterIP) that load‑balances traffic to a set of pods. The kube‑proxy component programs iptables (or IPVS) rules so that packets sent to the Service VIP are DNAT‑ed to a selected pod IP.

netfilter and iptables

iptables uses the netfilter framework to rewrite packet headers. When a Service is created, kube‑proxy adds rules that match the Service VIP, select a backend pod, and change the destination IP to that pod’s IP. The conntrack subsystem records the mapping so that return traffic is rewritten back to the Service VIP.

IPVS

IPVS, built on netfilter, provides kernel‑level load balancing with hash tables for higher scalability. When kube‑proxy runs in IPVS mode, a virtual IPVS interface is created per Service, and IPVS servers are added for each backend pod.

External Traffic to Services

To expose services outside the cluster, two common approaches are used: LoadBalancer services and Ingress controllers.

LoadBalancer

In cloud environments (e.g., AWS), a LoadBalancer service creates a cloud load balancer that forwards traffic to node ports. iptables on each node then routes the traffic to the appropriate pod, with conntrack handling return‑path NAT.

Ingress Controller

An Ingress object provides HTTP/HTTPS routing based on URL paths. The Ingress controller creates an external load balancer (e.g., AWS ALB) that forwards traffic to node ports, where iptables again directs it to the correct pod.

Summary

The Kubernetes networking model ties together Linux network namespaces, virtual Ethernet devices, bridges, iptables/IPVS, and cloud load‑balancing components to enable container‑to‑container, pod‑to‑pod, pod‑to‑service, and external traffic flows. While the topic is broad, this overview provides a foundation for deeper exploration.