Kubernetes Rolling Updates and Rollbacks

Intermediate·3 min read·

Fast recall

Quick revision

Core answer

Rolling updates replace pods incrementally — new pods start, pass readiness, then old pods are terminated. Behavior is controlled by maxSurge (extra pods above desired) and maxUnavailable (pods allowed offline). maxSurge: 1, maxUnavailable: 0 guarantees zero downtime. Kubernetes retains old ReplicaSets (up to revisionHistoryLimit, default 10) so kubectl rollout undo is instant and requires no image rebuild. For higher-risk changes, blue-green and canary are safer alternatives to native rolling.

Interview Answer3 min

Kubernetes rolling updates replace running Pods incrementally — new Pods start before old Pods terminate, maintaining availability throughout the deployment. The two parameters that control update speed and risk are maxSurge and maxUnavailable.

Rolling update mechanics

maxSurge: 1 allows one pod above the desired replica count during rollout — with 3 replicas, Kubernetes starts one new Pod (4 total), waits for it to pass readiness, terminates one old Pod; this continues until all pods run the new version.
maxUnavailable: 0 ensures zero pod downtime — no old pod terminates until its replacement passes readiness; set this to 0 in production for services that cannot tolerate reduced capacity during deploys.
The readiness probe is the critical coupling: a broken new version where readiness never passes stalls the rollout — old pods keep serving, the broken new pod sits in 0/1 Running, and the rollout never progresses; this is a feature, not a bug.

Triggering and monitoring

kubectl set image deployment/payment-service app=payment-service:v2.1.0 triggers a rolling update — Kubernetes records this as a new revision in the rollout history.
kubectl rollout status deployment/payment-service blocks and streams progress until all replicas are on the new version or progressDeadlineSeconds (default 600s) elapses.
kubectl rollout history deployment/payment-service shows revision history; annotate kubernetes.io/change-cause on updates so the history is meaningful.

Rollback

kubectl rollout undo deployment/payment-service reverts to the previous ReplicaSet immediately — old pods are recreated from the previous spec; no image rebuild required.
kubectl rollout undo deployment/payment-service --to-revision=3 rolls back to a specific revision — useful when the last version is also broken.
revisionHistoryLimit (default 10) controls how many old ReplicaSets are kept; setting it too low means you cannot roll back past recent releases.

When rolling is not enough

For breaking database schema changes, use blue-green — deploy v2 as a separate Deployment, verify in isolation, flip the Service selector atomically to switch traffic, flip back for rollback.
For high-risk large changes, use canary — deploy one or two pods alongside the stable version, weight 10% of traffic to them via Ingress or service mesh, monitor error rate, progressively shift to 100%.
Always pair rolling with a PodDisruptionBudget — minAvailable: 2 prevents node drains from evicting all replicas simultaneously during cluster maintenance.

Interview-ready guide

Interview answer

Rolling update mechanics

maxSurge: 1 allows one pod above the desired replica count during rollout — with 3 replicas, Kubernetes starts one new Pod (4 total), waits for it to pass readiness, terminates one old Pod; this continues until all pods run the new version.
maxUnavailable: 0 ensures zero pod downtime — no old pod terminates until its replacement passes readiness; set this to 0 in production for services that cannot tolerate reduced capacity during deploys.
The readiness probe is the critical coupling: a broken new version where readiness never passes stalls the rollout — old pods keep serving, the broken new pod sits in 0/1 Running, and the rollout never progresses; this is a feature, not a bug.

Triggering and monitoring

kubectl set image deployment/payment-service app=payment-service:v2.1.0 triggers a rolling update — Kubernetes records this as a new revision in the rollout history.
kubectl rollout status deployment/payment-service blocks and streams progress until all replicas are on the new version or progressDeadlineSeconds (default 600s) elapses.
kubectl rollout history deployment/payment-service shows revision history; annotate kubernetes.io/change-cause on updates so the history is meaningful.

Rollback

kubectl rollout undo deployment/payment-service reverts to the previous ReplicaSet immediately — old pods are recreated from the previous spec; no image rebuild required.
kubectl rollout undo deployment/payment-service --to-revision=3 rolls back to a specific revision — useful when the last version is also broken.
revisionHistoryLimit (default 10) controls how many old ReplicaSets are kept; setting it too low means you cannot roll back past recent releases.

When rolling is not enough

For breaking database schema changes, use blue-green — deploy v2 as a separate Deployment, verify in isolation, flip the Service selector atomically to switch traffic, flip back for rollback.
For high-risk large changes, use canary — deploy one or two pods alongside the stable version, weight 10% of traffic to them via Ingress or service mesh, monitor error rate, progressively shift to 100%.
Always pair rolling with a PodDisruptionBudget — minAvailable: 2 prevents node drains from evicting all replicas simultaneously during cluster maintenance.

03 · Deep dive