Core Workload Resources: Pods, Deployments, and ReplicaSetsLesson 2.3

Kubernetes rolling updates and rollbacks: how to deploy without downtime

RollingUpdate strategy, maxUnavailable, maxSurge, update trigger conditions, kubectl set image, rollback with kubectl rollout undo, revision history, Recreate strategy

The Default Update Strategy Is RollingUpdate

Kubernetes rolling update process diagram

By default, when you change a Deployment (new image, env var, resource limit), Kubernetes rolls the change out gradually. It never takes your app completely offline.

Controlling the Rollout Speed

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1   # At most 1 old pod down at a time
      maxSurge: 1         # At most 1 extra pod above desired count

Triggering and Rolling Back Updates

# Update the image (triggers a new rollout)
kubectl set image deployment/web-app web-app=nginx:1.26

# Watch it roll out
kubectl rollout status deployment/web-app

# Something broke — roll back to previous version
kubectl rollout undo deployment/web-app

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

# See revision history
kubectl rollout history deployment/web-app

The Recreate Strategy

Set strategy.type: Recreate and Kubernetes kills all old Pods before creating new ones. This causes downtime but is sometimes needed when your app cannot run two versions simultaneously (database schema migrations, for example). Only use Recreate when you must.