Canary deployments in Kubernetes - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the deployment strategy as Canary in the Kubernetes deployment manifest.

Kubernetes

strategy:
  type: [1]

Drag options to blanks, or click blank then click option'

ARollingUpdate

BCanary

CBlueGreen

DRecreate

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'RollingUpdate' instead of 'Canary' for canary deployments.

Using 'Recreate' which deletes all old pods before starting new ones.

The type field under strategy defines the deployment method. For canary deployments, it should be set to Canary.

2fill in blank

medium

Complete the code to define the percentage of traffic routed to the canary version.

Kubernetes

spec:
  strategy:
    canary:
      trafficPercentage: [1]

Drag options to blanks, or click blank then click option'

A0

B100

C10

D50

Attempts:

3 left

💡 Hint

Common Mistakes

Setting trafficPercentage to 100, which sends all traffic to canary immediately.

Setting trafficPercentage to 0, which sends no traffic to canary.

The trafficPercentage field controls how much traffic goes to the canary pods. Typically, it starts low like 10%.

3fill in blank

hard

Fix the error in the command to apply the canary deployment manifest.

Kubernetes

kubectl [1] -f canary-deployment.yaml

Drag options to blanks, or click blank then click option'

Adelete

Bdescribe

Cget

Dapply

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'delete' which removes resources instead of creating/updating.

Using 'get' which only retrieves information.

The kubectl apply command is used to create or update resources from a manifest file.

4fill in blank

hard

Fill both blanks to define a canary deployment with 3 replicas and 20% traffic.

Kubernetes

spec:
  replicas: [1]
  strategy:
    canary:
      trafficPercentage: [2]

Drag options to blanks, or click blank then click option'

A3

B5

C20

D50

Attempts:

3 left

💡 Hint

Common Mistakes

Setting replicas too high for initial canary testing.

Setting trafficPercentage too high, risking full traffic shift.

The replicas field sets the number of pod copies. The trafficPercentage under canary sets the traffic split to the canary pods.

5fill in blank

hard

Fill all three blanks to create a canary deployment manifest snippet with label 'app: web', 4 replicas, and 15% traffic.

Kubernetes

metadata:
  labels:
    app: [1]
spec:
  replicas: [2]
  strategy:
    canary:
      trafficPercentage: [3]

Drag options to blanks, or click blank then click option'

Aweb

B4

C15

Dapi

Attempts:

3 left

💡 Hint

Common Mistakes

Using wrong label values that don't match selectors.

Setting replicas or trafficPercentage incorrectly.

The app label identifies the application. replicas sets pod count. trafficPercentage controls canary traffic.

Practice

1. What is the main purpose of a canary deployment in Kubernetes?

easy

A. To release a new version to a small group of users first to reduce risk

B. To deploy all users to the new version immediately

C. To delete the old version before deploying the new one

D. To run multiple versions permanently without any rollout

Solution

1. Step 1: Understand canary deployment concept

   Canary deployments release new software versions to a small subset of users first to test stability and reduce risk.

2. Step 2: Compare options with this concept

   Only To release a new version to a small group of users first to reduce risk describes this gradual rollout to a small group to reduce risk.

3. Final Answer:

   To release a new version to a small group of users first to reduce risk -> Option A

4. Quick Check:

   Canary deployment = gradual rollout [OK]

Hint: Canary means small test group rollout first [OK]

Common Mistakes:

• Thinking canary deploys to all users at once
• Confusing canary with blue-green deployment
• Assuming canary deletes old versions immediately

2. Which Kubernetes resource is typically used to manage canary deployments?

easy

A. Deployment

B. ConfigMap

C. ServiceAccount

D. PersistentVolume

Solution

1. Step 1: Identify resource for managing app versions

   Deployments manage application versions and rollout strategies in Kubernetes.

2. Step 2: Match resource to canary deployment

   Canary deployments use multiple Deployments with different labels to control traffic.

3. Final Answer:

   Deployment -> Option A

4. Quick Check:

   Canary uses Deployment resource [OK]

Hint: Deployments control app versions and rollout [OK]

Common Mistakes:

• Choosing ConfigMap which stores config, not versions
• Selecting ServiceAccount which manages permissions
• Picking PersistentVolume which handles storage

3. Given this snippet of a Kubernetes Deployment YAML for canary rollout, what percentage of traffic will go to the canary pods?

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

Assuming the stable deployment has 8 replicas with label version: stable and the Service routes traffic evenly by label.

medium

A. 20%

B. 25%

C. 80%

D. 50%

Solution

1. Step 1: Calculate total replicas

   Stable has 8 replicas, canary has 2 replicas, total = 8 + 2 = 10 replicas.

2. Step 2: Calculate canary traffic percentage

   Traffic is split evenly by label, so canary gets 50% traffic regardless of pod count.

3. Final Answer:

   50% -> Option D

4. Quick Check:

   Service splits traffic evenly by label = 50% canary [OK]

Hint: Check how Service splits traffic: by pods or labels [OK]

Common Mistakes:

• Assuming traffic splits by pod count instead of labels
• Ignoring label-based routing in Service
• Miscounting total replicas

4. You applied a canary Deployment but users report they see only the old version. What is the most likely cause?

medium

A. The image tag in the canary Deployment is incorrect

B. The Deployment replicas are set to zero

C. The Service selector does not include the canary label

D. The pod resource limits are too high

Solution

1. Step 1: Understand how Service routes traffic

   Service routes traffic to pods matching its selector labels.

2. Step 2: Identify why canary pods get no traffic

   If Service selector misses canary label, canary pods won't receive traffic, so users see only old version.

3. Final Answer:

   The Service selector does not include the canary label -> Option C

4. Quick Check:

   Service selector missing canary label = no canary traffic [OK]

Hint: Check Service selector matches canary pod labels [OK]

Common Mistakes:

• Assuming zero replicas without checking
• Blaming image tag without logs
• Ignoring Service selector labels

5. You want to roll out a canary deployment with 10% traffic to the new version and 90% to stable. You have 10 stable pods and 2 canary pods. How should you configure the Service to achieve this traffic split?

hard

A. Set Service selector to include both stable and canary labels and use weighted routing with 10% weight on canary

B. Create two Services, one for stable and one for canary, and use an Ingress with traffic splitting

C. Use a single Deployment with 12 replicas and update image tag gradually

D. Set Service selector to only stable label and manually scale canary pods to 1

Solution

1. Step 1: Understand traffic splitting in Kubernetes Service

   Standard Kubernetes Service does not support weighted traffic splitting by itself.

2. Step 2: Identify method to split traffic by percentage

   Using two Services and an Ingress or service mesh allows weighted traffic splitting (e.g., 10% to canary, 90% to stable).

3. Step 3: Evaluate options

   Create two Services, one for stable and one for canary, and use an Ingress with traffic splitting describes creating two Services and using Ingress for traffic splitting, which is the correct approach.

4. Final Answer:

   Create two Services, one for stable and one for canary, and use an Ingress with traffic splitting -> Option B

5. Quick Check:

   Weighted traffic split requires Ingress or service mesh [OK]

Hint: Use Ingress or service mesh for weighted traffic split [OK]

Common Mistakes:

• Expecting Service selector to do weighted routing
• Scaling pods to control traffic percentage
• Using single Deployment for canary traffic split