# Application Updates, Rollbacks, and Rollout Strategies

> Chapter 4 of the Courseiva CNCF-CKAD curriculum — https://courseiva.com/learn/cncf-ckad/application-updates-and-rollbacks

**Official objective:** 2.2 — Perform rolling updates and rollbacks of applications

## Introduction

Application updates, rollbacks, and rollout strategies. This is the core of how you change a live application without taking it offline or accidentally breaking everything for every user. For CKAD, you must prove you can update a Kubernetes deployment, monitor the rollout health, and undo a bad change — all from the command line — because that is exactly what a real application developer does every day.

## The Food Truck Menu Update Analogy

12 food trucks are parked at a busy city square, each one selling a different menu item. Today, your signature dish — the spicy jackfruit burrito — has a new recipe with a different sauce, and you need to update every truck without ever shutting down the whole operation. You decide to update 3 trucks at a time. While those 3 are closed, customers just walk to the other 9 trucks and buy their regular burrito. Once the first 3 are back open with the new sauce, you update the next 3, and so on until all 12 trucks serve the new recipe. 

Halfway through, a customer at truck 4 complains the new sauce is too spicy. You need to roll back immediately. You tell the next 3 trucks in line: 'Stop changing. Switch back to the old sauce.' Then you change the trucks that already updated — one by one — back to the old recipe. Customers never noticed the chaos because there were always 9 trucks open and selling something. 

That planned, gradual switch is a rolling update. The emergency reversal is a rollback. Your decision to update 3 trucks at a time instead of all 12 at once is the rollout strategy. Every real-world IT system that must stay live 24/7 uses this exact logic to change software without breaking the customer experience.

## Core explanation

In Kubernetes, an application runs as a Deployment. A Deployment is a blueprint that tells Kubernetes: 'Keep 5 copies of my app running at all times.' Each copy is called a Pod — a single running instance of your containerised software. When you want to change the container image (for example, upgrade from version 2.0 to 2.1), you do a rollout. A rollout is the process of gradually replacing old Pods with new ones. 

The default rollout strategy is called a Rolling Update. This means Kubernetes does not kill all old Pods at once. Instead, it creates a new Pod with the new image, waits until that Pod is healthy, then kills one old Pod. It repeats this cycle until every old Pod has been replaced. 

But you can configure two important parameters: maxSurge and maxUnavailable. maxSurge controls how many extra Pods can be created above your desired count during the update. If you set maxSurge to 1, Kubernetes can create one extra Pod beyond the 5 you want — so you might have 6 Pods temporarily. maxUnavailable controls how many Pods can be unavailable during the update. If set to 0, Kubernetes will never have fewer than your desired 5 Pods running. These settings let you balance speed against risk. 

If something goes wrong during a rollout — your new image crashes, or health checks fail — you need a rollback. A rollback reverts the Deployment to its previous stable version. Kubernetes stores the history of changes to a Deployment. You can see the history with 'kubectl rollout history deployment/my-app'. To undo the last change, you run 'kubectl rollout undo deployment/my-app'. You can also roll back to a specific revision number using '--to-revision=2'. 

Kubernetes also supports a second rollout strategy: Recreate. With Recreate, Kubernetes kills every running Pod first, then creates all new Pods from the new image. This causes downtime because there is a period when zero Pods are running. Recreate is rarely used for production services that must stay available, but it can be useful for batch jobs or test environments where a clean slate matters more than uptime. 

The rollout process itself goes through several states: Progressing (the update is happening), Complete (all Pods are updated and healthy), or Failed (new Pods cannot start). You check the status with 'kubectl rollout status deployment/my-app'. If it hangs or fails, you can add '--watch' to see real-time progress. 

Why does all this matter? Before Kubernetes, updating a live application meant either taking the whole site offline or using complex scripting to drain traffic from one server, update it, and repeat. Kubernetes automates this with a declarative model: you tell the system what you want (image version 2.1, 5 replicas, RollingUpdate strategy) and it figures out how to get there safely. Your job as a CKAD candidate is to know the commands, understand the parameters, and handle emergencies when a rollout goes wrong.

## Real-world context

Imagine you work for a ride-sharing app company. Your team maintains the microservice that calculates surge pricing. The service runs as a Kubernetes Deployment with 20 replicas spread across multiple availability zones. Today, your team is releasing version 4.2, which uses a new machine-learning model to predict demand. 

