Canary deployments in Kubernetes - Commands & Configuration

Introduction

When you want to release a new version of your app safely, you can send only a small part of your users to the new version first. This helps catch problems early without affecting everyone. This method is called canary deployment.

When you want to test a new app version with a small group of users before full release

When you want to reduce risk by gradually shifting traffic to a new version

When you want to monitor new version performance and errors before full rollout

When you want to rollback quickly if the new version has issues

When you want to run two versions of your app side-by-side during an update

Config File - canary-deployment.yaml

canary-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 5
  selector:
    matchLabels:
      app: my-app
      version: stable
  template:
    metadata:
      labels:
        app: my-app
        version: stable
    spec:
      containers:
      - name: my-app-container
        image: my-app:1.0
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
      version: canary
  template:
    metadata:
      labels:
        app: my-app
        version: canary
    spec:
      containers:
      - name: my-app-container
        image: my-app:1.1
---
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

This file creates two deployments: one stable with 5 replicas running version 1.0, and one canary with 1 replica running version 1.1. The service selects pods with label app: my-app, so it sends traffic to both stable and canary pods. This setup lets you send about 1/6 of traffic to the new version for testing.

Commands

This command creates the stable and canary deployments and the service that routes traffic to both versions.

Terminal

kubectl apply -f canary-deployment.yaml

Expected Output

deployment.apps/my-app created

deployment.apps/my-app-canary created

service/my-app-service created

This command lists all pods with label app=my-app to verify both stable and canary pods are running.

Terminal

kubectl get pods -l app=my-app -o wide

Expected Output

NAME                          READY   STATUS    RESTARTS   AGE   IP           NODE

my-app-abcdef1234-xyz12       1/1     Running   0          1m    10.244.1.5   node1

my-app-abcdef1234-xyz34       1/1     Running   0          1m    10.244.1.6   node2

my-app-canary-12345abcde-xy1  1/1     Running   0          30s   10.244.1.7   node3

→

-l - Filter pods by label

→

-o wide - Show extra pod details like IP and node

This command shows the service details to confirm it selects pods with label app=my-app and routes traffic to both stable and canary pods.

Terminal

kubectl describe service my-app-service

Expected Output

Name:                     my-app-service

Namespace:                default

Labels:                   <none>

Selector:                 app=my-app

Type:                     ClusterIP

IP:                       10.96.0.1

Port:                     <unset>  80/TCP

TargetPort:               8080/TCP

Endpoints:                10.244.1.5:8080,10.244.1.6:8080,10.244.1.7:8080

Session Affinity:         None

Events:                   <none>

This command checks the rollout status of the canary deployment to ensure the new version is running smoothly.

Terminal

kubectl rollout status deployment/my-app-canary

Expected Output

deployment "my-app-canary" successfully rolled out

Key Concept

If you remember nothing else from this pattern, remember: run the new version alongside the old one with fewer pods and route only a small share of traffic to it for safe testing.

Common Mistakes

Creating only one deployment and replacing the old version immediately

This causes all users to get the new version at once, increasing risk of failure without gradual testing.

Create a separate canary deployment with fewer replicas and run it alongside the stable deployment.

Service selector only matches stable pods, ignoring canary pods

Traffic will not reach the canary pods, so the new version is not tested with real users.

Use a service selector that matches both stable and canary pods by a common label.

Not checking rollout status of the canary deployment

You might miss errors or crashes in the new version before sending traffic.

Use 'kubectl rollout status' to verify the canary deployment is healthy before increasing traffic.

Summary

Create two deployments: stable with most replicas and canary with fewer replicas running the new version.

Use a service that selects both stable and canary pods to split traffic between versions.

Check pods and rollout status to ensure the canary version is running well before 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