The Kubernetes Networking Model

Analogy categoryAnalogies

Kubernetes does not invent a new networking protocol; instead it imposes a small set of strict rules on top of ordinary IP networking so that every component in the cluster can reason about addresses the same way. Every Pod gets its own IP address, and that address is expected to be reachable from every other Pod in the cluster without any manual NAT configuration.

🏏

Cricket analogy: It's like every player on a franchise squad getting a fixed shirt number for the season, e.g. Kohli always 18, so commentators and teammates can identify and reach anyone on the field without checking a roster every over.

The Four Fundamental Requirements

The Kubernetes networking model is defined by four requirements that any Container Network Interface (CNI) plugin must satisfy: all Pods can communicate with all other Pods without NAT, all Nodes can communicate with all Pods without NAT, the IP a Pod sees itself as is the same IP others see it as, and containers within a Pod share a single network namespace so they can reach each other over localhost. Plugins like Calico, Cilium, and Flannel implement these guarantees differently, using overlay networks, BGP peering, or eBPF, but the API contract they expose to workloads is identical.

🏏

Cricket analogy: It's like the ICC mandating that every international ground must have the same pitch dimensions and boundary rules, so a bowler's yorker means the same thing whether the match is in Mumbai or Melbourne, even though groundskeepers prepare each pitch differently.

Pod-to-Pod Communication and the CNI

When a new Pod is scheduled, the kubelet invokes a CNI plugin binary to allocate an IP from the cluster's Pod CIDR and wire up the Pod's network namespace with a virtual ethernet pair connected to a bridge or overlay on the node. From that point on, packets between Pods on different nodes typically travel either through an overlay encapsulation like VXLAN, which wraps the original packet in a UDP packet for tunneling, or through direct routing where the CNI programs the node's routing table and relies on BGP so the underlying network fabric already knows how to reach each Pod CIDR block.

🏏

Cricket analogy: It's like how a franchise's support staff registers a new overseas signing with the BCCI before the auction window closes, issuing them a player ID and slotting them into the squad list so the whole league can now recognize and schedule them for matches.

yaml

# Example Calico IPPool defining the Pod CIDR used by the CNI plugin
apiVersion: projectcalico.org/v3
kind: IPPool
metadata:
  name: default-ipv4-ippool
spec:
  cidr: 10.244.0.0/16
  ipipMode: Always      # encapsulate cross-node traffic in IP-in-IP
  natOutgoing: true      # NAT Pod traffic leaving the cluster to the internet
  nodeSelector: all()

Container-to-Container Communication Within a Pod

Containers within the same Pod share a single network namespace, which means they share one IP address and one port space, and can talk to each other over localhost exactly as if they were separate processes on the same machine. This is why a sidecar container, such as an Envoy proxy injected by a service mesh, can intercept traffic on 127.0.0.1 before it leaves the Pod, and why you can never run two containers in the same Pod that both bind to the same port.

🏏

Cricket analogy: It's like a batting partnership at the crease, both batters share the same run count and strike rotation and can call a quick single to each other instantly without needing to relay through the dressing room.

Because localhost communication inside a Pod never leaves the network namespace, it bypasses NetworkPolicy enforcement entirely; policies only govern traffic that crosses Pod boundaries, so a compromised sidecar can always talk to its own app container regardless of any policy you write.

kube-proxy and Cluster-Wide Reachability

The Pod network alone only gets you point-to-point reachability; kube-proxy is the component that watches the API server for Service and Endpoint objects and programs each node's packet-forwarding rules, historically via iptables chains and increasingly via IPVS or eBPF in modern distributions, so that traffic sent to a stable Service ClusterIP gets load-balanced across the current set of healthy backing Pods. This layer is what lets a client Pod keep talking to a single virtual IP even as the real Pods behind it are rescheduled, scaled, or replaced during a rolling update.

🏏

Cricket analogy: It's like a stadium's PA announcer always calling out to whichever wicketkeeper is currently on the field by role, 'keeper', rather than by name, so the announcement stays valid even when a substitute keeper takes the gloves mid-match.

Legacy iptables-mode kube-proxy scales linearly with the number of Services and Pods, and on clusters with tens of thousands of Services, rule evaluation can add meaningful latency and CPU overhead per packet; IPVS or eBPF-based dataplanes (e.g. Cilium replacing kube-proxy entirely) are strongly recommended for large clusters.

Every Pod gets a unique, routable IP; Pod-to-Pod traffic must never require NAT.
The CNI plugin (Calico, Cilium, Flannel, etc.) implements the networking model, typically via overlay encapsulation (VXLAN, IP-in-IP) or direct BGP routing.
Containers within one Pod share a network namespace and can reach each other over localhost, sharing the same port space.
kube-proxy programs iptables, IPVS, or eBPF rules so Service ClusterIPs load-balance traffic across live backend Pods.
The 'IP a Pod sees itself as' rule guarantees no hidden NAT confuses applications that log or bind to their own address.
NetworkPolicy only governs traffic crossing Pod boundaries; intra-Pod localhost traffic is never policy-enforced.