Chapter 16 Kubernetes: Networking & Storage
How a Service really routes (kube-proxy, iptables, IPVS), every Service type, CoreDNS and ndots, Ingress and TLS, Gateway API, NetworkPolicy, CNI, and storage: PV/PVC/StorageClass, access modes, zones, reclaim.
In plain words
Picture a big hotel where guests change rooms every night. If you wanted to deliver a pizza to "the guy in room 214", it would be wrong by tomorrow. So the hotel gives each team a front desk with a fixed name ("Room service desk"), and the desk always knows which rooms currently belong to that team. Some doors are locked so only certain guests can knock. And guests who need to keep their luggage get a locker in the basement that stays put when they move rooms.
That is this chapter. Pods are the guests that move, Services are the front desks (a stable IP and a DNS name), CoreDNS is the phone book, Ingress and Gateway API are the hotel's main entrance, NetworkPolicy is the locks, and PersistentVolumes are the lockers that outlive any pod.
Why it matters on call
Most "Kubernetes is broken" tickets a platform team gets are really networking or storage. "The service times out", "DNS doesn't resolve after we added a policy", "the ingress returns 503", "the pod is stuck in ContainerCreating with a Multi-Attach error", "we deleted the namespace and the database disk is gone". Each has a precise mechanism and a two-command check once you know it.
It is also a big share of any hands-on Kubernetes exam, and where interviewers separate people who have run a cluster from people who have read about one. It comes after workloads (Ch 15) because Services select pods by label and volumes mount into pods; it comes before scheduling and security (Ch 17) because zones, RWO disks and NetworkPolicy feed straight into those.
Lessons
- Services: a stable address in front of moving pods
- How a ClusterIP really routes: kube-proxy, iptables, IPVS
- Service types: NodePort, LoadBalancer, ExternalName, headless
- CoreDNS and the names it serves
- ndots:5, the search path, and why api.github.com costs 8 queries
- Ingress: the resource, the controller, the rules
- TLS termination at the Ingress
- Gateway API: GatewayClass, Gateway, HTTPRoute
- NetworkPolicy: default allow, isolation, and the rules
- Designing policies: three tiers, namespaces, the dash trap
- CNI: how a pod gets its IP, and why the CIDRs matter
- Volumes: where the data lives, and for how long
- PersistentVolume, PersistentVolumeClaim, StorageClass
- Access modes, zones, and why RWO constrains scheduling
- Reclaim policies, protection, expansion, StatefulSet claims
56 hands-on labs (missions, incidents and drills) run in the terminal: Open this chapter in the terminal Free, in your browser - a real Ubuntu terminal to try it in, with missions that check your work.
Questions people ask
Why does Kubernetes need Services at all? Can't pods just talk to each other by IP?
They can, and the network is flat: any pod can reach any pod IP. The problem is that pod IPs change every time a pod is replaced, and a Deployment replaces pods constantly (rollouts, crashes, node drains). A Service gives you a virtual IP and a DNS name that never change, plus a label selector that tracks which pods are behind it right now. Clients use web.shop; the Service keeps the list of real pod IPs up to date in EndpointSlices.
Is a namespace a network boundary?
No. Namespaces are a naming and RBAC boundary only. A pod in shop can reach any pod in payments by IP, and resolve api.payments through DNS, unless a NetworkPolicy isolates it and the CNI actually enforces policies. This surprises people coming from VPC thinking, and it is a common audit finding: "multi-tenant cluster, no NetworkPolicies".
Ingress or Gateway API, which one should I learn?
Both. The Ingress API is stable (GA) and everywhere. Gateway API is its successor: roles split across GatewayClass, Gateway and HTTPRoute, typed fields instead of annotations, and cross-namespace references with ReferenceGrant. The ingress-nginx controller project is retired, so new platforms pick a Gateway implementation, but you will operate existing Ingresses for years.
What is the difference between a volume and a PersistentVolume?
A volume is anything a pod mounts: an emptyDir, a ConfigMap, a hostPath, or a claim. Its lifetime depends on the type. A PersistentVolume is a cluster object that represents a real piece of storage (a disk, an NFS export) that exists independently of any pod. Pods never reference PVs directly; they reference a PersistentVolumeClaim, which binds 1:1 to a PV.
Is this the same on a cloud provider's managed cluster as on the kubeadm lab cluster?
The APIs are identical: Service, Ingress, NetworkPolicy, PVC and StorageClass behave the same. What differs is who fills them in. On a managed cluster the cloud-controller-manager creates the provider's load balancers for type: LoadBalancer, the provider's disk and file-share CSI drivers back the StorageClasses, and the network policy engine is often picked at cluster creation. On kubeadm you install MetalLB, a CNI and CSI drivers yourself.