In this lesson: Explain the control loop model and judge whether a system needs Kubernetes.
You can run containers on a server with Compose. It works well. What it does not do is decide which server a container should run on, move it when that server dies, add copies when traffic rises, or replace one that has stopped responding. Doing those things by hand across thirty machines is a full-time job. Kubernetes is software that does them for you.
The one idea: declare, then reconcile
You do not tell Kubernetes to start containers. You describe the state you want — "there should be four copies of this image, reachable on this name, each with this much memory" — and a set of controllers continuously compares that description to reality and closes the gap.
desired: 4 replicas
actual: 3 replicas ──▶ start one
actual: 5 replicas ──▶ stop one
a node dies ──▶ reschedule its pods elsewhereThis loop never stops. It is why a Kubernetes cluster heals itself, and also why fighting it by hand is futile: delete a pod that a Deployment owns and a new one appears immediately, because you changed reality without changing the description.
What it is made of
| Piece | Job |
|---|---|
| API server | The only way anything talks to the cluster. Everything is a request to it. |
| etcd | The database holding the desired state. Losing it is losing the cluster. |
| Scheduler | Decides which node each new pod should run on. |
| Controller manager | Runs the reconciliation loops. |
| kubelet | On every node: starts the containers it has been assigned and reports back. |
What it genuinely gives you
- Self-healing. A crashed container restarts; a dead node's work moves elsewhere. Without anyone waking up.
- Bin packing. The scheduler fits workloads onto nodes by their declared needs, so you buy fewer machines.
- Rolling updates with health gates. Built in, including automatic rollback when the new version fails its probes.
- Service discovery and load balancing. Names resolve to healthy pods; unhealthy ones are removed from rotation.
- One vocabulary. Every team describes workloads the same way, which is what makes a platform possible.
What it costs
It is important to be honest about this, because the cost is routinely understated.
- A control plane to operate — or a managed one to pay for. Either way it is a system that can itself fail.
- A large security surface. Default settings are permissive. RBAC, network policy, pod security and secret handling are all work you now own.
- A real learning curve. Not just for you — for everyone who deploys.
- Debugging gains a layer. "The site is slow" now includes the possibility that it is the ingress, the service mesh, DNS inside the cluster, or a resource limit.
- Upgrades are ongoing. Kubernetes moves fast, APIs are removed, and falling behind gets expensive.
The smaller options in between
| Option | Suits |
|---|---|
| Compose on one or two servers | Most small and medium applications. Genuinely fine. |
| Managed container services (Cloud Run, ECS, App Runner) | Stateless web services where you want scaling without a cluster. |
| Nomad, Docker Swarm, k3s | Scheduling with much less machinery than full Kubernetes. |
| Managed Kubernetes | When you genuinely need it — let someone else run the control plane. |
Try it yourself
Install k3d or kind and create a local cluster. Run kubectl get pods -A and look at what is already running before you have deployed anything — the DNS, the proxy, the controllers. That list is the machinery you are taking on, and seeing it is the most useful thing you can do before deciding to adopt it.