How to Implement Canary Deployments on Kubernetes: Step‑by‑Step Guide

Canary Release on Kubernetes

What is a Canary Release?

A canary release (also called gray‑scale release) originates from 17th‑century coal miners who used canaries to detect toxic gas; similarly, a small fraction of traffic (often 1–2 % of servers) is upgraded first to validate a new version before a full rollout.

Benefits and Drawbacks

Advantages: flexible, customizable strategies, can target specific traffic segments, and limits impact of failures to a small user base. Drawbacks: incomplete coverage makes fault isolation harder when issues affect users not included in the canary group.

Step‑by‑Step Implementation

Open two terminal tabs to perform the rollout.

Monitor existing pods: kubectl get pods -l app=myapp -n blue-green -w Deploy the new image and pause the rollout:

kubectl set image deployment myapp-v1 myapp=janakiramm/myapp:v2 -n blue-green && kubectl rollout pause deployment myapp-v1 -n blue-green

Observe the pod list in the first tab; the new pod will appear in Pending or ContainerCreating state until the rollout is resumed.

When the new version is verified, resume the rollout: kubectl rollout resume deployment myapp-v1 -n blue-green Check replica sets to see both the old and new versions: kubectl get rs -n blue-green If a problem is detected, view rollout history: kubectl rollout history deployment myapp-v1 -n blue-green and roll back to a previous revision, e.g.,

kubectl rollout undo deployment myapp-v1 -n blue-green --to-revision=1

Verify the final state of replica sets with detailed output:

kubectl get rs -n blue-green -o wide

Key Observations

Pausing the deployment creates a temporary gap where the new pods are not serving traffic, allowing safe validation. After a successful validation, resuming the rollout updates the remaining pods. Rolling back restores the previous replica set and creates a new revision, which can be inspected via the rollout history.