You start by editing the Deployment YAML to change the container image tag from 'surge-engine:4.1' to 'surge-engine:4.2'. You save the file and apply it with 'kubectl apply -f deployment.yaml'. Immediately, Kubernetes begins a rolling update. It creates one new Pod with version 4.2. The Pod starts, but its readiness probe fails because the new model needs a different API key that hasn't been provisioned yet. 

Kubernetes waits. The readiness probe keeps failing after the configured timeout. Kubernetes marks that new Pod as unhealthy and stops the rollout. The Deployment status shows 'Progressing' for a while, then 'Failed'. At this moment, the old 20 replicas are still running with version 4.1 — no customers are affected. 

You check 'kubectl rollout history deployment/surge-engine' and see that revision 12 is the current stable one. You run 'kubectl rollout undo deployment/surge-engine --to-revision=12'. Kubernetes kills the one failed 4.2 Pod and goes back to 20 healthy 4.1 Pods. The incident is resolved in under two minutes. 

Later, your colleague fixes the API key issue. This time, before applying the update, you change the Deployment's strategy to: maxSurge: 2 and maxUnavailable: 1. This means up to 2 extra Pods can be created, and only 1 Pod can be unavailable at a time — so 21 Pods total at peak, never fewer than 19. You apply the new YAML, watch 'kubectl rollout status deployment/surge-engine --watch', and see each Pod come up green. The entire rollout completes in 90 seconds. Customers never experience a delay or an error. 

Key actions an IT professional performs: 

- Editing the Deployment YAML to change the container image tag and rollout parameters.
- Running 'kubectl apply -f deployment.yaml' to trigger the update.
- Monitoring progress with 'kubectl rollout status' and 'kubectl get pods -w'.
- Checking rollout history with 'kubectl rollout history deployment/my-app'.
- Executing a rollback with 'kubectl rollout undo deployment/my-app'.
- Pausing a rollout with 'kubectl rollout pause deployment/my-app' if you need to investigate mid-update.
- Resuming a paused rollout with 'kubectl rollout resume deployment/my-app'.

## Exam focus

CKAD exam tasks on this topic are practical and command-line based. You will be given a scenario and must type the correct kubectl commands to perform an update or a rollback. Traps are common, and the time pressure is real. 

Question types you will see: 

- 'Update the image of Deployment X to nginx:1.19 and verify the rollout succeeds.' You must edit the Deployment, apply the change, and check status. 
- 'A recent rollout of Deployment Y caused pods to crashLoopBackOff. Roll back to the previous revision.' You must identify the failed state, find the previous revision number, and use 'kubectl rollout undo'. 
- 'Configure Deployment Z so that during rolling updates, no more than 2 Pods are unavailable and exactly 1 extra Pod can be created.' You must edit the strategy spec with maxUnavailable: 2 and maxSurge: 1 (or similar numbers). 
- 'Pause the rollout of Deployment A after 3 Pods have been updated, then verify it's paused, then resume it.' You must use 'kubectl rollout pause' and 'kubectl rollout resume'. 

Traps to watch for: 

- The exam may ask you to roll back to a specific revision, not just the previous one. Use '--to-revision=N'. 
- You might need to edit a Deployment that has no strategy specified. Default strategy is RollingUpdate with maxSurge: 25% and maxUnavailable: 25%. You must understand that percentages are rounded up or down — Kubernetes rounds percentages up for maxSurge and down for maxUnavailable, so with 3 replicas, maxSurge: 25% becomes 1, maxUnavailable: 25% becomes 0. 
- If a rollout fails, the Deployment is still considered 'progressing' if you check during the retry cycle. You must wait for the status to settle or use '--timeout' to fail fast. 
- The exam may give you a Deployment name but not tell you the namespace. Use '--namespace' or set your context. 
- Rolling back does not automatically update the YAML file in the cluster's etcd store in a way you can see with 'kubectl get deployment -o yaml' — the revision history is separate from the applied YAML. You must check history to see previous configurations. 

Key definitions to memorise: 

