Progressive delivery concept in Kubernetes - Step-by-Step Execution

Process Flow - Progressive delivery concept

Start Deployment

↓

Deploy to Small User Group

↓

Monitor Metrics & Feedback

↓

If Issues Detected

Yes→Rollback or Fix

↓

End

No↓

Increase User Group Size

↓

Repeat Monitoring & Scaling

↓

Full Deployment to All Users

↓

End

The flow shows deploying to a small group first, monitoring, then gradually increasing users if no issues, else rollback.

Execution Sample

Kubernetes

kubectl apply -f canary-deployment.yaml
# Monitor metrics
# Increase traffic to canary
kubectl rollout status deployment/myapp
# Full rollout if stable

This sequence deploys a canary version, monitors it, then rolls out fully if stable.

Process Table

Step	Action	Deployment State	User Group Size	Monitoring Result	Next Step
1	Apply canary deployment	Canary version deployed	5% users	Pending	Monitor metrics
2	Monitor metrics	Canary running	5% users	No issues	Increase user group
3	Increase user group	Canary running	25% users	Pending	Monitor metrics
4	Monitor metrics	Canary running	25% users	No issues	Increase user group
5	Increase user group	Canary running	50% users	Pending	Monitor metrics
6	Monitor metrics	Canary running	50% users	Issues detected	Rollback canary
7	Rollback canary	Stable version restored	100% users	N/A	End deployment

💡 Rollback triggered at 50% user group due to detected issues, deployment ends with stable version.

Status Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	After Step 7
Deployment State	Stable version	Canary deployed	Canary running	Canary running	Stable version restored
User Group Size	0%	5%	25%	50%	100%
Monitoring Result	N/A	Pending	Pending	Pending	N/A

Key Moments - 3 Insights

Why do we deploy to only a small user group first instead of all users?

Deploying to a small group limits risk. If issues appear (see Step 6 in execution_table), we can rollback without affecting everyone.

What happens if monitoring detects issues during progressive delivery?

The deployment is rolled back to the stable version immediately (Step 6 and 7), preventing bad code from reaching more users.

Why do we increase user group size gradually?

Gradual increase allows careful observation of system behavior and user impact before full rollout, reducing risk of widespread failure.

Visual Quiz - 3 Questions

Look at the execution table, what is the user group size when issues are detected?

A 5%

B 25%

C 50%

D 100%

💡 Hint

Check the 'User Group Size' and 'Monitoring Result' columns at Step 6 in the execution_table.

At which step does the deployment rollback happen?

A Step 7

B Step 6

C Step 4

D Step 5

💡 Hint

Look for the 'Rollback canary' action in the 'Action' column of the execution_table.

If no issues were detected at 50% user group, what would be the next step?

A Rollback canary

B Increase user group to 100%

C Monitor metrics again

D End deployment immediately

💡 Hint

Refer to the flow in the execution_table rows 4 and 5 where no issues lead to increasing user group size.

Concept Snapshot

Progressive delivery means releasing new software gradually.
Start with a small user group (canary).
Monitor system and user feedback carefully.
If stable, increase user group size step-by-step.
If issues appear, rollback immediately.
This reduces risk and improves reliability.

Full Transcript

Progressive delivery is a method to release software updates gradually. First, a new version is deployed to a small portion of users, called a canary deployment. Then, monitoring tools check for errors or bad feedback. If no problems are found, the deployment expands to more users in steps. If issues are detected at any point, the deployment is rolled back to the stable version to protect users. This approach helps catch problems early and reduces the chance of widespread failures.

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