Rolling update strategy in Kubernetes - Mini Project: Build & Apply

Kubernetes Rolling Update Strategy

📖 Scenario: You manage a web application running on Kubernetes. You want to update the app to a new version without downtime. Kubernetes rolling update helps replace old app versions with new ones gradually.

🎯 Goal: Learn how to create a Deployment with an initial app version, configure the rolling update strategy, update the app version, and observe the rolling update in action.

📋 What You'll Learn

Create a Deployment YAML with app version 1

Add rolling update strategy with maxSurge and maxUnavailable

Update the Deployment to app version 2

Check the rollout status to confirm update success

💡 Why This Matters

🌍 Real World

Rolling updates let you update live applications without downtime by replacing pods gradually.

💼 Career

DevOps engineers use rolling update strategies daily to deploy new app versions safely in Kubernetes clusters.

1

Create initial Deployment YAML with app version 1

Create a file named deployment.yaml with a Kubernetes Deployment for an app called myapp. Use image nginx:1.19. Set replicas to 3. Include labels app: myapp under metadata and spec.template.metadata. Use container name nginx.

Kubernetes

# Create deployment.yaml with Deployment for myapp using nginx:1.19 and 3 replicas
# Your code here

Hint

Use apiVersion: apps/v1 and set replicas: 3. Labels must be under both metadata and spec.template.metadata.

2

Add rolling update strategy to Deployment

Edit deployment.yaml to add a strategy section under spec. Use type: RollingUpdate. Set rollingUpdate.maxSurge to 1 and rollingUpdate.maxUnavailable to 1.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    app: myapp
spec:
  replicas: 3
  # Add rolling update strategy below
  # Your code here
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: nginx
        image: nginx:1.19
        ports:
        - containerPort: 80

Hint

Place strategy under spec. Use type: RollingUpdate and set maxSurge and maxUnavailable to 1.

3

Update Deployment to use nginx version 1.21

Change the container image in deployment.yaml from nginx:1.19 to nginx:1.21 to prepare for rolling update.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    app: myapp
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: nginx
        # Change image version to 1.21 below
        # Your code here
        ports:
        - containerPort: 80

Hint

Update the image field under containers to nginx:1.21.

4

Apply Deployment and check rollout status

Run the command kubectl apply -f deployment.yaml to update the Deployment. Then run kubectl rollout status deployment/myapp-deployment to check the rolling update status. Write the exact output you see from the rollout status command.

Kubernetes

# Run kubectl apply and rollout status commands
# Your code here

Hint

After applying, the rollout status command shows deployment "myapp-deployment" successfully rolled out when update finishes.

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