Why orchestration

1 · What `docker run` cannot do

Here's a night you might recognize. You shipped a container to a VM with docker run -d. It worked. Everyone was happy. Then at 3:17am the app hit an out-of-memory error and the process died — and because nothing was watching, it stayed dead until a customer emailed at 8am. You SSH in, run docker run again, and go back to bed. Two weeks later the whole VM reboots for a kernel patch and your container doesn't come back at all, because you never set it to start on boot. That drip of tiny 3am chores — restart it, move it, scale it, put it behind a load balancer — is the problem orchestration exists to erase.

Here's the mental shift. docker run is a one-shot command: it starts a container and then walks away. Nobody is left minding the store. What production actually wants is a standing promise — "keep this thing running, in this shape, no matter what breaks" — and a command that runs once can't make a promise that lasts forever. Think of the difference between lighting a candle and installing a thermostat. The candle (docker run) gives you light right now, but if a draft blows it out, it's out. The thermostat (an orchestrator) has a target and a loop that keeps checking reality against it — furnace kicks on when the room drifts cold, off when it's warm — with no one in the room. Orchestration is a thermostat for your containers.

The common beginner mistake here is assuming Docker's own flags are "close enough." --restart=always does bring a crashed container back — but only on the same host, and only if the Docker daemon itself is alive. The instant the machine dies, that flag dies with it, and everything it was restarting is simply gone. Docker gives you the pieces for one container on one box; orchestration gives you a system that spans many boxes and outlives any one of them. Read the table below as a list of promises you'd otherwise have to keep by hand, at 3am, forever.

A single docker run is perfect for one container on one machine. Production is not that. The moment you have real traffic, you need answers to questions Docker alone does not answer: what restarts a crashed container at 3am? What moves it when its host dies? How do ten replicas share one stable address? How do you roll out v2 without dropping requests, and roll back in seconds when it's bad? Orchestration is the standing machinery that answers all of these automatically.

2 · The declarative model — desired vs actual state

Think about how you get a haircut. You don't stand behind the barber narrating every scissor stroke — "now move up two millimeters, now tilt the blade, now snip." You describe the result you want ("short on the sides, leave the top") and trust them to keep cutting until reality matches that description. If you come back in three weeks and it's grown out, you don't re-explain the whole procedure — you just say "same as last time," and they close the gap again. That is the entire philosophy of Kubernetes in one everyday act: you describe the end state, not the steps, and something else does the work of getting there and staying there.

This matters because it's the opposite of how most of us first learn to automate. The instinct is to write a script: "do this, then this, then this." That's imperative — a recipe of steps — and it has a fatal flaw in a world where things break: a script runs once, top to bottom, and then it's over. The moment reality drifts (a container dies, a node reboots), the script has no idea and no reason to care; it already finished. The declarative model flips this. You hand the cluster a description of the world you want — "3 replicas of this image on port 80" — and a controller compares that description to what's actually running, over and over, forever, taking action every time they disagree. You stop writing how and start writing what.

The common trap for newcomers is treating a Kubernetes manifest like a shell script — imagining kubectl apply "runs" the YAML the way bash runs commands. It doesn't. Applying a manifest doesn't execute anything; it records a wish in the cluster's database, and independent controllers then race to make that wish true. That's why you can apply the same file ten times and nothing bad happens — you're re-stating the same desired state, not re-running ten actions. Hold onto the phrase desired vs actual; every self-healing behavior in the rest of this track is just that gap being closed automatically.

This is the single most important idea in Kubernetes, and it's what separates it from a shell script. You do not tell the cluster "start this container, then that one." You declare the desired state — "I want 3 replicas of this image exposed on port 80" — and write it down as YAML. A set of controllers continuously compares desired state to actual state and takes whatever action closes the gap. Delete a Pod and the controller notices actual < desired and makes a new one. This loop is called reconciliation.

3 · Cluster anatomy — control plane + nodes

Picture a busy restaurant. Out front there's a manager taking orders, writing them on tickets, and deciding which cook handles what; in back there's a line of cooks who actually make the food. You, the customer, never walk into the kitchen and start frying — you talk to the front, and the front drives the back. A Kubernetes cluster is organized exactly like this. The control plane is the front-of-house brain that takes your orders and decides what runs where; the worker nodes are the kitchen line that does the actual cooking. When people say "I can't reach the cluster," nine times out of ten they mean they can't reach the manager out front — the control plane — not that the cooks stopped working.

Understanding this split is what turns cluster debugging from guesswork into a checklist. Every component has one job, and when something misbehaves, knowing whose job it was tells you where to look. The manager (api-server) is the only one allowed to write in the reservation book (etcd) — so if two people try to change the same thing at once, the book stays consistent. The seating planner (scheduler) decides which table (node) a new party (Pod) goes to. The floor supervisors (controller-manager) keep checking that every table that should be occupied actually is, and re-seat parties when a table breaks. And on each table sits a waiter (kubelet) who takes instructions from the front and reports back whether the food actually arrived.

