Progressive delivery concept in Kubernetes - Commands & Configuration

Introduction

Progressive delivery helps release new software versions slowly and safely. It reduces risks by exposing changes to a small group first, then gradually to everyone.

When you want to test a new app version with a small group of users before full release

When you want to reduce downtime or errors during software updates

When you want to monitor new features and roll back quickly if problems appear

When you want to deploy updates multiple times a day without affecting all users

When you want to gather feedback from real users on new changes before full rollout

Config File - deployment.yaml

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 5
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-app:1.1
        ports:
        - containerPort: 80

This file defines a Kubernetes Deployment for the app.

replicas: number of app copies running.

strategy: RollingUpdate means new version replaces old gradually.

maxSurge: how many extra pods can run during update (1 here).

maxUnavailable: how many pods can be down during update (1 here).

This setup allows progressive delivery by updating pods one by one safely.

Commands

This command creates or updates the Deployment with the new app version and rolling update strategy.

Terminal

kubectl apply -f deployment.yaml

Expected Output

deployment.apps/my-app created

This command checks the progress of the rolling update to ensure pods update successfully one by one.

Terminal

kubectl rollout status deployment/my-app

Expected Output

deployment "my-app" successfully rolled out

This command lists all pods of the app to see how many are running the new version during the rollout.

Terminal

kubectl get pods -l app=my-app

Expected Output

NAME                       READY   STATUS    RESTARTS   AGE

my-app-5d8f7c7d7f-abc12   1/1     Running   0          2m

my-app-5d8f7c7d7f-def34   1/1     Running   0          1m

my-app-5d8f7c7d7f-ghi56   1/1     Running   0          30s

my-app-5d8f7c7d7f-jkl78   1/1     Running   0          10s

my-app-5d8f7c7d7f-mno90   1/1     Running   0          5s

If the new version causes problems, this command rolls back to the previous stable version quickly.

Terminal

kubectl rollout undo deployment/my-app

Expected Output

deployment.apps/my-app rolled back

Key Concept

If you remember nothing else from this pattern, remember: update your app gradually to catch problems early and keep users safe.

Common Mistakes

Setting maxUnavailable to 0 during rolling update

This prevents any pod from being unavailable, which can delay updates and cause longer rollout times.

Set maxUnavailable to at least 1 to allow one pod to update at a time for smooth progressive delivery.

Not checking rollout status after applying update

You might miss errors or failed updates causing downtime or broken app versions.

Always run 'kubectl rollout status' to monitor update progress and catch issues early.

Deploying new version to all pods at once

This causes full downtime or exposes all users to bugs at once.

Use rolling update strategy with maxSurge and maxUnavailable to update pods gradually.

Summary

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

Use 'kubectl apply' to deploy changes and 'kubectl rollout status' to monitor progress.

Roll back quickly with 'kubectl rollout undo' if problems occur during update.

Practice

1. What is the main goal of progressive delivery in Kubernetes?

easy

A. To avoid monitoring after deployment

B. To deploy all changes at once to all users

C. To release software changes gradually and safely

D. To delete old versions immediately after deployment

Solution

1. Step 1: Understand the concept of progressive delivery

   Progressive delivery means releasing software updates slowly to reduce risk and catch problems early.

2. Step 2: Compare options to the concept

   Only To release software changes gradually and safely describes gradual and safe release, matching the concept.

3. Final Answer:

   To release software changes gradually and safely -> Option C

4. Quick Check:

   Progressive delivery = gradual safe release [OK]

Hint: Think slow and safe rollout, not instant or risky [OK]

Common Mistakes:

• Confusing progressive delivery with instant deployment
• Ignoring the safety aspect of gradual rollout
• Assuming old versions are deleted immediately

2. Which Kubernetes feature is commonly used to run multiple versions of an application side by side for progressive delivery?

easy

A. Namespaces

B. Labels

C. Persistent Volumes

D. ConfigMaps

Solution

1. Step 1: Identify how Kubernetes distinguishes versions

   Kubernetes uses labels to tag and select different versions of deployments.

2. Step 2: Match features to use case

   Labels allow running multiple versions side by side by selecting pods with specific labels.

3. Final Answer:

   Labels -> Option B

4. Quick Check:

   Labels = version tags for deployments [OK]

Hint: Labels tag versions; namespaces separate environments [OK]

Common Mistakes:

• Confusing namespaces with version tagging
• Using ConfigMaps or volumes for version control
• Not knowing labels select pods

3. Given this Kubernetes deployment snippet for progressive delivery:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-v2
  labels:
    version: v2
spec:
  replicas: 2
  selector:
    matchLabels:
      version: v2
  template:
    metadata:
      labels:
        version: v2
    spec:
      containers:
      - name: myapp
        image: myapp:2.0

What does this configuration do?

medium

A. Deploys two pods running version 2.0 of myapp labeled as v2

B. Deletes all pods labeled v2 and replaces with version 1.0

C. Creates a service exposing version 1.0 of myapp

D. Scales the existing deployment to zero replicas

Solution

1. Step 1: Analyze deployment metadata and labels

   The deployment is named myapp-v2 and uses label version: v2 for pods.

2. Step 2: Check replicas and container image

   It creates 2 replicas running image myapp:2.0, matching label v2.

3. Final Answer:

   Deploys two pods running version 2.0 of myapp labeled as v2 -> Option A

4. Quick Check:

   Deployment with replicas=2 and image v2 = Deploys two pods running version 2.0 of myapp labeled as v2 [OK]

Hint: Look for replicas and image tags to identify deployment version [OK]

Common Mistakes:

• Confusing deployment labels with service exposure
• Assuming deletion instead of creation
• Mixing version labels with scaling actions

4. You deployed a new version of your app with label version: v2 but traffic is still going only to v1. What is a likely cause?

medium

A. Service selector is still set to version: v1

B. Deployment replicas for v2 are set to zero

C. Pods labeled v2 are not running

D. All of the above

Solution

1. Step 1: Check service selector labels

   If the service selector targets version v1, traffic won't reach v2 pods.

2. Step 2: Verify deployment replicas and pod status

   If replicas for v2 are zero or pods are not running, no v2 pods receive traffic.

3. Final Answer:

   All of the above -> Option D

4. Quick Check:

   Service selector + replicas + pod status all affect traffic [OK]

Hint: Check service selector, replicas, and pod health for traffic issues [OK]

Common Mistakes:

• Only checking one cause and ignoring others
• Assuming pods labeled v2 always run
• Not verifying service selectors

5. You want to implement progressive delivery by routing 10% of traffic to a new version v2 and 90% to v1. Which Kubernetes tool or method best supports this?

hard

A. Using multiple Deployments with labels and a Service with weighted traffic routing via Istio or another service mesh

B. Scaling down the v1 deployment to 10% replicas and scaling up v2 to 90% replicas

C. Deleting the v1 deployment and replacing it with v2 immediately

D. Using ConfigMaps to switch traffic percentages

Solution

1. Step 1: Understand traffic splitting in Kubernetes

   Kubernetes alone does not support weighted traffic routing; service meshes like Istio enable this.

2. Step 2: Evaluate options for traffic control

   Using multiple deployments with labels and Istio allows routing 10% to v2 and 90% to v1 safely.

3. Final Answer:

   Using multiple Deployments with labels and a Service with weighted traffic routing via Istio or another service mesh -> Option A

4. Quick Check:

   Weighted routing needs service mesh, not just scaling [OK]

Hint: Use service mesh for traffic weights, not just replica counts [OK]

Common Mistakes:

• Trying to control traffic by scaling replicas only
• Deleting old version immediately
• Using ConfigMaps for traffic routing