How do rolling updates work in a Deployment, and how do you roll back?

Summary

A rolling update creates a new ReplicaSet and shifts pods from old to new gradually, limited by maxSurge (extra pods allowed above the desired count) and maxUnavailable (pods allowed to be unavailable). New pods only count as available once they pass readiness (and minReadySeconds). Roll back with kubectl rollout undo or, better, by reverting the manifest in Git.

Longer Answer

progressDeadlineSeconds marks a rollout as failed if it stalls (for example, new pods never become ready), but Kubernetes does not roll back automatically; tools such as Argo Rollouts or Flagger add automated canary analysis and rollback.

A rolling update only works safely when old and new versions can run side by side (backward-compatible APIs and database schema) and when readiness probes reflect real readiness. maxUnavailable: 0 with maxSurge: 25% keeps full capacity during the rollout at the cost of temporary extra pods.

Key Points

• New ReplicaSet scaled up, old scaled down.
• maxSurge / maxUnavailable control pace.
• Readiness gates progress.
• No automatic rollback; use undo, Git revert or Argo Rollouts.