Rolling updates and rollbacks

Key points

• The default strategy is RollingUpdate. New pods come up while old ones drain, with maxSurge and maxUnavailable at 25% each.
• A new pod only counts as available once its readiness probe passes. Without a probe the rollout is blind.
• kubectl rollout status blocks until the rollout finishes or the 10 minute progressDeadlineSeconds expires.
• kubectl rollout undo scales the previous ReplicaSet back up. It is far faster than rebuilding.
• Never deploy the latest tag. If the tag text does not change, nothing rolls. Pin a version or a digest.
• kubectl rollout restart recycles pods without changing the image, handy after a ConfigMap or Secret edit.

Example

# roll forward
kubectl set image deployment/web app=ghcr.io/acme/web:1.5.0
kubectl rollout status deployment/web --timeout=120s

# what changed, and when
kubectl rollout history deployment/web
kubectl rollout history deployment/web --revision=4

# roll back
kubectl rollout undo deployment/web
kubectl rollout undo deployment/web --to-revision=3

# restart in place, no image change
kubectl rollout restart deployment/web

A rollout is only as safe as the readiness probe that gates it.