Why Orchestration?
Docker made one container on one machine easy. Now picture production: fifteen services, three replicas each, spread across a dozen machines. At 3 a.m. a machine dies — who restarts its containers somewhere else? Traffic triples — who starts more replicas? You ship a new version — who swaps forty-five containers without downtime? Doing that by hand isn't a job, it's a pager nightmare. Kubernetes (K8s) is the system that does it for you.
💡 The Bottom Line
Kubernetes is a control loop over a cluster of machines: you declare the state you want ("three replicas of this image, reachable on port 80"), and Kubernetes works continuously to make reality match — restarting what dies, rescheduling around failed machines, and scaling on demand. You manage the description, not the containers.
Imperative vs declarative: the core idea
With Docker you give commands: start this, stop that. Kubernetes flips the model — you hand it a description (a YAML manifest) of the desired state, and its controllers reconcile endlessly:
- Desired: 3 replicas. A container crashes → actual: 2. Kubernetes starts one. Actual: 3. ✅
- A whole machine dies → its pods are rescheduled onto healthy machines automatically.
- You edit the manifest to a new image version → Kubernetes rolls the change out gradually.
This "reconciliation loop" is the single concept the rest of Kubernetes hangs off — every object type you'll meet in this track is just a different kind of desired state.
What a cluster looks like
- Control plane — the brain: the API server you talk to, the scheduler that decides which machine runs what, and the controllers running the reconciliation loops.
- Nodes — the worker machines (VMs or physical) that actually run your containers.
- kubectl — the CLI you use for everything:
kubectl apply -f app.yamlsubmits desired state;kubectl get/describe/logsinspect reality.
🙋 There Are No Dumb Questions
Q: Does Kubernetes replace Docker?
A: No — they're different layers. You still build container images exactly as before
(Dockerfile, registry); Kubernetes is what runs those images across a cluster.
Under the hood Kubernetes uses a container runtime (containerd, which is Docker's own core)
rather than the full Docker Engine, but from your point of view nothing changes: build and
push an image, then hand Kubernetes the image name.
⚠️ Watch Out
Kubernetes is not a default choice — it's an answer to problems of scale. One app on one server is better served by Docker Compose and a reverse proxy. Reach for Kubernetes when you actually have the problems it solves: many services, many machines, zero-downtime deploys, autoscaling. Learning it is valuable either way; deploying it everywhere is not.
🔧 Try It Yourself
You don't need a cloud account — run a tiny cluster on your laptop. Install one of
minikube, kind, or enable Kubernetes in Docker Desktop, then:
kubectl get nodes
kubectl get pods -AThe first shows your cluster's machines (just one, locally); the second shows the system pods Kubernetes runs for itself. If both answer, you have a working cluster for the rest of this track.
✅ Quick Check
What does "declarative desired state" mean in Kubernetes?
Next up: the smallest thing Kubernetes manages — the pod — and why it's a wrapper around your container rather than the container itself.