The Kubernetes Networking Model
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.
# 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.
Practice what you learned
1. Which of the following is NOT one of the four core Kubernetes networking requirements?
2. How do containers within the same Pod typically communicate with each other?
3. What is the role of kube-proxy in the networking model?
4. Why does NetworkPolicy have no effect on traffic between two containers in the same Pod?
5. What distinguishes overlay networking (e.g. VXLAN) from direct BGP-based routing in a CNI plugin?
Was this page helpful?
You May Also Like
Services In Depth
How Kubernetes Services provide stable virtual IPs over dynamic Pod sets, covering all four Service types, EndpointSlices, and headless Services.
Network Policies
How Kubernetes NetworkPolicy locks down the default flat, open Pod network using default-deny baselines, selector-based rules, and CNI-dependent enforcement.
Ingress Controllers
How Ingress resources describe HTTP routing rules and how Ingress controllers like NGINX, Traefik, and cloud ALB controllers actually fulfill them, including TLS and multi-controller setups.
Service Mesh Basics with Istio
How Istio's sidecar-based service mesh delivers mutual TLS, traffic shaping, and observability transparently, covering its control/data plane split and key resources.