Every change to spec.template is a rollout. The Deployment controller creates a new ReplicaSet and moves Pods across, a few at a time.
Start one
kubectl set image deploy/market-web nginx=nginx:1.26nginx is the container name, not the image. Read it from kubectl get deploy market-web -o jsonpath='{.spec.template.spec.containers[0].name}' when unsure.
Watch it
kubectl rollout status deploy/market-webWaiting for deployment "market-web" rollout to finish: 1 out of 3 new replicas have been updated...
deployment "market-web" successfully rolled outIf the new Pods never become Ready (bad image, crash loop), rollout status waits and then times out. The old Pods keep serving.
Record why
The CHANGE-CAUSE column is an annotation. Set it before the change:
kubectl annotate deploy market-web kubernetes.io/change-cause="upgrade nginx to 1.26"
kubectl set image deploy/market-web nginx=nginx:1.26
kubectl rollout history deploy/market-webREVISION CHANGE-CAUSE
1 <none>
2 upgrade nginx to 1.26Go back
kubectl rollout undo deploy/market-web
kubectl rollout undo deploy/market-web --to-revision=1Undo does not delete anything. It copies the old ReplicaSet's template back into the Deployment, which becomes a new revision. The history numbers keep climbing.
The strategy
RollingUpdate (default) Recreate
old: ■ ■ ■ old: ■ ■ ■
■ ■ ■ □ new Pod added □ □ □ all old Pods stopped
■ ■ □ □ old Pod removed □ □ □ then new Pods started
■ □ □ □
□ □ □ no downtime downtime between the twospec.strategy.rollingUpdate has two knobs, absolute numbers or percentages of replicas:
| Field | Meaning | Default |
|---|---|---|
maxSurge | Extra Pods allowed above replicas during the rollout | 25% |
maxUnavailable | Pods allowed to be missing below replicas | 25% |
maxUnavailable: 0 means a new Pod must be Ready before an old one is removed. Recreate ignores both and stops everything first; use it when two versions cannot run at the same time.