Lesson 5 of 6 ·17 min read

Why Kubernetes exists

Imagine you run an online store. At the start life is simple:

1 server · 1 application · 100 users

Then the business grows: millions of users, multiple servers, several services, deployments every week. Questions start arriving faster than you can answer them by hand:

• Which server should run this container?
• What happens when a server dies at 3am?
• How do we update without downtime?
• How do we add instances during a traffic spike and remove them after?

Kubernetes is the system that answers these automatically. Keep the scale of that origin story in mind; it returns in Lesson 6 as the reason most projects should not start here.

The building blocks, smallest first

Container. Exactly the unit from Lesson 1: your Python app plus its runtime and dependencies, packaged to run anywhere.

Pod. The smallest thing Kubernetes deploys. A pod wraps one or more containers; usually one:

Pod
┌──────────────────┐
│  API container   │
└──────────────────┘

Occasionally a pod carries a helper container alongside the main one (a log shipper, for instance), which is why the wrapper exists at all.

Node. A machine: physical server, VM, or cloud instance. Pods run on nodes.

Cluster. The collection of nodes that Kubernetes manages as one pool.

Cluster
├── Node 1 ── Pod  Pod  Pod
├── Node 2 ── Pod  Pod
└── Node 3 ── Pod  Pod  Pod  Pod

Two parts run the show: the control plane (the brain: an API server, a scheduler deciding where pods go, and a database called etcd holding the cluster's state) and the worker nodes, which actually run your pods.

The central idea: desired state

This is the mental shift that makes everything else click. With Docker you issue commands: run this container. With Kubernetes you declare an outcome:

"I want 3 instances of my API running."

Desired: 3        Reality: 3        ✓ nothing to do

    ...a pod crashes...

Desired: 3        Reality: 2        ✗ start one

Desired: 3        Reality: 3        ✓

Kubernetes controllers compare desired state with observed state, continuously, and act to close any gap. That loop is called reconciliation, and it is the single most important idea in Kubernetes. Self-healing is not a feature bolted on top; it is what the loop does all day.

Deployments: how you ask for pods

You almost never create pods directly. You create a Deployment that describes what you want, and Kubernetes maintains it:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: api
        image: myorg/myapp:1.4

kubectl apply -f deployment.yaml

Read the YAML as a sentence: keep three replicas of the container built from myorg/myapp:1.4 running, labelled app: web. Notice the image reference: the nodes pull that exact image from the registry you met in Lesson 3. The whole release pipeline plugs in here.

Scaling is a change of one number, by hand or automatically:

kubectl scale deployment web --replicas=30

Updates are the reconciliation loop again: change the image to :1.5 and Kubernetes performs a rolling update, replacing pods a few at a time so users see little or no downtime:

v1 v1 v1  →  v2 v1 v1  →  v2 v2 v1  →  v2 v2 v2

kubectl rollout undo        # and back again if it goes wrong

Services: a stable address for unstable pods

Pods are temporary. When one dies and is replaced, the replacement has a different IP. Anything pointed at the old IP is now broken. A Service gives a changing set of pods one stable name and load-balances across them:

            Users
              │
              ▼
         API Service       stable name: api
       ┌──────┼──────┐
       ▼      ▼      ▼
      Pod    Pod    Pod    (IPs come and go underneath)

The Service finds its pods by their labels (app: web in the YAML above), not by their addresses. If that principle sounds familiar, it should: it is the find-each-other-by-name rule from Lesson 2, operating at cluster scale.

The remaining Kubernetes vocabulary

The remaining nouns you will meet all map onto ideas this course has already covered:

And the day-to-day commands are few:

kubectl get pods
kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl exec -it <pod-name> -- bash

One request, top to bottom

A user opens https://shop.com:

User → Ingress → Service → Pod → Container → your Python code

If a pod fails, reconciliation replaces it. If traffic grows, replicas increase. If you ship version 2, the rolling update swaps pods gradually. Every mechanism in this lesson is visible in that one request path.

A mental model to keep

If you want to feel the reconciliation loop rather than read about it, install a local cluster (Minikube or Kind), deploy the YAML above, then kubectl delete pod one of your pods and watch Kubernetes calmly replace it. That single moment teaches more than any diagram.