DEVOPS / A CONCEPT NOTE
Canary Deployments
rolling out changes to a small subset before full release
Overview · mechanism
pitfall · examples
01 / THE SHORT VERSION
The idea in a few sentences.
A canary deployment routes a small percentage of traffic (e.g., 5%) to the new version while the rest hits the stable version. You monitor metrics — error rate, latency, throughput — and if everything looks good, you gradually ramp up to 100%. If something goes wrong, you route all traffic back to the old version instantly.
02 / FOLLOW THE MECHANISM
How a canary rollout works
New version
is deployed alongside the stable version, both behind the same load balancer or service mesh.
Traffic split
the load balancer sends 5% of requests to the canary, 95% to stable.
Monitoring
error rate, p99 latency, and business metrics are compared between canary and baseline.
Auto-promotion
if the canary passes the observation window (e.g., 10 min with no errors), traffic shifts to 25%, 50%, then 100%.
Rollback
if the canary shows elevated errors, all traffic goes back to stable and the canary is terminated.
04 / COMMAND NOTES
Read the command, then the result.
Inspect the flags and arguments before trying an example. Snippets can need local setup, replacement values, or resources in your own environment.
update the canary pod's image
kubectl set image deployment/my-app canary=my-app:v2rollback a deployment
kubectl rollout undo deployment/my-app05 / CHECK YOURSELF
Could you explain Canary Deployments to a teammate?
Try it out loud in two sentences: what it is, and the one detail that changes the picture. If you stall, the gap is the part to reread.
Up next in Delivery & operationsFeature Flagsturning features on and off without deploying code