Canary deployments in Kubernetes - Step-by-Step Execution

Process Flow - Canary deployments

Start: New version ready

↓

Deploy small subset of pods with new version

↓

Monitor performance and errors

↓

Increase new

↓

version pods

↓

Fix issues

↓

Repeat until

↓

full rollout

↓

Done

The flow shows deploying a small part of the app with the new version, monitoring it, then either increasing rollout or rolling back based on results.

Execution Sample

Kubernetes

kubectl apply -f deployment-v2.yaml
kubectl set image deployment/myapp myapp=myapp:v2 --record
kubectl rollout status deployment/myapp
kubectl get pods -l app=myapp
# Monitor logs and metrics
kubectl rollout undo deployment/myapp

This sequence deploys a new version, updates image for canary, checks rollout status, monitors pods, and can rollback if needed.

Process Table

Step	Action	Pods with old version	Pods with new version	Result	Next Step
1	Deploy initial canary pods with new version	9	1	1 pod runs new version, 9 old	Monitor performance
2	Monitor logs and metrics	9	1	No errors detected	Increase new version pods
3	Scale new version pods to 3	7	3	More pods running new version	Monitor performance
4	Monitor logs and metrics	7	3	Minor errors detected	Decide to rollback or continue
5	Rollback to old version	10	0	All pods back to old version	Fix issues and retry later
6	End	10	0	Deployment stable with old version	Stop

💡 Rollback triggered due to errors in canary pods, deployment reverted to old version

Status Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	Final
Pods with old version	10	9	7	10	10
Pods with new version	0	1	3	0	0
Errors detected	No	No	Yes (minor)	N/A	N/A

Key Moments - 3 Insights

Why do we start with only a few pods running the new version instead of all at once?

Starting with a small number limits risk if the new version has bugs. Execution table step 1 shows only 1 pod updated to catch issues early.

What happens if errors are detected during monitoring?

If errors appear, the deployment can be rolled back to the old version to keep the app stable, as shown in step 5 of the execution table.

Why do we monitor performance after increasing new version pods?

Increasing new pods gradually helps confirm stability at larger scale before full rollout, shown in steps 3 and 4 where monitoring guides next action.

Visual Quiz - 3 Questions

Look at the execution table, how many pods run the new version after step 3?

A 3

B 1

C 7

D 10

💡 Hint

Check the 'Pods with new version' column at step 3 in the execution table.

At which step does the deployment rollback to the old version?

A Step 4

B Step 5

C Step 2

D Step 6

💡 Hint

Look for the row mentioning rollback in the 'Action' column of the execution table.

If no errors were detected at step 4, what would likely happen next?

A Rollback to old version

B Stop deployment

C Increase new version pods further

D Delete all pods

💡 Hint

Refer to the 'Result' and 'Next Step' columns at step 4 in the execution table.

Concept Snapshot

Canary deployments gradually roll out new app versions.
Start with a small subset of pods running new code.
Monitor performance and errors carefully.
If stable, increase new pods until full rollout.
If errors occur, rollback to old version.
This reduces risk of bad releases.

Full Transcript

Canary deployments in Kubernetes involve deploying a new version of an application to a small number of pods first. This limits risk by exposing only a small part of the system to potential bugs. After deploying the initial canary pods, you monitor logs and metrics to check for errors or performance issues. If everything looks good, you increase the number of pods running the new version step by step, monitoring at each stage. If errors are detected, you rollback the deployment to the old stable version to keep the application reliable. This process repeats until the new version is fully rolled out or fixed. The execution table shows each step with pod counts and decisions, helping visualize how canary deployments work in practice.

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