CKAD — Rolling Updates

2 minute read

What Is a Rolling Update?

When you update a Deployment (e.g., change the container image), Kubernetes performs a rolling update by default. It gradually replaces old Pods with new ones — ensuring zero downtime.

Update the Image

# Imperative update (fastest)
kubectl set image deployment/web nginx=nginx:1.27

# Record the change for rollback history
kubectl set image deployment/web nginx=nginx:1.27 --record

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

How Rolling Updates Work

Behind the scenes, Kubernetes creates a new ReplicaSet and gradually scales it up while scaling the old ReplicaSet down:

Step 1: New ReplicaSet created (0 replicas)
        Old ReplicaSet: 3 Pods running

Step 2: New ReplicaSet scaled to 1, Old scaled to 2
        Kubernetes waits for new Pod to be Ready

Step 3: New ReplicaSet scaled to 2, Old scaled to 1
        Another new Pod ready

Step 4: New ReplicaSet scaled to 3, Old scaled to 0
        All new Pods running, old ones terminated

The old ReplicaSet is kept (with 0 replicas) to enable rollbacks.

Update Strategy Configuration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.27

maxSurge and maxUnavailable

Field Description Default
maxSurge Max Pods above desired count during update 25%
maxUnavailable Max Pods that can be unavailable during update 25%

Examples with 4 Replicas

Setting Effect
maxSurge: 1 At most 5 Pods exist during update (4 + 1)
maxUnavailable: 1 At least 3 Pods are always available
maxSurge: 0, maxUnavailable: 1 Replace one at a time, never exceed 4
maxSurge: 2, maxUnavailable: 0 Add 2 new before removing any old (zero unavailability)
maxSurge: 50%, maxUnavailable: 50% Fast update — half the fleet at once

How to Choose

Priority Configuration
Zero downtime maxSurge: 1, maxUnavailable: 0
Fast updates maxSurge: 50%, maxUnavailable: 50%
Balanced (default) maxSurge: 25%, maxUnavailable: 25%
Minimal resources maxSurge: 0, maxUnavailable: 1

Recreate Strategy

For cases where you cannot run old and new versions simultaneously:

spec:
  strategy:
    type: Recreate

This kills all old Pods first, then creates new ones.

Strategy Downtime When to Use
RollingUpdate None (default) Most applications
Recreate Yes DB schema changes, single-writer apps, version conflicts

Exam tip: The CKAD exam tests your understanding of maxSurge and maxUnavailable. Remember: maxSurge controls the ceiling (how many extra Pods), maxUnavailable controls the floor (how many can be down).

Next: Learn how to undo bad updates with Rollbacks →

Updated:

You may also enjoy