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.