What an orchestrator does, and when you need one
🎯You'll be able to
Explain what Kubernetes adds over running containers yourself, name its main parts, and judge when it's worth the extra complexity.
🏠The everyday picture
A big railway station has a control room. Controllers don't drive trains; they keep a plan of which trains should be where and keep correcting reality to match it: send a spare engine when one breaks down, move a train to a free platform, hold a train until the line is clear.
📘What it really is
-
An orchestrator runs containers across many servers and keeps them matching a desired state you describe: "3 copies of
routerani:1.0.3, each with 250 MB of memory, behind one address". -
Kubernetes works as a set of control loops: each controller repeatedly compares what you asked for with what's running and acts on the difference. A crashed copy is replaced; a lost server's copies are started elsewhere. This is the same idea as Terraform's plan and apply, but it runs all the time, not when you type a command.
-
Main parts:
- the control plane: the API server (everything talks to it),
etcd(where the desired state is stored), the scheduler (picks a server for each copy) and controllers. Managed services run this for you; - nodes: the servers that run your containers, each with an agent called the kubelet;
-
kubectl: the command-line tool you use to talk to the API server. -
What you get: self-healing, spreading copies across servers and zones, rolling updates and rollbacks, service discovery and load balancing, autoscaling, and one standard way to describe apps that works on any cloud.
-
What it costs: a lot to learn and run, many moving parts to secure and upgrade (a new minor version comes out about three times a year), and a base cost even when traffic is low.
-
When you may not need it: a few services with steady traffic often fit well on a managed container service (Cloud Run, AWS Fargate/ECS, Azure Container Apps) or a couple of servers with Terraform, as in RouteRani. Kubernetes pays off with many services, many teams, or a platform team to run it.
📝A worked example
Input (not verified): with a kind cluster running, kubectl get nodes and kubectl get pods -A.
Expected output: one node named something like kind-control-plane with status Ready, and system pods in the kube-system namespace
(for example coredns, etcd, kube-apiserver, kube-scheduler), all Running. These are the control plane parts described above,
running as pods themselves.
🌍Where it's used
- Payment platforms run hundreds of small services, each scaled separately at month-end and sale peaks.
- Streaming services spread copies across zones so one data centre failure doesn't stop the match.
- Internal platforms: a platform team runs Kubernetes so product teams only write a short YAML file per service.
📝Case scenario
A five-person startup moved its single web app to self-managed Kubernetes because "that's what big companies use". Within three months, half their engineering time went on cluster upgrades, certificates and networking problems. They moved the app to a managed container service with two copies and kept the Kubernetes skills for later, when they had 20 services and a platform engineer.
🖱️Try it
List, for RouteRani as it is in the kit, which jobs you do yourself that Kubernetes would do: restarting a crashed copy, choosing which
server runs it, updating nginx when copies change, rolling updates, autoscaling. Success: for each one, you can say which part of the kit does
it now (Docker restart policy, Terraform, nginx's resolver, create_before_destroy, tools/autoscale.js).
⚠️Common mistakes
- Choosing Kubernetes by default. Sign: more time on the cluster than the product. Fix: start with a managed container service until the need is clear.
- Running your own control plane without a reason. Sign: upgrades and
etcdbackups nobody owns. Fix: use a managed service. - Thinking Kubernetes makes apps reliable by itself. Sign: an app without probes or limits still fails. Fix: the app must still be stateless, healthy-checked and limited.
🛠️For your project
In your capstone write-up, explain whether RouteRani should move to Kubernetes, and at what point it would be worth it.
✅Quick check
What does a Kubernetes controller do?
Show the answer
Repeatedly compares the desired state with what's running and acts to close the gap.
Name one sign that a team doesn't need Kubernetes yet.
Show the answer
A few services with steady traffic and no one to run a cluster.