Why one Docker host is not enough: the case for orchestration

You can containerise an app and run it with Docker on one machine. But production is not one machine: you run many copies of your app across many servers, you need them to restart when they crash, move when a server dies, scale up under load, and update without downtime. Doing that by hand with docker run is impossible at scale. Container orchestration — and specifically Kubernetes — is the system that does it for you. This module builds real Kubernetes objects against a live cluster. This first lesson is why orchestration exists, so the pieces that follow have a reason.

What one Docker host cannot do

Compose (the containers module) runs your stack beautifully — on one machine. Production needs things a single host cannot give you:

• Run many replicas across many machines. One copy of your app cannot handle production traffic, and one machine is a single point of failure. You need N copies spread over a fleet of servers.
• Self-healing. When a container crashes — and they do — something must restart it. When an entire server dies, its containers must be recreated on healthy servers. No human can watch this 24/7.
• Scaling. Traffic rises and falls; you need to add replicas under load and remove them when it drops, automatically.
• Zero-downtime updates. Deploying a new version must not take the site down — old and new versions overlap, traffic shifts gradually, and a bad version rolls back.
• Service discovery and load balancing. With replicas coming and going across machines, something must give them a stable address and spread traffic across whichever are currently healthy.

Doing all this by hand — SSHing to servers, running containers, watching for crashes, wiring up load balancers — does not scale past a toy. Orchestration automates it.

What an orchestrator does

A container orchestrator manages containers across a cluster of machines. You tell it what you want — "run 3 replicas of this image, keep them healthy, expose them at this address" — and it continuously makes reality match, across the whole fleet:

• It schedules containers onto machines with capacity.
• It restarts failed containers and reschedules them off dead machines.
• It scales replicas up and down.
• It rolls out new versions gradually and rolls back bad ones.
• It provides networking so replicas are reachable at a stable address and traffic is balanced.

Kubernetes (often "k8s") is the dominant orchestrator — the industry standard, run by every major cloud (Amazon EKS, Google GKE, Azure AKS) and countless companies. Learn Kubernetes and you can operate containers in production almost anywhere.

The one idea that explains Kubernetes: desired state

If you remember one thing about Kubernetes, remember this: it is declarative. You do not tell Kubernetes the steps to take ("start a container, now another, now restart that one"). You declare the desired state — "I want 3 replicas of this image running" — in a YAML file, and Kubernetes' job is to continuously reconcile actual state toward that desired state.

This reconciliation loop is the heart of everything:

• You say "3 replicas". A pod crashes, leaving 2. Kubernetes notices actual (2) ≠ desired (3) and creates one. You did nothing; the system healed itself.
• You change the file to "5 replicas" and apply it. Kubernetes sees the gap and creates 2 more.
• You change the image version and apply. Kubernetes rolls the pods to the new image to match the new desired state.

So operating Kubernetes is mostly: write down the state you want, apply it, and let the reconciler make it so. That declarative model — desired state in files, a controller constantly reconciling — is why Kubernetes is powerful and why it feels different from docker run. Everything in this module is a kind of desired-state object you declare and apply.

The shape of a cluster

A Kubernetes cluster is a set of machines (nodes) with two roles:

• The control plane — the brain. It holds the desired state, runs the reconciling controllers, and decides what runs where (the scheduler). On managed Kubernetes (EKS/GKE/AKS) the cloud runs this for you.
• Worker nodes — the machines that actually run your containers (in pods — the next lesson).

You interact with the cluster through kubectl, the command-line client, which talks to the control plane's API: you kubectl apply your desired-state YAML, and kubectl get/describe/logs to see what is happening. You will practise on a local cluster — this course's examples are verified on kind (Kubernetes-in-Docker), which runs a real cluster inside Docker on your laptop, so you can learn without a cloud bill. Everything you learn on kind is the same Kubernetes you would run on EKS in production.

A note on complexity

Be honest about this: Kubernetes is complex, and it is easy to feel lost in its many objects and options. Two things make it manageable. First, the desired-state idea above unifies everything — every object is something you declare and the reconciler maintains. Second, you only need a handful of objects to run a real service: a Deployment (run and maintain replicas), a Service (a stable address), and ConfigMaps/ Secrets (configuration). This module teaches exactly those, hands-on, against a running cluster — enough to deploy and operate an app, which is what a foundation needs. The deep end (operators, custom resources, service meshes) can wait; the core is learnable and immediately useful.

Check your work

What one host can't do: run many replicas across many machines, self-heal (restart crashed containers, reschedule off dead nodes), scale automatically, update with zero downtime, and provide service discovery/load balancing. By-hand docker run does not scale past a toy.

An orchestrator manages containers across a cluster: schedules, restarts/reschedules, scales, rolls out/back, and networks them. Kubernetes is the standard, run by every major cloud (EKS/GKE/AKS).

The core idea — declarative desired state: you declare what you want (e.g. "3 replicas of this image") in YAML; Kubernetes continuously reconciles actual toward desired (a pod dies → it recreates one; you change the file → it adjusts). Operating k8s = write the desired state, apply, let the reconciler make it so.

Cluster shape: control plane (the brain — holds desired state, runs controllers, schedules; managed for you on EKS/GKE/AKS) + worker nodes (run your pods). You drive it with kubectl against the API. Practise on a local kind cluster — same Kubernetes as production.

Complexity: k8s is complex, but the desired-state idea unifies it and a handful of objects (Deployment, Service, ConfigMap/Secret) run a real service — this module's focus.

Practice

1. List five things production needs that a single Docker host cannot provide, and why each matters.
2. Explain "declarative desired state" and give an example of the reconciler healing a gap automatically.
3. Explain the difference between telling a system the steps versus declaring the desired state.
4. Describe the two node roles in a cluster (control plane, workers) and what each does.
5. Explain what kubectl is and how you interact with a cluster through it.
6. Set up a local cluster with kind (or Docker Desktop Kubernetes) and run kubectl get nodes.

Official documentation

• Kubernetes — What is Kubernetes? — Orchestration and what Kubernetes does.
• Kubernetes — Cluster architecture — Control plane and nodes.
• kind — Quick start — Running a local Kubernetes cluster in Docker.

Next: Pods, Deployments and ReplicaSets.