Rolling update strategy in Kubernetes - Step-by-Step Execution

Process Flow - Rolling update strategy

Start with current version pods

↓

Create new version pods gradually

↓

Wait for new pods to be ready

↓

Delete old version pods gradually

↓

Check if all pods are updated

↓

Continue update

The rolling update replaces old pods with new ones step-by-step, ensuring availability by creating new pods before deleting old ones.

Execution Sample

Kubernetes

kubectl set image deployment/myapp myapp=nginx:2.0
# Rolling update starts
kubectl rollout status deployment/myapp

This command updates the image of the deployment 'myapp' to version 2.0 and monitors the rolling update progress.

Process Table

Step	Action	Pods Old Version	Pods New Version	Status	Notes
1	Start rolling update	3	0	Old version running	All pods running old version
2	Create 1 new pod	3	1	New pod starting	New pod created, old pods still running
3	Wait for new pod ready	3	1	New pod ready	New pod passed readiness checks
4	Delete 1 old pod	2	1	Old pod terminated	One old pod removed
5	Create 1 new pod	2	2	New pod starting	Second new pod created
6	Wait for new pod ready	2	2	New pod ready	Second new pod ready
7	Delete 1 old pod	1	2	Old pod terminated	Another old pod removed
8	Create 1 new pod	1	3	New pod starting	Third new pod created
9	Wait for new pod ready	1	3	New pod ready	Third new pod ready
10	Delete last old pod	0	3	Old pods terminated	All old pods removed
11	Update complete	0	3	All pods running new version	Rolling update finished

💡 All old pods replaced by new pods, update complete

Status Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	After Step 8	After Step 10	Final
Pods Old Version	3	3	2	2	1	0	0
Pods New Version	0	1	1	2	3	3	3
Status	Old version running	New pod starting	Old pod terminated	New pod ready	New pod starting	Old pods terminated	All pods running new version

Key Moments - 3 Insights

Why do we create new pods before deleting old pods?

Creating new pods first ensures the application stays available during the update, as shown in steps 2 and 3 where new pods start and become ready before old pods are deleted in step 4.

What happens if a new pod is not ready?

The update pauses until the new pod passes readiness checks, preventing deletion of old pods and avoiding downtime, as seen in the 'Wait for new pod ready' steps (3, 6, 9).

How do we know when the rolling update is complete?

When all old pods are deleted and all pods run the new version, as in step 11 where old pods count is 0 and new pods count is 3.

Visual Quiz - 3 Questions

Look at the execution table, how many new version pods exist after step 6?

A 3

B 1

C 2

D 0

💡 Hint

Check the 'Pods New Version' column at step 6 in the execution table.

At which step does the first old pod get deleted?

A Step 4

B Step 2

C Step 3

D Step 5

💡 Hint

Look for the first 'Old pod terminated' status in the execution table.

If new pods took longer to become ready, which step would be delayed?

A Creating new pods

B Deleting old pods

C Starting rolling update

D Update complete

💡 Hint

Refer to the 'Wait for new pod ready' steps before old pods are deleted.

Concept Snapshot

Rolling update strategy in Kubernetes:
- Gradually replace old pods with new pods
- Create new pods first, wait until ready
- Then delete old pods step-by-step
- Ensures zero downtime during updates
- Use 'kubectl set image' and 'kubectl rollout status' to manage

Full Transcript

The rolling update strategy in Kubernetes updates application pods gradually to avoid downtime. It starts by creating new pods with the updated version while keeping old pods running. Once new pods are ready, old pods are deleted one by one. This cycle repeats until all pods run the new version. Commands like 'kubectl set image' trigger the update, and 'kubectl rollout status' monitors progress. This method ensures continuous availability during updates.

Practice

1. What is the main purpose of a rolling update in Kubernetes?

easy

A. To update an application without downtime by gradually replacing pods

B. To delete all pods and recreate them at once

C. To backup the current state of the application

D. To scale the application to zero replicas

Solution

1. Step 1: Understand rolling update concept

   A rolling update replaces pods one by one to avoid downtime.

2. Step 2: Compare options with concept

   Only To update an application without downtime by gradually replacing pods describes gradual replacement without downtime.

3. Final Answer:

   To update an application without downtime by gradually replacing pods -> Option A

4. Quick Check:

   Rolling update = gradual pod replacement [OK]

Hint: Rolling update means update pods one by one without downtime [OK]

