Canary deployments in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

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

Choose the best explanation for why teams use canary deployments.

A To gradually roll out changes to a small subset of users before full deployment

B To immediately replace all running pods with new ones without testing

C To create a backup of the current deployment before updating

D To run multiple versions of an application permanently for load balancing

💡 Hint

Think about minimizing risk when releasing new software.

Canary deployments allow gradual rollout to catch issues early by exposing new versions to a small user group first.

💻 Command Output

intermediate

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

Given the command below, what will it show?

Kubernetes

kubectl get pods -l app=myapp

A Lists all pods with label app=myapp including both stable and canary versions

B Shows only pods running the stable version of myapp

C Shows only pods running the canary version of myapp

D Returns an error because label selector is missing

💡 Hint

Label selectors filter pods by matching labels.

The command lists all pods with the label app=myapp, which includes both stable and canary pods if labeled the same.

❓ Configuration

advanced

Which Kubernetes manifest snippet correctly defines a canary deployment with 10% traffic?

Choose the manifest snippet that sets up a canary deployment routing 10% of traffic to the new version.

A

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-canary
            port:
              number: 80

B

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

C

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp.example.com
  http:
  - route:
    - destination:
        host: myapp
        subset: stable
      weight: 90
    - destination:
        host: myapp
        subset: canary
      weight: 10

D

apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

💡 Hint

Look for traffic splitting configuration in the manifest.

Option C uses Istio VirtualService to split traffic 90% to stable and 10% to canary subset, which is the correct way to control traffic percentage.

❓ Troubleshoot

advanced

Why does the canary deployment not receive any traffic despite correct configuration?

You configured a canary deployment with 10% traffic but the canary pods show zero requests. What is the most likely cause?

A The ingress controller is not installed in the cluster

B The canary pods are not running due to image pull errors

C The stable deployment has zero replicas

D The service selector does not include the canary pods' labels

💡 Hint

Check if traffic routing matches pod labels correctly.

If the service selector does not match canary pod labels, traffic won't be routed to canary pods even if they are running.

🔀 Workflow

expert

What is the correct sequence of steps for a safe canary deployment in Kubernetes?

Order the steps below to perform a safe canary deployment.

A 1,3,2,4

B 1,2,3,4

C 2,1,3,4

D 1,4,3,2

💡 Hint

Think about deploying first, then monitoring, then increasing traffic, then full rollout.

The safe canary workflow is: deploy canary, monitor, increase traffic gradually, then full rollout.

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