All labs
Lab 22
Application Scaling

Kubernetes — Replicas, Self-Healing & Rolling Updates

Run QuickMove's booking service on Kubernetes. Set a replica count and the Deployment holds it; kill a pod and it self-heals; ship v2 and it rolls out with zero downtime; turn on the HPA and pods scale with load.

QuickMove's booking service runs on Kubernetes as a Deployment. Change the replica count, kill a pod, ship a new version, or hand control to the autoscaler — and watch the cluster keep itself in the state you asked for.
replicas2
📦 Deployment: booking-servicedesired 2 · ready 2
📦runningv1
📦runningv1
The Deployment reconciles toward 2 running pods. Kill one and it comes back; ship a version and it rolls out one pod at a time.
What contains what (the part everyone mixes up)
🌐 Cluster — many nodes (machines)
📦 Deployment — keeps N identical pods running
🧫 Pod — 1 (usually) or more containers, scheduled together
🧰 Container — run by a runtime (Docker or containerd, CRI-O…)
💿 Image — your app + dependencies, frozen
Read it inside-out: an image runs as a container; a pod wraps one or more containers; a Deploymentkeeps N pods alive; the cluster spreads them over machines. Docker is just one container runtime — Kubernetes doesn't "manage Dockers," it schedules pods, and a container isn't "made of Dockers."
Pod
One running copy of your container — the unit Kubernetes schedules.
Deployment
Declares how many pods you want and keeps that many running.
Replicas
The desired pod count the Deployment maintains.
Service
A stable address in front of pods that come and go.
HPA
Horizontal Pod Autoscaler — adds/removes pods based on metrics like CPU.
Rolling update
Replaces pods gradually so the app never goes fully down.
What just happened