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.