Progressive delivery concept in Kubernetes - Mini Project: Build & Apply

Progressive Delivery Concept with Kubernetes

📖 Scenario: You work as a DevOps engineer for a company that wants to safely release new versions of their web application. Instead of deploying the new version to all users at once, you will use progressive delivery to gradually roll out the update. This helps catch issues early and reduces risk.

🎯 Goal: Build a simple Kubernetes deployment manifest that uses labels and selectors to manage a canary release. You will create the initial deployment, add a canary version with a label, and then use a service selector to route traffic to both versions progressively.

📋 What You'll Learn

Create a Kubernetes deployment manifest for the stable version of the app

Add a canary deployment with a specific label

Create a service that selects both stable and canary pods using labels

Print the final combined manifest to verify the setup

💡 Why This Matters

🌍 Real World

Progressive delivery helps companies release new software versions safely by controlling how many users get the update at a time.

💼 Career

DevOps engineers use Kubernetes manifests with labels and services to manage canary deployments and reduce risk during software releases.

1

Create the stable deployment manifest

Create a Kubernetes deployment manifest named stable-deployment.yaml with these exact specifications: deployment name webapp-stable, app label webapp, container image nginx:1.21, and 3 replicas.

Kubernetes

# Create a deployment manifest for the stable version
# Your code here

Hint

Use version: stable as a label to identify the stable pods.

2

Add the canary deployment manifest

Add a new deployment manifest named canary-deployment.yaml with deployment name webapp-canary, app label webapp, version label canary, container image nginx:1.22, and 1 replica.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-stable
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
      version: stable
  template:
    metadata:
      labels:
        app: webapp
        version: stable
    spec:
      containers:
      - name: nginx
        image: nginx:1.21

# Add the canary deployment manifest below
# Your code here

Hint

Use version: canary label to identify the canary pods.

3

Create a service selecting both stable and canary pods

Create a Kubernetes service manifest named webapp-service.yaml that selects pods with label app: webapp (both stable and canary). Use port 80 for the service and target port 80 for the container.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-stable
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
      version: stable
  template:
    metadata:
      labels:
        app: webapp
        version: stable
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: webapp
      version: canary
  template:
    metadata:
      labels:
        app: webapp
        version: canary
    spec:
      containers:
      - name: nginx
        image: nginx:1.22

# Add a service manifest selecting pods with label app: webapp
# Your code here

Hint

The service selector should match app: webapp to include both stable and canary pods.

4

Print the combined manifest

Print the entire combined Kubernetes manifest containing the stable deployment, canary deployment, and service to verify the progressive delivery setup.

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-stable
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
      version: stable
  template:
    metadata:
      labels:
        app: webapp
        version: stable
    spec:
      containers:
      - name: nginx
        image: nginx:1.21
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: webapp
      version: canary
  template:
    metadata:
      labels:
        app: webapp
        version: canary
    spec:
      containers:
      - name: nginx
        image: nginx:1.22
---
apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  selector:
    app: webapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

# Print the full manifest below
# Your code here

Hint

Use a print statement to output the full manifest string.

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