The Network Model
Kubernetes networking rests on one promise: every Pod gets its own IP address, and every Pod can reach every other Pod directly, without network address translation. That flat model is simple to state and is the foundation everything else — Services, DNS, policies — builds on.
Understanding the model first saves enormous confusion later. Once you accept "every Pod is a first-class network citizen with its own IP," the rest of Kubernetes networking stops looking like magic and starts looking like consequences.
The Flat-Network Promise
Kubernetes requires that the network satisfy a few rules: every Pod has a unique IP; Pods on any node can communicate with Pods on any other node without NAT; and agents on a node (like the kubelet) can reach Pods on that node. There is no port mapping and no per-node address juggling — a Pod's IP is the same whether you reach it from the same node or across the cluster.
This is a deliberate departure from the single-host Docker model, where containers share the host's IP and you publish ports. At cluster scale that bridging becomes unmanageable, so Kubernetes flattens it: the Pod, not the node, is the addressable unit.
The Four Kinds of Traffic
It helps to separate the conversations. Pod-to-Pod is the flat network above — direct, by Pod IP. Pod-to-Service goes through a stable virtual IP that kube-proxy redirects to a backing Pod (Topic 08). External-to-Service comes in via NodePort, LoadBalancer, or Ingress. Pod-to-external leaves the cluster, usually source-NATed to a node IP. Most networking questions are really about which of these four you are looking at.
IP Allocation
Each node is assigned a slice of a cluster-wide Pod CIDR, and Pods on that node draw IPs from its slice. Services draw from a separate Service CIDR. The sizes of these ranges cap how many Pods and Services a cluster can hold — and on clouds where Pods take real VPC IP addresses, IP exhaustion is a genuine scaling limit you must plan for, not an afterthought.
Who Implements the Model
Kubernetes defines the model but does not implement it. That job belongs to a CNI plugin (Topic 22), which wires each Pod's network namespace, assigns its IP, and arranges routing between nodes — by overlay tunneling or native routing. This is why a brand-new cluster has Pods stuck in ContainerCreating until a CNI plugin is installed: the contract exists, but nothing has fulfilled it yet.
Docker (single host) — containers share the host IP; you publish and map ports. Fine for one machine.
Kubernetes — every Pod has its own routable IP, reachable cluster-wide without NAT. Built for many nodes.
- Assuming Docker-style port mapping or NAT between Pods — the model is flat, direct Pod-to-Pod.
- Treating a Pod IP as stable; it changes on every reschedule, which is why Services exist.
- Under-sizing the Pod or Service CIDR and hitting an address ceiling as the cluster grows.
- Ignoring cloud IP exhaustion when Pods consume real VPC addresses.
- Expecting Pods to network before a CNI plugin is installed.
- Internalize the four traffic types — most networking confusion is mistaking one for another.
- Size Pod and Service CIDRs for the cluster's eventual scale, not its first week.
- On clouds with VPC-native networking, plan IP capacity explicitly to avoid exhaustion.
- Address workloads through Services and DNS names, never raw Pod IPs.
- Install and verify the CNI plugin as step one of any cluster build.
Knowledge Check
What is the core rule of the Kubernetes network model?
- Every Pod gets its own IP and can reach every other Pod directly, without NAT
- Every container shares its node's IP and publishes host ports mapped through NAT to reach the outside
- Pods communicate only by proxying every packet through the API server
- Each node owns one IP that all of its Pods share behind NAT
Why are Pods stuck in ContainerCreating on a brand-new cluster with no CNI installed?
- Kubernetes defines the network model but a CNI plugin must implement it; without one, Pod networking can't be set up
- The API server has not finished starting, so the kubelet cannot register the node or pull the Pod manifests it needs to run
- etcd is missing the Pod CIDR range, so no Pod can be assigned an address
- The scheduler refuses to place any Pod until a matching Service exists for it
Why is a Pod IP unsuitable as a long-lived address for another service to call?
- Pod IPs change whenever Pods are recreated; a Service provides the stable address
- Pod IPs are reachable only from within the same node, so off-node callers can never connect
- Pod IPs are encrypted and rotate automatically every hour
- Pod IPs can never be resolved through cluster DNS at all
You got correct