Rolling Updates

Rolling Updates — Zero Downtime Deployments

A rolling update gradually replaces old pods with new ones. At any point during the update, some old pods and some new pods are running, ensuring your application stays available.

This is the default update strategy for Deployments in Kubernetes.

How Rolling Updates Work

  Step 1: Starting state (3 replicas of v1)
  ┌──────┐  ┌──────┐  ┌──────┐
  │ v1   │  │ v1   │  │ v1   │
  └──────┘  └──────┘  └──────┘

  Step 2: Scale up new version (maxSurge: 1)
  ┌──────┐  ┌──────┐  ┌──────┐  ┌──────┐
  │ v1   │  │ v1   │  │ v1   │  │ v2   │
  └──────┘  └──────┘  └──────┘  └──────┘

  Step 3: Terminate old pods (maxUnavailable: 1)
  ┌──────┐  ┌──────┐  ┌──────┐
  │ v1   │  │ v1   │  │ v2   │
  └──────┘  └──────┘  └──────┘

  Step 4: Scale up, terminate old
  ┌──────┐  ┌──────┐  ┌──────┐
  │ v1   │  │ v2   │  │ v2   │
  └──────┘  └──────┘  └──────┘

  Step 5: Complete
  ┌──────┐  ┌──────┐  ┌──────┐
  │ v2   │  │ v2   │  │ v2   │
  └──────┘  └──────┘  └──────┘

Updating a Deployment

# Update the image
kubectl set image deployment/my-app app=my-app:v2

# Or edit the manifest
kubectl edit deployment my-app

# Watch the rollout in real-time
kubectl rollout status deployment/my-app

Rollback

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

# Rollback to the previous version
kubectl rollout undo deployment/my-app

# Rollback to a specific revision
kubectl rollout undo deployment/my-app --to-revision=2

Kubernetes keeps a history of rollouts. If something goes wrong, you can revert instantly.

Configuring Update Strategy

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1         # Max pods above desired count during update
      maxUnavailable: 0   # Max pods that can be unavailable
  minReadySeconds: 10     # Wait 10s before considering pod ready
  progressDeadlineSeconds: 600  # Fail rollout after 600s
  template:
    spec:
      containers:
        - name: app
          image: my-app:v2

maxSurge: 1, maxUnavailable: 0 — The safest configuration. One extra pod is created before old pods are terminated, ensuring zero downtime.