The controllers that make ephemeral Pods reliable — keep N alive, and roll out new versions with zero downtime.
Your win: explain the Pod → ReplicaSet → Deployment hierarchy, how
self-healing and rolling updates work, and why this is how ~22 of this repo's services run.
The hierarchy that fixes ephemeral Pods
Lesson 3 left a problem: Pods die and don't come back. Two nested controllers solve
it:1
Deployment ──manages──► ReplicaSet ──manages──► Pods
"I want v2, "keep exactly 3 (the actual
3 replicas, copies of THIS running
rolled out safely" pod template alive" containers)
A ReplicaSet's entire job: keep a specified number of
identical Pods running. Fewer than desired → it creates more; more → it deletes some. This
is Lesson 1's reconcile loop, applied to a replica count.2
A Deployment manages ReplicaSets to give you declarative updates:
change the image and it orchestrates the transition — rolling update, rollback,
scaling.1
You write the Deployment; it makes the rest
You almost never create a ReplicaSet or Pod directly. You declare a Deployment
(desired image + replica count), and it creates the ReplicaSet, which creates the Pods.
Self-healing falls out for free: kill a Pod and the ReplicaSet notices the count dropped and
makes a new one — the 3am story from Lesson 1.
The rolling update — zero downtime, from first principles
When you change a Deployment's pod template (say, a new image tag), it doesn't kill
everything and restart. It creates a new ReplicaSet and shifts capacity
gradually:3
old RS (v1): ●●● new RS (v2):
old RS (v1): ●● new RS (v2): ● ← scale up new, down old
old RS (v1): ● new RS (v2): ●●
old RS (v1): new RS (v2): ●●● ← done, old RS kept for rollback
The pace is bounded by maxSurge (how many extra Pods above desired) and
maxUnavailable (how many below). Readiness probes (Lesson 8) gate it: a new Pod
only receives traffic once it reports ready, so users never hit a booting Pod. Rollback is
just "scale the old ReplicaSet back up" — which is why the old one is kept.
Anchor — how this repo runs ~22 services
Most backend services are Deployments, all generated from one library template:
deployments/helm/libs/util/templates/_deployment.tpl:30
(via the util.app orchestrator, _app.tpl:7).
spike, usermgmt, eureka, notificationmgmt
… all Deployments. And Course 1's sk.bash -s bob ended in
kubectl rollout restart deploy/bob — that command triggers exactly this
rolling-update dance.
A second Deployment on your own team's service
The notification team runs an extra hand-written Deployment,
backend/notificationmgmt/templates/deployment-consumers.yaml:2
— a separate {name}-consumers Deployment for its Kafka consumers, scaled
independently (you'll meet its KEDA autoscaler in Lesson 9). Good proof that "one service"
can be several Deployments. Not everything is a Deployment, though: tom and
conversationmgmt are StatefulSets — the subject of Lesson 7.
Backend use case
Backend use case: this is the real reading lens for `libs/util/templates/_deployment.tpl`, plus the many backend services that all invoke it through the shared library chart.
Common mistake
Common mistake: describing a Deployment as if it talks directly to containers, skipping the ReplicaSet layer and rollout mechanics.
Read this next
Kubernetes docs — Deployments (+ the rolling-update tutorial)
Declarative updates, rollouts and rollbacks, and how the Deployment drives ReplicaSets.
In plain English
Plain English: a Deployment is the usual Kubernetes object for keeping a stateless app running, scaled, and updated safely through ReplicaSets.
Check yourself (from memory)
Q1. The correct management hierarchy is…
A Deployment manages ReplicaSets, which keep the Pods
running. You declare the Deployment; it makes the rest.
Q2. A ReplicaSet's single responsibility is to…
It reconciles the replica count. Rollouts belong to the
Deployment; scheduling to the scheduler; routing to Services.
Q3. A rolling update achieves zero downtime by…
Capacity shifts gradually (maxSurge/maxUnavailable), and
readiness probes ensure only ready new Pods get traffic.
Explain Pod → RS → Deployment, self-healing, and the rolling update.
recall, then click to reveal
HIERARCHY: a DEPLOYMENT manages REPLICASETS which manage PODS. A
ReplicaSet's only job = keep N identical Pods alive (reconcile the count) → SELF-HEALING (kill
a Pod, it's recreated). A Deployment adds DECLARATIVE UPDATES: change the image → it creates
a NEW ReplicaSet and does a ROLLING UPDATE — scale new up while scaling old down (bounded by
maxSurge/maxUnavailable), readiness probes gate traffic so users
never hit a booting pod; the old RS is kept for instant ROLLBACK. You declare only the
Deployment. Repo: ~22 backend services are Deployments from
libs/util/…/_deployment.tpl:30; kubectl rollout restart deploy/bob
(Course 1) triggers the dance; notification has an extra -consumers Deployment.
✅ Part 1 complete
You have the core mental model: Kubernetes reconciles declared desired state (L1), split
across a control plane and nodes (L2); the unit is the ephemeral Pod (L3), made reliable by
Deployments/ReplicaSets (L4). Part 2 connects and configures these
workloads — Services & DNS, ConfigMaps/Secrets, StatefulSets (your
conversationmgmt!), and probes/resources.
Ready for Part 2 (Services, config, StatefulSets, probes)? Or want a
mock interview on Part 1 — seven courses in, still no retention check.
Ask me.