Common Mistakes:

• Thinking rolling update deletes all pods at once
• Confusing rolling update with backup
• Assuming rolling update scales pods to zero

2. Which kubectl command starts a rolling update by changing the image of a deployment?

easy

A. kubectl set image deployment/myapp myapp-container=myimage:v2

B. kubectl rollout undo deployment/myapp

C. kubectl scale deployment/myapp --replicas=0

D. kubectl get pods --watch

Solution

1. Step 1: Identify command to update image

   The command to update a deployment's image is 'kubectl set image'.

2. Step 2: Match command with options

   kubectl set image deployment/myapp myapp-container=myimage:v2 uses 'kubectl set image' correctly to start rolling update.

3. Final Answer:

   kubectl set image deployment/myapp myapp-container=myimage:v2 -> Option A

4. Quick Check:

   Change image = kubectl set image [OK]

Hint: Use kubectl set image to start rolling update [OK]

Common Mistakes:

• Using rollout undo to start update
• Scaling replicas to zero instead of updating image
• Using get pods to update image

3. After running kubectl set image deployment/myapp myapp-container=myimage:v2, what does kubectl rollout status deployment/myapp show?

medium

A. The configuration details of the deployment

B. The current rollout progress of the deployment update

C. The logs of the deployment pods

D. The list of pods in the deployment

Solution

1. Step 1: Understand purpose of rollout status

   The command 'kubectl rollout status' shows progress of deployment updates.

2. Step 2: Compare options with command purpose

   The current rollout progress of the deployment update correctly describes rollout progress; others describe different commands.

3. Final Answer:

   The current rollout progress of the deployment update -> Option B

4. Quick Check:

   Rollout status = update progress [OK]

Hint: Rollout status shows update progress, not pod list or logs [OK]

Common Mistakes:

• Confusing rollout status with pod listing
• Expecting logs from rollout status
• Thinking rollout status shows config details

4. You ran kubectl set image deployment/myapp myapp-container=myimage:v2 but the new pods crash. Which command helps you revert to the previous version?

medium

A. kubectl scale deployment/myapp --replicas=0

B. kubectl delete deployment myapp

C. kubectl rollout undo deployment/myapp

D. kubectl get pods --all-namespaces

Solution

1. Step 1: Identify command to revert deployment

   'kubectl rollout undo' reverts deployment to previous version.

2. Step 2: Match command with options

   kubectl rollout undo deployment/myapp correctly reverts the deployment; others do not revert updates.

3. Final Answer:

   kubectl rollout undo deployment/myapp -> Option C

4. Quick Check:

   Undo rollout = kubectl rollout undo [OK]

Hint: Use rollout undo to revert bad updates quickly [OK]

Common Mistakes:

• Deleting deployment instead of undoing
• Scaling replicas to zero instead of reverting
• Using get pods which only lists pods

5. You want to update your deployment with zero downtime and ensure at least 2 pods are always available during the update. Which rolling update settings in the deployment spec help achieve this?

hard

A. Set 'maxUnavailable' to 1 and 'maxSurge' to 1 in 'rollingUpdate' strategy

B. Set 'maxUnavailable' to 2 and 'maxSurge' to 0 in 'rollingUpdate' strategy

C. Set 'maxUnavailable' to 3 and 'maxSurge' to 3 in 'rollingUpdate' strategy

D. Set 'maxUnavailable' to 0 and 'maxSurge' to 2 in 'rollingUpdate' strategy

Solution

1. Step 1: Understand maxUnavailable and maxSurge

   'maxUnavailable' controls how many pods can be down; 'maxSurge' controls extra pods created during update.

2. Step 2: Ensure at least 2 pods always available

   Setting 'maxUnavailable' to 0 means no pods go down; 'maxSurge' 2 allows 2 extra pods to be created for smooth update.

3. Final Answer:

   Set 'maxUnavailable' to 0 and 'maxSurge' to 2 in 'rollingUpdate' strategy -> Option D

4. Quick Check:

   Zero unavailable + surge 2 = no downtime, 2 pods always up [OK]

Hint: maxUnavailable 0 means no pod down; maxSurge adds extra pods [OK]

Common Mistakes:

• Setting maxUnavailable > 0 causes downtime
• Setting maxSurge to 0 prevents extra pods during update
• Choosing high maxUnavailable and maxSurge causing instability