CKA — Rolling Updates & Rollbacks
CKA Exam Domain
Workloads & Scheduling — 15%
Perform rolling updates and rollbacks on Deployments.
Rolling updates and rollbacks are core CKA exam skills. You must be able to update a Deployment, check rollout status, view history, and undo changes — all under time pressure.
Rolling Updates
When you change a Deployment’s Pod template (e.g., update the container image), Kubernetes performs a rolling update by default. It gradually replaces old Pods with new ones, ensuring your application stays available throughout the process.
How it works:
- A new ReplicaSet is created with the updated Pod template
- New Pods are scaled up in the new ReplicaSet
- Old Pods are scaled down in the old ReplicaSet
- This continues until all Pods run the new version
Old RS: 3 → 2 → 1 → 0
New RS: 0 → 1 → 2 → 3
Triggering an Update
There are three ways to trigger a rolling update:
Method 1: kubectl set image (fastest for the exam)
kubectl set image deployment/web web=nginx:1.27-alpine
Format: kubectl set image deployment/<name> <container-name>=<new-image>
Method 2: Edit YAML and apply
kubectl edit deployment web
# Change the image in the editor, save, and exit
Method 3: Update the manifest file and apply
# Edit the YAML file
vim web-deployment.yaml
# Apply the changes
kubectl apply -f web-deployment.yaml
Exam tip:
kubectl set imageis the fastest approach. Use it when the question only asks you to update the image.
maxSurge and maxUnavailable
These two parameters control the speed and safety of rolling updates.
| Parameter | What It Controls | Default |
|---|---|---|
maxSurge |
Maximum number of Pods above the desired replica count during an update | 25% |
maxUnavailable |
Maximum number of Pods that can be unavailable during an update | 25% |
Both accept an absolute number or a percentage.
Example: 3 replicas with different settings
| Setting | maxSurge | maxUnavailable | Max Total Pods | Min Available Pods |
|---|---|---|---|---|
| Default (25%) | 1 (ceil of 25% of 3) | 1 (floor of 25% of 3) | 4 | 2 |
| Safe | 1 | 0 | 4 | 3 |
| Fast | 3 | 0 | 6 | 3 |
| Minimal resources | 0 | 1 | 3 | 2 |
YAML example
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
This is the safest configuration — Kubernetes creates one new Pod, waits for it to be Ready, then removes one old Pod. Zero downtime, but slower.
kubectl rollout Commands
These commands are essential for the CKA exam:
# Watch the rollout progress in real time
kubectl rollout status deployment/web
# View rollout history (list of revisions)
kubectl rollout history deployment/web
# View details of a specific revision
kubectl rollout history deployment/web --revision=2
# Undo — rollback to the previous revision
kubectl rollout undo deployment/web
# Rollback to a specific revision
kubectl rollout undo deployment/web --to-revision=1
# Pause a rollout (stop mid-update)
kubectl rollout pause deployment/web
# Resume a paused rollout
kubectl rollout resume deployment/web
Example: Watching a rollout
$ kubectl rollout status deployment/web
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
Example: Viewing history
$ kubectl rollout history deployment/web
REVISION CHANGE-CAUSE
1 <none>
2 <none>
3 <none>
Tip: To track why each revision was created, add
--record(deprecated) or annotate:kubectl annotate deployment/web kubernetes.io/change-cause="Updated to nginx:1.27-alpine"
Revision History
Kubernetes keeps old ReplicaSets around so you can rollback. The number of old ReplicaSets retained is controlled by revisionHistoryLimit.
spec:
revisionHistoryLimit: 10 # default
| Setting | Behavior |
|---|---|
10 (default) |
Keeps last 10 old ReplicaSets |
0 |
No history — cannot rollback |
5 |
Keeps last 5 old ReplicaSets |
Exam warning: If
revisionHistoryLimitis set to0, you cannot perform a rollback. Old ReplicaSets are cleaned up immediately.
You can see old ReplicaSets with:
kubectl get rs
Old ReplicaSets will show DESIRED: 0, CURRENT: 0, but they remain in the cluster until they exceed the history limit.
Rollback Scenarios
Scenario 1: Bad image update
# Update to a non-existent image
kubectl set image deployment/web web=nginx:9.99.99
# Check status — it will be stuck
kubectl rollout status deployment/web
# Waiting for deployment "web" rollout to finish: 1 out of 3 new replicas have been updated...
# Check Pods — new Pod will be in ImagePullBackOff
kubectl get pods
# Rollback immediately
kubectl rollout undo deployment/web
# Verify
kubectl rollout status deployment/web
# deployment "web" successfully rolled out
Scenario 2: Rollback to a specific revision
# Check history
kubectl rollout history deployment/web
# Rollback to revision 1
kubectl rollout undo deployment/web --to-revision=1
# Verify the image
kubectl describe deployment web | grep Image
Scenario 3: Pausing and resuming
Pausing is useful when you want to make multiple changes before triggering a single rollout:
# Pause the Deployment
kubectl rollout pause deployment/web
# Make multiple changes (no rollout triggered yet)
kubectl set image deployment/web web=nginx:1.27-alpine
kubectl set resources deployment/web -c web --limits=cpu=200m,memory=256Mi
# Resume — a single rollout is triggered with all changes
kubectl rollout resume deployment/web
Practice Questions
Q1. A Deployment named frontend is running with image nginx:1.26. Update it to nginx:1.27 and verify the rollout completes.
Show Answer
kubectl set image deployment/frontend frontend=nginx:1.27
kubectl rollout status deployment/frontend
Verify:
kubectl describe deployment frontend | grep Image
Q2. View the rollout history of the frontend Deployment, then rollback to revision 1.
Show Answer
kubectl rollout history deployment/frontend
kubectl rollout undo deployment/frontend --to-revision=1
kubectl rollout status deployment/frontend
Q3. What is the difference between maxSurge and maxUnavailable?
Show Answer
- maxSurge — the maximum number of Pods that can exist above the desired replica count during an update. It controls how many new Pods are created before old ones are removed.
- maxUnavailable — the maximum number of Pods that can be unavailable during an update. It controls how many old Pods can be terminated before new ones are ready.
Both default to 25%.
Q4. A Deployment was updated with a broken image and Pods are stuck in ImagePullBackOff. Rollback to the previous version.
Show Answer
kubectl rollout undo deployment/<name>
kubectl rollout status deployment/<name>
kubectl get pods
Q5. Pause the Deployment api, change the image to node:20-alpine and set memory limit to 512Mi, then resume.
Show Answer
kubectl rollout pause deployment/api
kubectl set image deployment/api api=node:20-alpine
kubectl set resources deployment/api -c api --limits=memory=512Mi
kubectl rollout resume deployment/api
kubectl rollout status deployment/api
Next — learn how to inject configuration into your workloads.
