Rolling update strategy in Kubernetes - Commands & Configuration

Introduction

When you update an application running in Kubernetes, you want to avoid downtime. The rolling update strategy updates your app gradually, replacing old versions with new ones without stopping the whole app at once.

When you want to update your app without making it unavailable to users.

When you need to fix bugs or add features to your app while it is running.

When you want to test new versions of your app safely by updating pods one by one.

When you want to keep your app stable and avoid sudden crashes during updates.

When you want Kubernetes to manage the update process automatically.

Config File - deployment.yaml

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: example-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: example-app
    spec:
      containers:
      - name: example-container
        image: nginx:1.21
        ports:
        - containerPort: 80

This file defines a Deployment named example-deployment that runs 3 copies (replicas) of an Nginx container.

The strategy section sets the update method to RollingUpdate. It controls how many pods can be unavailable (maxUnavailable: 1) and how many extra pods can be created during the update (maxSurge: 1).

This means Kubernetes will update pods one by one, keeping the app available.

Commands

This command creates or updates the Deployment using the configuration file. It starts running 3 pods with the specified Nginx image.

Terminal

kubectl apply -f deployment.yaml

Expected Output

deployment.apps/example-deployment created

This command lists all pods with the label app=example-app to check that the pods are running.

Terminal

kubectl get pods -l app=example-app

Expected Output

NAME                                READY   STATUS    RESTARTS   AGE

example-deployment-5d8f9f7d7f-abc12   1/1     Running   0          10s

example-deployment-5d8f9f7d7f-def34   1/1     Running   0          10s

example-deployment-5d8f9f7d7f-ghi56   1/1     Running   0          10s

→

-l - Filter pods by label

This command updates the Deployment to use a new image version nginx:1.22, triggering a rolling update.

Terminal

kubectl set image deployment/example-deployment example-container=nginx:1.22

Expected Output

deployment.apps/example-deployment image updated

This command shows the progress of the rolling update to confirm it finishes successfully.

Terminal

kubectl rollout status deployment/example-deployment

Expected Output

deployment "example-deployment" successfully rolled out

This command lists the pods again to verify that all pods are running the new image version.

Terminal

kubectl get pods -l app=example-app

Expected Output

NAME                                READY   STATUS    RESTARTS   AGE

example-deployment-6a7b8c9d0e-xyz12   1/1     Running   0          30s

example-deployment-6a7b8c9d0e-uvw34   1/1     Running   0          30s

example-deployment-6a7b8c9d0e-rst56   1/1     Running   0          30s

→

-l - Filter pods by label

Key Concept

If you remember nothing else from this pattern, remember: rolling updates replace pods gradually to keep your app running without downtime.

Common Mistakes

Not specifying the rolling update strategy in the Deployment, causing Kubernetes to use the default or recreate all pods at once.

This can cause downtime because all pods might stop before new ones start.

Always set the strategy type to RollingUpdate with maxUnavailable and maxSurge values to control the update flow.

Setting maxUnavailable or maxSurge to 0 or too high values without understanding the impact.

Setting maxUnavailable to 0 means no pods can be down, which might block updates; setting maxSurge too high can overload resources.

Use small values like 1 for maxUnavailable and maxSurge to balance availability and update speed.

Not checking rollout status after updating the image.

You might miss errors during the update and end up with a broken app.

Always run 'kubectl rollout status' to confirm the update completed successfully.

Summary

Create a Deployment with a rolling update strategy to update pods gradually.

Use 'kubectl set image' to change the container image and trigger the rolling update.

Check the update progress with 'kubectl rollout status' to ensure no downtime.

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