Deployments and ReplicaSets

You've been creating bare Pods so far. In practice, you almost never do that — you create a Deployment, and it creates everything else for you.

The chain: Deployment → ReplicaSet → Pods

A Deployment declares what you want: this image, this many replicas, this update strategy. It doesn't manage pods directly — it creates and manages a ReplicaSet, and the ReplicaSet is what actually watches over a set of identical Pods, using a label selector (last lesson!) to know which ones are "its."

Deployment → ReplicaSet → Pods

Deployment: web

spec.replicas = 3

−scale+

ReplicaSet: web-7d9f6c

desired: 3 · current: 3

📦 podweb-1

📦 podweb-2

📦 podweb-3

Why the extra layer? Because a rolling update needs two ReplicaSets to exist briefly — the old one scaling down while the new one scales up — and the Deployment is what orchestrates that handoff. You'll see this directly in the next lesson.

Scaling vs. updating: two different operations

This distinction matters more than it looks like it should:

• Scaling (replicas: 2 → replicas: 4) changes how many — the pod template is untouched, so the existing ReplicaSet just grows. No new revision, no rolling update, just more of the exact same pods.
• Updating (changing the image, env vars, or anything in spec.template) changes what — this creates a brand-new ReplicaSet (new revision) and triggers a rolling update between old and new.

You'll do exactly the first one in this lesson's lab, and exactly the second one in the next.

Who owns what

Every object a controller creates on your behalf carries an ownerReference back to its creator: Pods point to their ReplicaSet, the ReplicaSet points to its Deployment. This is also how garbage collection works — delete the Deployment, and Kubernetes cascades the delete down through the ReplicaSet to every Pod, because of this chain, not because anything is hardcoded to know about Deployments specifically.

The infrastructure analogy

A Deployment is closest to an auto-scaling group's launch template plus its desired-capacity setting, combined — except, again, it's continuously enforced rather than evaluated on a schedule, and "launching a new version" (the rolling update) is a first-class, built-in operation instead of a separate deploy script you maintain yourself.