Progressive delivery concept in Kubernetes - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is progressive delivery in software deployment?

Progressive delivery is a way to release new software features slowly to a small group of users first, then gradually to everyone. It helps catch problems early and reduce risks.

beginner

Name two common techniques used in progressive delivery.

Two common techniques are canary releases and feature flags. Canary releases send new versions to a small user group. Feature flags turn features on or off without new deployments.

intermediate

How does Kubernetes support progressive delivery?

Kubernetes supports progressive delivery by allowing multiple versions of an app to run together. Tools like Argo Rollouts help manage canary releases and gradual traffic shifting.

beginner

What is a canary release?

A canary release is when a new version of software is given to a small group of users first. If it works well, it is rolled out to more users. This reduces the chance of big problems.

intermediate

Why is monitoring important in progressive delivery?

Monitoring helps detect issues early during progressive delivery. It tracks errors, performance, and user feedback so teams can stop or fix a release before it affects many users.

What is the main goal of progressive delivery?

A Deploy all features to all users at once

B Reduce risk by releasing features gradually

C Avoid testing new software versions

D Remove old versions immediately

Progressive delivery aims to reduce risk by releasing new features slowly to a small group first.

Which Kubernetes tool helps manage canary releases?

A Argo Rollouts

B kubectl get pods

C Helm charts

D Docker Compose

Argo Rollouts is a Kubernetes tool designed to manage progressive delivery techniques like canary releases.

What does a feature flag do?

A Turns features on or off without redeploying

B Deletes old software versions

C Monitors server health

D Scales pods automatically

Feature flags allow teams to enable or disable features dynamically without new deployments.

In progressive delivery, what is a canary release?

A Rolling back to a previous version

B Deploying software to all users simultaneously

C Releasing new software to a small user group first

D Testing software only in development

A canary release means giving the new version to a small group first to test it in real conditions.

Why is monitoring critical during progressive delivery?

A To avoid using feature flags

B To speed up deployment

C To increase server costs

D To detect problems early and stop bad releases

Monitoring helps catch issues early so teams can fix or stop a release before it affects many users.

Explain what progressive delivery is and why it is useful in software deployment.

Think about how releasing slowly helps avoid big mistakes.

Describe how Kubernetes can be used to implement progressive delivery.

Consider how Kubernetes manages app versions and traffic.

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