The mistake beginners make is picturing the control plane as a single magic box, so when something breaks they have no idea which piece failed or what the blast radius is. It's worth internalizing early that these are separate processes with separate failure modes — a fact Exercise 5 makes you reason about directly. If etcd (the reservation book) is lost, the cluster forgets everything it was supposed to be doing; if the scheduler stops, existing tables keep serving but no new parties get seated; if a single node's kubelet dies, only that one table goes quiet while the rest of the restaurant runs fine. You talk only to the control plane (via kubectl); it drives the nodes — so trace the diagram below left-to-right as the path your order actually takes.

A cluster is two kinds of machines. The control plane is the brain that decides what should run where; the worker nodes are the muscle that actually runs your containers. You talk only to the control plane (via kubectl); it drives the nodes.

On a managed service like EKS (K5), AWS runs and secures the entire control plane for you — you only manage nodes. That's the main reason most teams use managed Kubernetes rather than running etcd themselves.

4 · Pods vs containers

You spend the whole containers track learning about containers — and then Kubernetes hands you a word you've never seen: Pod. Almost everyone's first reaction is quiet confusion: "Wait, I thought I was deploying containers. What's a Pod, and why do I suddenly have to care?" It feels like an unnecessary layer of jargon between you and the thing you already understand. It isn't — but the friction is real, so let's name it plainly and make it click before you ever write one.

Here's the analogy that makes it stick: a container is a single roommate, and a Pod is the apartment they live in. Usually one roommate lives alone — one Pod, one container — and the apartment is basically just a wrapper around that one person. But sometimes two roommates truly need to share the same apartment: same address (one IP), same phone line (localhost), same fridge (shared storage), and — crucially — they move in and move out together. That's a Pod with a main container and a sidecar: a log shipper or proxy that only makes sense living right next to the app and dying when it dies. Kubernetes schedules apartments, not individual roommates, because everything that must share an address and a lifecycle has to be placed as one unit.

Why bother with the wrapper at all, when 90% of the time it's just one container? Because the smallest thing the scheduler can place on a node needs a single, stable network identity and a single lifecycle — and "a container plus its inseparable helpers" is the honest unit of deployment, not the lone container. The mistake to avoid is reaching for multi-container Pods too eagerly: cramming your database and your API into one Pod because it's "convenient" is an anti-pattern, because they can no longer scale, restart, or move independently. The rule of thumb — one main container per Pod, add a sidecar only when it must share the app's fate — is worth tattooing on your brain now, before the YAML tempts you otherwise. Read the minimal Pod below with that lens: it's one apartment, one roommate.

Newcomers assume Kubernetes runs containers. It doesn't — directly. The smallest unit it schedules is a Pod: one or more containers that share a network namespace (same IP, same localhost) and can share storage. Usually a Pod is one app container; a second sidecar container (a log shipper, a proxy) is added only when it must live and die with the main one.

pod.yamlapiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    app: web
spec:
  containers:
    - name: app
      image: ghcr.io/example/web:1.0.0   # pin a version, never :latest
      ports:
        - containerPort: 8000

run.shkubectl apply -f pod.yaml        # create/update from the manifest
kubectl get pods                 # is it Running?
kubectl describe pod web         # events, image, node, why it's Pending/CrashLooping
kubectl logs web                 # the container's stdout/stderr

NAME   READY   STATUS    RESTARTS   AGE
web    1/1     Running   0          12s

5 · When NOT to use Kubernetes

Here's a failure mode that plays out in real companies every year. A two-person startup reads that "everyone serious runs Kubernetes," spins up a cluster for their single Flask API, and six months later has spent more engineering hours fighting cluster upgrades, networking quirks, and expiring certificates than they ever spent building the actual product. The app was never the problem — the infrastructure they didn't need became a second full-time job neither of them signed up for. Nobody warned them, because it's rarely fashionable to say "you don't need this." So this section says it plainly: Kubernetes is often the wrong first choice, and knowing that is a mark of experience, not ignorance.

The honest framing is that Kubernetes is a power tool with a real running cost, and like any power tool, using it for a job that a screwdriver would do is not impressive — it's a hazard. A cluster doesn't just sit there; someone has to own it. That means patching security holes, running version upgrades that can break things, managing RBAC, watching costs, and being on call for the cluster itself — a layer of pager duty entirely separate from your application. That ownership is the true price of Kubernetes, and it's almost always paid in headcount, not dollars of compute. If no one on the team is that owner, the cluster doesn't stay still — it quietly rots into an unpatched, misconfigured liability, which is genuinely worse than the simple VM you were trying to outgrow.

The most useful instinct to build is to flip the default: don't ask "why not Kubernetes?" — ask "do I actually have the problems from section 1?" Kubernetes earns its complexity only when you're running many services across many machines and you have a team to own the platform. Miss those conditions and a managed host (a PaaS, serverless, or managed containers like ECS/Fargate or Cloud Run) ships the exact same container with a fraction of the operational burden — and, because you containerized anyway, migrating to Kubernetes later is writing manifests, not rewriting the app. That's the quiet superpower: the decision is reversible, so choosing "not yet" costs you almost nothing. The table below is your decision aid — for each situation, notice it fails at least one of the many-services / many-machines / team-to-run-it tests.

Kubernetes is powerful and expensive in complexity. It is the wrong first choice more often than the internet admits. Reach for something simpler when: