The container orchestrator: software that runs and manages MANY containers across MANY machines — automatically.
← / → to navigate · EN/VI switch below
Kubernetes (k8s) = the container orchestrator — software that runs and manages MANY containers across MANY machines, automatically.
You tell it what you want; it decides where each container runs and keeps it running.
Not one app on one VPS — dozens or hundreds of containers spread across a pool of machines.
Docker builds the box; k8s flies the fleet. It doesn't replace Docker — it manages the containers Docker (or similar) makes.
A machine dies, a container crashes, traffic spikes — k8s notices and fixes it without a human.
One box vs the air traffic control for many boxes.
Packages ONE app with everything it needs into a single container — a portable box that runs the same on your laptop and on the server.
Great for one app. It doesn't answer: which machine runs it? what if it crashes? how do I run 3 copies?
Runs and manages MANY such boxes across MANY machines — places them, restarts them, scales them, swaps versions — automatically.
You describe the goal ('3 copies of hello'); k8s keeps the sky in order.
You don't run commands per machine. You declare a state ('3 copies of my app'), and k8s constantly works to make reality match it.
Decides which machine (node) each container lands on, spreading the load across the pool.
A container crashes or its machine dies → k8s starts a replacement, often on another node, in seconds.
Change replicas from 3 to 10 — new copies appear. Scale back down and they're gone. No machine by machine.
New version? Containers are swapped one-by-one without downtime. Traffic is split evenly across the running copies.
Five words: cluster, node, pod, deployment, service.
That's the whole vocabulary you need to read a deployment file.
The whole thing: a pool of machines working together to run your containers.
One machine in the cluster (a server or VM) that runs containers.
The smallest unit: a group of 1+ containers that live together (almost always just one).
'Run N replicas of this pod, and keep it true.' The object you edit most — it drives restarts, rollouts and scaling.
A stable name + port for a group of pods. Pods come and go; the service's address never changes.
3 nodes, 3 pods — one per node. The service gives all three pods one shared front door.
🖥 node-1
🖥 node-2
🖥 node-3
↕ service "hello-svc" — one stable name + port for all three pods
If node-2 dies, k8s re-places that pod on another node — the cluster stays at 3 running copies.
A controller loop, running every second, forever.
A YAML file: 'run 3 replicas of image hello, port 80'. You `kubectl apply` it once.
The scheduler picks a node for each of the 3 pods — spreading them out, respecting each machine's capacity.
The control plane constantly checks: are 3 pods actually running? Right image? Port open?
Pod crashed → a new one. Node died → its pods move elsewhere. Load up → more replicas. You never do this by hand.
Rule of thumb: many containers × many servers → k8s. One small site → not yet.
A monolith is one app on one VPS. A real product grows into many services, each with several copies — something has to place, restart and scale them all.
2 a.m. crash → k8s already restarted it. Traffic spike → replicas go 3 → 30 → back to 3. No human in the loop.
One app, one VPS? Docker + nginx is enough and far simpler. k8s earns its keep once the fleet of containers outgrows hand management.
This file IS the goal: 3 replicas, image nginx:1.27, port 80.
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello
spec:
replicas: 3
selector:
matchLabels: {app: hello}
template:
spec:
containers:
- name: hello
image: nginx:1.27
containerPort: 80replicas: 3 is the whole ask — k8s works non-stop to keep exactly 3 running.
Pods get brand-new names every time they're recreated — the service's name and port never change.
apiVersion: v1
kind: Service
metadata:
name: hello-svc
spec:
selector:
app: hello
ports:
- port: 80
targetPort: 80selector finds every pod labelled app: hello; clients just talk to hello-svc:80.
`kubectl` is your remote control for the cluster — two commands cover 80% of daily life.
k8s itself is open source; in practice you run a managed version from your cloud — or a tiny one at home.
Managed k8s from Google, Amazon and Azure — the cloud runs the control plane, you just deploy. The default choice for most teams.
Tiny k8s that runs on your laptop or a single VPS — perfect for learning and small projects.
The command-line remote control — the same tool works with every k8s above, managed or not.
k8s has a deep toolbox. These are real — but not your next step.
Logical partitions of one cluster (staging vs prod). Useful later — the default namespace works fine to start.
How the outside internet reaches your services (URLs, TLS, routing). A whole topic of its own.
The package manager for k8s — reusable 'charts' for common apps. You'll meet it after the basics.
Custom controllers that automate whole systems (databases, queues…). Powerful, advanced.
How the scheduler scores and picks nodes. Knowing 'it places pods for you' is enough here.
Docker packs one app into a box. Kubernetes is the air traffic control that flies many such boxes across many machines — placing, restarting and scaling them, automatically.
Next: put one deployment YAML on a small cluster — k3s on a VPS is a great first run.