Lesson 4 · Core objects & the control plane

Deployments & ReplicaSets

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:¹

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.²
A Deployment manages ReplicaSets to give you declarative updates: change the image and it orchestrates the transition — rolling update, rollback, scaling.¹

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:³

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.

Kubernetes docs — Deployments (+ the rolling-update tutorial)

Declarative updates, rollouts and rollbacks, and how the Deployment drives ReplicaSets.

→ kubernetes.io — Deployments
→ kubernetes.io — Performing a rolling update

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.

1. Kubernetes — Deployments.

2. Kubernetes — ReplicaSet.

3. Kubernetes — Performing a rolling update.