Deployments: the one you will use
Managing pods the normal way.
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.
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 deployNAME READY UP-TO-DATE AVAILABLE AGEweb 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/v1kind: Deploymentmetadata: { name: web }spec:replicas: 3selector: { 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.