- RollingUpdate: Default strategy. Replaces Pods gradually. 
- Recreate: Kills all Pods before creating new ones. Causes downtime. 
- maxSurge: Maximum number of Pods allowed above the desired count during update. 
- maxUnavailable: Maximum number of Pods allowed to be unavailable during update. 
- readinessProbe: Health check that tells Kubernetes when a Pod is ready to serve traffic. If this fails during a rollout, the update stops. 
- rollout status: Command to check if a rollout succeeded or failed. 
- rollout history: Shows revision history for undo operations. 
- rollout undo: Reverts to a previous revision. 
- rollout pause / resume: Controls the rollout flow manually.

## Step by step

1. **Edit the Deployment YAML** — Change the container image tag (e.g., from nginx:1.18 to nginx:1.19) or other fields. You can edit the YAML file directly or use 'kubectl edit deployment/name'. This defines the desired state.
2. **Apply the change** — Run 'kubectl apply -f deployment.yaml' to send the new YAML to the Kubernetes API server. This triggers the rollout, and Kubernetes begins comparing the current state to the desired state.
3. **Monitor the rollout status** — Use 'kubectl rollout status deployment/name --watch' to see if new Pods are created and old ones removed. The command exits with success or failure, showing you the progress of each step.
4. **Check Pod health with readiness probes** — Kubernetes uses readinessProbe to decide if a new Pod is ready to serve traffic. If the probe fails, the rollout stalls. You can see this by looking at 'kubectl get pods' and checking the 'READY' column.
5. **Perform a rollback if needed** — If the rollout fails or you decide the new version is bad, run 'kubectl rollout undo deployment/name'. This reverts to the previous revision's Pod template, creating old-version Pods and removing new ones.
6. **Verify the rollback succeeded** — Check 'kubectl rollout status deployment/name' again, and use 'kubectl get pods' to confirm all Pods are running the old image. This ensures the application is stable before you move on.

## Comparisons

### RollingUpdate Strategy vs Recreate Strategy

**RollingUpdate Strategy:**
- Pods are replaced gradually, one or few at a time.
- Zero downtime during the update.
- Default strategy for Deployments.

**Recreate Strategy:**
- All Pods are deleted first, then new Pods are created.
- Complete downtime during the transition.
- Must be explicitly configured; rarely used for production.

### rollout undo vs manual YAML revert

**rollout undo:**
- One command reverts to a previous revision.
- Preserves rollout history for future undo operations.
- Kubernetes automatically manages the old ReplicaSet.

**manual YAML revert:**
- You edit the YAML file and re-apply it.
- You must know the exact previous image tag and settings.
- Risks human error if you misremember the old config.

### maxSurge vs maxUnavailable

**maxSurge:**
- Controls extra Pods above desired count.
- Can be set as percentage (rounded up).
- Helps speed up rollout by creating Pods in parallel.

**maxUnavailable:**
- Controls Pods allowed to be down during update.
- Can be set as percentage (rounded down).
- Helps maintain minimum availability during rollout.

## Diagram

_This diagram shows the rolling update process: the desired state triggers pod creation, health checks decide if the rollout continues, and failure leads to a rollback._

```mermaid
flowchart TD
    A[Desired State: image:nginx:1.19] --> B[K8s API Server]
    B --> C{Check Current State}
    C -->|Old Pods exist| D[Create New Pod with readinessProbe]
    D --> E{New Pod Ready?}
    E -->|Yes| F[Kill one old Pod]
    E -->|No| G[Stop rollout, keep old Pods]
    F --> H{All Pods updated?}
    H -->|No| D
    H -->|Yes| I[Rollout Complete]
    G --> J[Admin runs rollout undo]
    J --> K[Revert to previous revision]
```

## Common misconceptions

