interview-prep

How do rolling updates and rollbacks work in Kubernetes

Crisp answer: A Deployment rolling update incrementally replaces old pods with new ones, controlled by maxSurge and maxUnavailable. A rollback reverts to the previous ReplicaSet. Zero-downtime is only guaranteed if readiness probes are configured correctly.

The update strategy:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # Allowed to have 1 extra pod above desired count
      maxUnavailable: 0    # No pod may be unavailable during the update

With replicas: 3, maxSurge: 1, maxUnavailable: 0:

  1. Create 1 new pod (now 4 total)
  2. Wait for new pod to pass readiness probe
  3. Terminate 1 old pod (back to 3)
  4. Repeat until all pods are new

Triggering an update:

# Change the image
kubectl set image deployment/api api=myapp:v2

# Or edit the deployment YAML and apply
kubectl apply -f deployment.yaml

# Or directly edit
kubectl edit deployment api

Kubernetes creates a new ReplicaSet for the new template. The old ReplicaSet is scaled down to 0 but kept (for rollback). The number of old ReplicaSets kept is controlled by revisionHistoryLimit (default: 10).

Watching the rollout:

kubectl rollout status deployment/api
# Waiting for deployment "api" rollout to finish: 1 out of 3 new replicas have been updated...
# Waiting for deployment "api" rollout to finish: 2 out of 3 new replicas have been updated...
# deployment "api" successfully rolled out

kubectl get pods -w   # Watch pods in real time

Rollback:

# See rollout history
kubectl rollout history deployment/api
# REVISION  CHANGE-CAUSE
# 1         <none>
# 2         image updated to v2
# 3         image updated to v3 (current)

# Rollback to previous revision
kubectl rollout undo deployment/api

# Rollback to specific revision
kubectl rollout undo deployment/api --to-revision=1

# Pause a rollout (stop mid-way)
kubectl rollout pause deployment/api

# Resume
kubectl rollout resume deployment/api

Why zero-downtime requires readiness probes:

Without a readiness probe, Kubernetes considers a pod ready as soon as the container starts — before the application is actually serving requests. If the update proceeds before the new pod is ready, the old pods are terminated and the new pod starts dropping requests.

With a readiness probe correctly configured, the rollout only proceeds to the next pod when the current new pod passes the readiness check.

Recreate strategy:

spec:
  strategy:
    type: Recreate

Terminates ALL old pods, then creates ALL new pods. Results in downtime but ensures no two versions run simultaneously. Useful for database schema migrations that are not backward-compatible.

What to say in the interview:

"A rolling update creates a new ReplicaSet for the updated template and incrementally shifts traffic by scaling up the new RS and down the old one, controlled by maxSurge and maxUnavailable. Zero-downtime depends entirely on readiness probes being correct — without them, Kubernetes sends traffic to the new pod before it's ready. Rollback just scales the previous ReplicaSet back up, which is fast because the pods start from an already-pulled image. The old ReplicaSets are kept up to revisionHistoryLimit, which is how rollback history is preserved."

My notes