Why Kubernetes Exists
You can run containers with Compose, so why is there a cluster? The failures Kubernetes was built to absorb — a dead machine, a traffic spike, a bad deploy — and the declarative idea underneath all of it.
You can run containers with Compose, so why is there a cluster? The failures Kubernetes was built to absorb — a dead machine, a traffic spike, a bad deploy — and the declarative idea underneath all of it.
You can already run containers. One command starts a web server; a compose file starts a web server, a database and a cache together. So the obvious question, before learning anything about Kubernetes, is what is left to solve.
The honest answer is: everything that happens after the machine you are sitting at. By the end of this lesson you will know exactly which problems Kubernetes exists to absorb, the one idea underneath all of its machinery, and — just as usefully — when you should not reach for it at all.
Compose is genuinely good at what it does. It also has a boundary that is easy to miss, because it is not a missing feature: it is a missing machine.
Compose runs your containers on one host, the one you ran the command on. That single fact produces four failures it cannot help with, and each one is a lesson later in this course.
The machine dies
A disk fails, a kernel panics, a cloud provider retires an instance. Your containers were on it, and nothing brings them back anywhere else. Somebody has to notice and act.
One machine is not enough
You cannot make a compose file spread its services across five servers. You would run five compose files by hand and then own the problem of who talks to which.
Deploying drops requests
docker compose up -d stops the old container and starts the
new one. Between those two events, requests fail.
A container dies quietly
restart: unless-stopped restarts a process that exited. It
does nothing about one that is running but wedged — holding
its port open, answering nothing.
Kubernetes is a system that runs containers across a group of machines and keeps them running. That group is called a cluster, and the machines in it are nodes.
Its job description is short: you tell it what you want running, and it makes the cluster match — choosing which node each container goes on, restarting what fails, moving work off a node that dies, replacing containers one at a time during an update, and giving traffic a stable address even though the containers behind it come and go.
Notice what is absent. You do not tell Kubernetes which machine to use. You do not tell it when to restart something. You describe the destination and it works out the route — which is the idea worth spending the rest of this lesson on.
Everything you will learn about Kubernetes hangs off a single loop, so it is worth naming carefully.
You write down the desired state: three copies of this image, reachable at this address, with this configuration. Kubernetes stores it. Then controllers inside Kubernetes watch the actual state and, whenever the two differ, take one step to close the gap. Forever, every few seconds.
That is reconciliation, and the difference it makes is easiest to feel as a comparison.
Bad — imperative: a sequence of actions, correct only at the moment it runs:
docker run -d --name api-1 -p 8001:8000 myapp:1.4.2
docker run -d --name api-2 -p 8002:8000 myapp:1.4.2
docker run -d --name api-3 -p 8003:8000 myapp:1.4.2Good — declarative: a statement of what should be true, which something else keeps true:
spec:
replicas: 3
template:
spec:
containers:
- name: api
image: myapp:1.4.2Instructions somebody performed.
Correct at the moment it ran, and never again on its own.
If api-2 crashes overnight there are two copies until a
human runs a command. Scaling to five means remembering the
naming scheme and the free ports. Rolling back means
remembering what was there before.
A fact something else is responsible for.
Kill a pod and another appears in seconds. Change replicas
to 5 and five exist.
Change the image tag and Kubernetes replaces them one at a time, waiting for each new one to become healthy before removing an old one. Nobody was paged, and the file in your repository is an accurate description of production.
The features you will hear listed are all consequences of that loop. Four of them are the reason people adopt it.
Self-healing. A container that crashes is restarted. A container that fails its health check is replaced. A node that stops responding has its work rescheduled elsewhere. All of it without a human, because the desired state never changed — only reality did.
Scaling as a number. replicas: 3 becomes replicas: 30, and
the scheduler finds room across the cluster. With an autoscaler, the
number itself responds to load.
Rolling updates and rollbacks. Changing the image is a gradual replacement, not a stop and start. If the new version is bad, one command puts the old one back, because Kubernetes kept the previous desired state.
Stable addressing. Pods get new IP addresses constantly. A Service gives a group of them one name and one address that never changes, so nothing has to track where anything is.
You will meet each of these properly in its own lesson. Reading them once now makes the next few lessons feel like recognition rather than introduction.
| Term | What it is |
|---|---|
| Cluster | The whole system: a control plane plus nodes |
| Node | One machine that runs your containers |
| Control plane | The brain: stores desired state, decides |
| Pod | The smallest unit you deploy: one or more containers |
| Deployment | Keeps N identical pods running, handles updates |
| Service | A stable name and address for a set of pods |
| Ingress | Routes outside HTTP traffic to Services |
| ConfigMap | Non-secret configuration, injected into pods |
| Secret | The same, for credentials |
| Namespace | A boundary that groups objects inside a cluster |
| kubectl | The command-line tool you talk to a cluster with |
| Manifest | A YAML file describing an object you want |
One reassurance about all of it: a container is still a container. The image you built in the Docker course is exactly what a cluster runs, unchanged. Kubernetes adds a layer above containers; it does not replace anything underneath.
Kubernetes is not free, and being honest about the cost is more useful than enthusiasm.
There is real complexity to hold: a dozen object types, YAML that is strict about structure, networking with several layers, and failure modes that need their own debugging skills. There is operational cost, because a cluster is itself a system that needs upgrading, monitoring and securing. And there is a floor on the resources — the control plane needs machines even when your application is tiny.
So, plainly: if one machine comfortably runs your application, and a few minutes of downtime during a deploy is acceptable, you do not need Kubernetes. Compose on a single server, or a managed platform that runs containers for you, will cost you far less and do the job.
It starts paying for itself when several of these are true: you need more than one machine, downtime during deploys is unacceptable, someone would otherwise be paged to restart things, you are running many services rather than one, or you want the same deployment mechanism across several environments and providers.
You will build up one object at a time, on a cluster running on your own laptop. The order is deliberate: each object exists because the previous one left something unsolved.
A pod runs your container, but nothing replaces it when it dies. A Deployment fixes that, but its pods have unstable addresses. A Service fixes that, but it is only reachable inside the cluster. An Ingress fixes that. Then configuration, storage, health checks, resource limits, and rollouts — and finally the same notes application from the Docker course, running on the cluster, updated and rolled back.
# The problems Kubernetes solves, and its answer to each
node dies -> reschedule the work onto another node
one host is too small -> spread pods across many nodes
deploy drops requests -> rolling update, one pod at a time
process wedged but up -> readiness and liveness probes
addresses keep moving -> a Service with a stable name
# The single idea
# you declare desired state; controllers reconcile actual state
# toward it, continuously. Every object is one or the other.
# Vocabulary
cluster the whole system: control plane + nodes
node one machine that runs containers
control plane stores desired state and makes decisions
pod smallest deployable unit: one or more containers
deployment keeps N identical pods running; handles updates
service stable name and address for a set of pods
ingress routes external HTTP traffic to services
configmap non-secret configuration for pods
secret credentials for pods
namespace a grouping boundary inside one cluster
manifest a YAML file describing a desired object
kubectl the CLI you use to talk to a cluster
# When to skip it
# one machine is enough, and a short deploy gap is acceptableThe next lesson opens the cluster up: what the control plane actually contains, what runs on each node, and where that reconciliation loop physically lives. It is the one piece of theory in the course, and it makes every error message afterwards easier to read.
Then you will build a cluster on your own laptop and start applying manifests to it. Before moving on, it is worth writing down — for a project you actually work on — which of the four Compose limits you have hit. That answer is what tells you whether the rest of this course is urgent or educational.