- **Misconception:** A rollback always goes back to the exact previous version before the update. **Reality:** You can roll back to any revision in the history, not just the immediately previous one. Use --to-revision flag to specify. (Beginners assume rollback is an 'undo last action' button, like Ctrl+Z in a word processor. In Kubernetes, you have a full history of revisions, and you can jump to any of them.)
- **Misconception:** If a rollout fails, you must manually delete the new Pods and reapply the old YAML. **Reality:** You simply run 'kubectl rollout undo deployment/name'. Kubernetes automatically reverts to the previous revision's Pod template and cleans up. (New users think they must manually intervene because they do not trust Kubernetes automation. The whole point of rollbacks is that Kubernetes handles the revert for you.)
- **Misconception:** maxSurge and maxUnavailable percentages apply to the number of Pods exactly as you set them — 25% of 4 replicas means exactly 1 Pod. **Reality:** Percentages are rounded: maxSurge rounds up (25% of 4 = 1) and maxUnavailable rounds down (25% of 4 = 0). This can cause unexpected behaviour with small replica counts. (Mathematically, 25% of 4 is 1, but the rounding rules are not symmetrical. Beginners often assume clean division and are confused when they see 0 unavailable during a rollout.)
- **Misconception:** A Recreate strategy is safer than a RollingUpdate because it gives a clean start. **Reality:** Recreate causes complete downtime and is generally less safe for production. RollingUpdate is safer because it maintains service continuity during the update. ('Clean start' sounds appealing to someone who dislikes partial states. But in real systems, downtime is the worst outcome, so Recreate is only used for non-live workloads.)
- **Misconception:** The rollout status command tells you immediately if the rollout succeeded or failed. **Reality:** The command waits for the rollout to complete (or times out). It shows 'successfully rolled out' only after all new Pods pass readiness probes. If it hangs, you may need to set a timeout. (Beginners expect an instant answer. In reality, Kubernetes waits for health checks, and a slow Pod startup can make the command appear stuck.)

## Key takeaways

- The default rollout strategy in Kubernetes is RollingUpdate, which replaces Pods gradually without downtime.
- Use 'kubectl rollout undo deployment/name' to revert a deployment to its previous revision, or add '--to-revision=N' for a specific revision.
- maxSurge controls how many extra Pods can be created above the desired count during a rollout; it rounds percentages up.
- maxUnavailable controls how many Pods can be down during a rollout; it rounds percentages down.
- A failing readiness probe during a rollout causes Kubernetes to stop the update and keep the old Pods running.
- The 'kubectl rollout status deployment/name --watch' command shows real-time progress and succeeds or fails explicitly.
- The Recreate strategy kills all existing Pods before creating new ones, which causes downtime and is rarely used in production.
- You can pause a rollout with 'kubectl rollout pause' and resume later with 'kubectl rollout resume'.
- Rollout history stores old ReplicaSet configurations, allowing you to roll back to any previous revision number.
- Always verify a rollout with 'kubectl get pods' and 'kubectl rollout status' before declaring success.

## FAQ

**What is the difference between a rollout and a rollback in Kubernetes?**

A rollout is the process of updating a Deployment to a new configuration (e.g., a new image version). A rollback is the process of reverting a Deployment to a previous configuration from its history.

**How do I roll back a deployment to a specific revision number?**

Run 'kubectl rollout undo deployment/my-app --to-revision=3', replacing '3' with the revision number you want. You can see all revision numbers with 'kubectl rollout history deployment/my-app'.

**What does maxSurge and maxUnavailable mean in a deployment strategy?**

maxSurge is the maximum number of extra Pods allowed above the desired count during a rolling update. maxUnavailable is the maximum number of Pods that can be unavailable during the update. Both can be set as a number or percentage.

**What happens if a rollout fails?**

Kubernetes stops creating new Pods and keeps the old Pods running. The Deployment's status shows 'Progressing' or 'Failed'. You can then roll back to a previous revision to restore service.

**Can I pause a rollout and resume it later?**

Yes. Use 'kubectl rollout pause deployment/my-app' to pause the rollout at its current state. Use 'kubectl rollout resume deployment/my-app' to continue it from where it stopped.

**How do I see the history of rollouts for a deployment?**

Run 'kubectl rollout history deployment/my-app'. It lists each revision with a change-cause annotation if set. To see details of a specific revision, add '--revision=2'.

## Check your understanding

1. **What command do you use to revert a Deployment to its previous revision?**

   Answer: 'kubectl rollout undo deployment/name' reverts to the previous revision.

2. **What is the default rollout strategy for a Kubernetes Deployment?**

   Answer: The default strategy is RollingUpdate.

3. **If a new Pod's readiness probe fails during a rollout, what does Kubernetes do?**

   Answer: Kubernetes stops the rollout and keeps the old Pods running.

4. **How do you see the list of revisions for a Deployment?**

   Answer: Run 'kubectl rollout history deployment/name'.

5. **What is the difference between maxSurge and maxUnavailable?**

   Answer: maxSurge controls how many extra Pods can be created above the desired count during an update, while maxUnavailable controls how many Pods can be unavailable during the update.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/cncf-ckad/application-updates-and-rollbacks