Deployments: the one you will use

Managing pods the normal way.

Beginner10 min · lesson 8 of 24
In plain terms
A Deployment is the store manager above that shift manager — it also swaps everyone into new uniforms smoothly, and puts them back in the old ones if the new batch is bad.
How a Deployment owns ReplicaSets and Pods
owns manages kubectl rollout undo ↻ scale old RS back up Deployment desired state · image + replicas ✎ you edit only this ReplicaSet · current replicas: 3 → keeps 3 pods ReplicaSet · old replicas: 0 · retained Pod app running Pod app running Pod app running controller reconcile loop keeps actual state → desired state
owns — Deployment → current ReplicaSetmanages — ReplicaSet → Podsrollback — undo scales the old ReplicaSet back up
You edit only the Deployment; its ReplicaSet and Pods follow, and the previous ReplicaSet is kept so a rollout can be undone.

The Deployment is the object you will actually use for almost every app. It manages a ReplicaSet for you (so you get the counting and self-healing) and adds two superpowers on top: smooth updates and instant rollback.

terminal
$ kubectl create deployment web --image=nginx:1.25 --replicas=3
$ kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
web 3/3 3 3 20s

The chain to remember

Deployment → ReplicaSet → Pods. You create and edit the Deployment at the top; it manages the ReplicaSet in the middle; the ReplicaSet keeps the Pods at the bottom. You touch the top and let the rest follow — that is the normal way to run things.

deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata: { name: web }
spec:
replicas: 3
selector: { matchLabels: { app: web } }
template:
metadata: { labels: { app: web } }
spec:
containers: [{ name: app, image: nginx:1.25 }]
Match the labels
The selector and the template’s labels must match (here, app: web) — that is how the Deployment knows which pods are “its” pods. A mismatch is a classic first-day gotcha.