Progressive delivery concept in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the main goal of progressive delivery in Kubernetes?

Progressive delivery is a modern approach in Kubernetes deployments. What is its primary goal?

A To gradually roll out changes to a subset of users to reduce risk

B To deploy all changes immediately to all users for faster updates

C To manually update each pod one by one without automation

D To rollback all changes automatically without monitoring

💡 Hint

Think about how to reduce impact of errors during deployment.

Progressive delivery aims to reduce risk by releasing updates gradually to a small group before full rollout.

💻 Command Output

intermediate

What is the output of this kubectl command for a canary deployment?

Given a deployment with a canary strategy, what does this command output?

Kubernetes

kubectl get pods -l app=myapp,version=canary

A Shows an error because label selector syntax is wrong

B Lists all pods regardless of labels

C Lists pods labeled with app=myapp and version=canary only

D Lists pods labeled with app=myapp but ignores version label

💡 Hint

Check how label selectors filter pods.

The command filters pods with both labels app=myapp and version=canary, showing only canary pods.

🔀 Workflow

advanced

Which step correctly describes a blue-green deployment workflow in Kubernetes?

Choose the correct sequence step for switching traffic in a blue-green deployment.

A Update blue environment and keep traffic on green indefinitely

B Update green environment, switch service to green, then delete blue

C Switch service to blue environment before updating green

D Delete blue environment first, then update green environment

💡 Hint

Think about minimizing downtime and risk during traffic switch.

Blue-green deployment updates the inactive environment (green), switches traffic to it, then removes the old (blue) environment.

❓ Troubleshoot

advanced

Why might a canary deployment not receive any traffic in Kubernetes?

You deployed a canary version but notice no traffic reaches it. What is a likely cause?

A Service selector labels do not match canary pods labels

B Canary pods are running but have no CPU requests set

C The deployment has too many replicas for canary

D The cluster has insufficient nodes for canary pods

💡 Hint

Check how services route traffic to pods.

If service selectors don't match canary pod labels, traffic won't be routed to canary pods.

✅ Best Practice

expert

Which practice best supports progressive delivery in Kubernetes environments?

To implement progressive delivery effectively, which practice is most important?

A Deploy all changes at once to reduce complexity

B Manually check logs after full deployment before rollback

C Avoid using feature flags to keep deployment simple

D Automate monitoring and rollback based on real-time metrics

💡 Hint

Think about how to detect and fix issues quickly during rollout.

Automated monitoring and rollback allow quick response to problems during progressive delivery, reducing risk.

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