Kubernetes, visually

Color legend (used throughout)

1 · What is a container?

A container is just a normal Linux process running on your host kernel — but the kernel lies to it about the world. It thinks it has its own filesystem, its own network interfaces, its own process tree. It sees almost nothing of the host.

The lies are produced by three kernel features: namespaces (what you can see), cgroups (how much you can use), and chroot/overlay filesystems (which files exist).

The container in our lab

containers:
  - name: proddetail
    image: python:3.12-alpine
    command: ["/bin/sh", "-c"]
    args:
      - touch /tmp/healthy /tmp/ready
        python3 -m http.server 3000
    ports:
      - containerPort: 3000

2 · What is a Pod?

A Pod is a thin wrapper around one or more containers that share a network and a small set of disks. From outside the pod looks like one machine: one IP, one localhost, one DNS name.

99% of pods have exactly one container. The multi-container pattern is for tightly-coupled "sidecars" (log shipper, proxy) that need to share localhost with the main app.

Pod ≠ Container — three differences that matter

3 · The full hierarchy

You almost never create a Pod directly. You write a Deployment, and three nested controllers do the work.

Who's responsible for what?

4 · Service — the stable address

Pods are mortal. They die, restart, get new IPs constantly. So you can't just save a pod's IP and call it.

A Service is a permanent virtual IP and DNS name that load-balances to whichever pods match its selector right now.

Labels and selectors — the glue of Kubernetes

Almost every "X connects to Y" relationship in Kubernetes is implemented with labels. The Service has a selector; pods have labels; they match → wired.

spec:
  selector:
    app: proddetail

metadata:
  labels:
    app: proddetail
    version: v2

5 · Versioning & rolling updates — the magic moment

Here's what your eyes saw earlier when we went from v1 → v2 with zero downtime.

The setup

Before the change, the Deployment is pointing at ReplicaSet A (v1) with 3 pods. We change the pod template → Deployment creates ReplicaSet B (v2) and orchestrates a controlled handoff.

The strategy knobs

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

Frame-by-frame timeline

ReplicaSets after the rollout

One-command rollback

$ kubectl rollout undo deployment/proddetail -n workshop
# Same algorithm — just scales the OLD RS back up and NEW RS back down.
# Service Endpoints update continuously. Zero downtime, both directions.

6 · Probes — self-healing in two flavors

Liveness vs readiness — the one-sentence distinction

Readiness probe — visual state machine

Liveness probe — visual state machine

What we actually demonstrated

$ kubectl exec $POD -- rm /tmp/ready
# 8s later:
$ kubectl get endpoints proddetail
NAME         ENDPOINTS
proddetail                ← empty!

$ kubectl get pod
NAME           READY   STATUS    RESTARTS
proddetail-x   0/1     Running   0
  ▲ not Ready    ▲ but alive    ▲ never killed

$ kubectl exec $POD -- rm /tmp/healthy
# ~12s later:
$ kubectl get pod
NAME           READY  STATUS   RESTARTS
proddetail-x   1/1    Running  1 (18s ago)
                                  ▲ killed and restarted

$ kubectl get events ...
Warning  Unhealthy  Liveness probe failed
Normal   Killing    Container will be restarted

7 · What each kubectl command actually does

kubectl is just an HTTP client for the Kubernetes API server. Every command becomes a REST call to /api/v1/....

kubectl apply -f file.yaml

$ kubectl apply -f deployment.yaml

kubectl get / describe / exec — what they really are

The control loop — why this all keeps working

Every Kubernetes controller is the same shape:

Forever. This is the loop. Pods die → ReplicaSet notices → spawns new pod. You change image → Deployment notices → rolling update. Everything in Kubernetes is one of these loops.

8 · The full picture (what we built today)