Rolling Updates and Rollbacks

Deploying a new version of an application without downtime is a fundamental requirement in production. Kubernetes Deployments provide a RollingUpdate strategy out of the box, along with the ability to pause, resume, and roll back deployments.

How Rolling Updates Work

When you update a Deployment (for example, by changing the container image tag), Kubernetes creates a new ReplicaSet for the new version and scales it up while scaling down the old ReplicaSet, gradually shifting traffic from old pods to new pods.

The speed of the rollout is controlled by two strategy parameters:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

• maxSurge: 1 — at most one extra pod beyond the desired count may exist during the update
• maxUnavailable: 0 — no pods may be unavailable at any point (zero-downtime rollout)

With maxUnavailable: 0, Kubernetes must bring a new pod up and mark it Ready before terminating an old one — ensuring at least the desired replica count of healthy pods at all times.

Triggering and Monitoring a Rollout

# Update the image of a deployment
kubectl set image deployment/web-app web=my-registry/web-app:2.0.0

# Alternatively, edit the manifest and apply
kubectl apply -f deployment.yaml

# Watch the rollout progress
kubectl rollout status deployment/web-app

# View rollout history
kubectl rollout history deployment/web-app

# Add an annotation to record the reason for a change
kubectl annotate deployment/web-app kubernetes.io/change-cause="Release v2.0.0"

Pausing and Resuming Rollouts

You can pause a rollout mid-way to observe the new pods before continuing:

# Pause the rollout
kubectl rollout pause deployment/web-app

# Make additional changes while paused (they accumulate and apply on resume)
kubectl set env deployment/web-app APP_ENV=production

# Resume the rollout
kubectl rollout resume deployment/web-app

Rolling Back

If a new version misbehaves — high error rates, failed health probes, memory leaks — you can roll back instantly:

# Roll back to the previous revision
kubectl rollout undo deployment/web-app

# Roll back to a specific revision
kubectl rollout undo deployment/web-app --to-revision=3

Kubernetes keeps a history of ReplicaSets (controlled by revisionHistoryLimit, default 10). Each undo restores the pod template from a previous ReplicaSet.

Readiness Probes and Rollouts