How Does Kubernetes Really Handle Container Networking? A Deep Dive

Kubernetes is built for running distributed clusters, making networking a core component; understanding its network model helps you run, monitor, and troubleshoot applications.

Container-to-Container Network

In a typical VM network communication is seen as direct Ethernet, but in Linux each process runs in a network namespace that provides its own routing, firewall rules, and devices.

Linux users can create a namespace with the ip command, e.g.: $ ip netns add ns1 After creation a mount point appears under /var/run/netns, allowing the namespace to persist even without attached processes. List namespaces with ls /var/run/netns or ip netns.

By default, each process is placed in the root network namespace to access external networks.

In Kubernetes, a Pod is a group of Docker containers that share a network namespace, giving them the same IP address and port space. Containers join the namespace via the -net=container:sandbox-container option.

Pod-to-Pod Network

Each Pod has a real IP address and communicates with other Pods using that IP. Pods on the same node connect via virtual Ethernet (veth) pairs: one end in the root namespace, the other in the Pod's namespace. The veth pairs attach to a Linux bridge, which forwards traffic between Pods.

When a packet leaves Pod1, it travels from eth0 to its veth, reaches the bridge cbr0, which uses ARP to forward it to the veth of Pod2, and finally arrives at Pod2's eth0. All Pods see each other’s IPs directly.

Across nodes, each node is assigned a CIDR block for its Pods. Packets destined for a Pod IP are routed by the node’s routing table to the correct node, then delivered via the same bridge and veth mechanism.

Pod-to-Service

Pod IPs are dynamic; Services provide a stable virtual IP (VIP) that abstracts a set of Pods. kube‑proxy configures iptables rules so that traffic to the Service VIP is rewritten to a selected Pod IP. The reverse path uses conntrack to rewrite the source IP back to the Service VIP.

netfilter and iptables

Kubernetes relies on Linux netfilter. iptables rules created by kube‑proxy watch Service and Pod changes, translating Service VIPs to real Pod IPs and handling return traffic.

IPVS

Newer clusters can use IPVS, a kernel‑level load balancer built on netfilter, offering higher performance and larger scale than iptables.

External-to-Service Communication

Exposing Services outside the cluster involves two main challenges: routing traffic from the Service to the Internet and routing inbound traffic from the Internet to the Service.

Outbound Traffic

In cloud environments like AWS VPC, Nodes have private IPs and use a NAT gateway for Internet egress. Since Pods have their own IPs, iptables performs source NAT to replace the Pod IP with the Node’s IP before the packet reaches the NAT gateway.

Inbound Traffic

Two common solutions are LoadBalancer Services and Ingress controllers. A LoadBalancer Service creates a cloud load balancer that forwards traffic to node ports, where iptables routes it to the appropriate Pod. An Ingress controller operates at L7, mapping HTTP/HTTPS paths to Services, also using node ports and iptables for the underlying traffic.

Both LoadBalancer and Ingress rely on kube‑proxy’s iptables (or IPVS) rules and conntrack to correctly rewrite source and destination IPs on the return path.

Summary

This article introduced the Kubernetes network model and common networking tasks, providing a foundation for deeper exploration of topics such as CNI plugins, service discovery, and advanced load‑balancing techniques.