Chapter 15 Kubernetes: Architecture & Workloads
The control plane and the node, the reconciliation loop, the path from kubectl apply to a running container, every workload type, labels, ConfigMaps and Secrets, init containers and sidecars.
In plain words
Imagine a big restaurant where you never cook yourself. You hand your order to a single receptionist at the front desk, who writes it in the order book. Then lots of helpers each watch the book for their own job: one decides which kitchen station gets the dish, one makes sure there are always three portions of soup ready, and a cook at each station actually makes the food. If a bowl of soup gets dropped, the soup helper sees "we want three, we have two" and orders another. Nobody shouts instructions at the cooks directly.
Kubernetes is that restaurant. You talk only to the kube-apiserver (the receptionist), which stores everything in etcd (the order book). The scheduler, the controllers and each node's kubelet watch it and react. You declare what should exist, a Deployment of 3 pods, and loops keep reality matching it.
Why it matters on call
Kubernetes is the centre of the platform you're moving into, and the Kubernetes admin exam (Ch 19) is in your plan. This chapter gives you the model you'll lean on in every incident: kubectl only talks to the apiserver, controllers reconcile, the scheduler only sets nodeName, and the kubelet is a systemd service you debug with Ch 2 skills. With that model, "pod stuck Pending" or "my change keeps getting undone" stop being mysteries.
It also covers the workload objects you'll write and review every week (Deployments, StatefulSets, DaemonSets, Jobs, ConfigMaps, Secrets) and the speed kit (k, $do, jsonpath) the exam rewards. It comes after Linux, containers and networking because pods are just Linux processes in namespaces, and before Services, storage and security (Ch 16-17), which build on these workloads.
Lessons
- The lab cluster, kubectl and kubeconfig
- The speed kit, and the shape of every kubectl command
- The control plane: who does what
- The node: kubelet, CRI, CNI, kube-proxy, CoreDNS
- The reconciliation loop
- From kubectl apply to a running container
- Pods: the unit, its lifecycle, and how to read its status
- Deployments and ReplicaSets: rolling updates, the maths, history and rollback
- StatefulSets: stable identity, ordered start, headless Services
- DaemonSets: one pod per node, and why the control plane is left out
- Jobs and CronJobs: run to completion, on a schedule
- Labels, selectors, annotations, namespaces
- ConfigMaps: env vs volumes, and what happens when you change one
- Secrets, base64, and the Downward API
- Init containers and sidecars
- Reading the API fast: -o yaml, jsonpath, custom-columns, sort and filter
- Imperative vs declarative: create, apply, diff, patch, replace, edit
- The debugging order
54 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
Is Kubernetes just a way to run Docker containers?
It runs OCI containers, including images built with docker build, but it is much more than a runner, and Docker itself isn't on the nodes: the kubelet talks to containerd over CRI. Kubernetes' job is keeping a declared state true across many machines: scheduling, restarting, rolling updates, service discovery and self-healing, through reconciliation loops.
Why do I never talk to the nodes directly?
Everything goes through the apiserver, and every component, including the kubelet on each node, watches it and reacts. kubectl sends your change to the apiserver, which stores it in etcd; the rest happens because controllers and kubelets notice. That single entry point is what makes logins, permissions, policy checks and auditing possible. You only touch nodes to debug the kubelet or containerd themselves.
What is the difference between a Pod, a Deployment and a ReplicaSet?
A Pod is one or more containers scheduled together on one node, sharing a network namespace. A ReplicaSet keeps N pods matching its selector alive. A Deployment manages ReplicaSets, one per version of the pod template, and adds rolling updates, history and rollback. You create Deployments; they create ReplicaSets; those create Pods. You almost never create the lower two yourself.
How does this lab cluster compare with a cloud provider's managed cluster?
The workload side is the same: Deployments, ConfigMaps and kubectl behave identically. The difference is the control plane: here it runs as static pods on cp-1 that you can see and break; in a managed cluster the cloud provider runs it for you, you can't see etcd or the apiserver pods, and an extra controller creates the cloud's load balancers for you. Ch 18 builds this kubeadm shape yourself.
Why is the exam speed kit taught this early?
The Kubernetes admin exam (Ch 19) gives you 2 hours for 15-20 hands-on tasks, so speed matters as much as knowledge. alias k=kubectl, completion for k, $do to generate YAML and jsonpath for quick answers need weeks to become muscle memory. Setting them up on day one means every lab from here on is practice for the exam.