Free lesson · CKAD Prep Program · Module 3: Application deployment

Ship Canary and Blue-Green Releases

Rolling updates change everything gradually; canary and blue-green change exposure deliberately. This lesson builds both with plain Deployments plus Services, no service mesh required.

12 min reading

Objectives

Run a canary by splitting traffic between two revisions
Cut a blue-green switch with a service selector flip
Compare the two strategies on blast radius plus rollback cost
Verify each stage with endpoint and version checks before moving on

Why this matters

Some releases deserve more caution than a rolling update gives: new pricing logic, rewritten auth paths, anything where the failure mode is wrong answers rather than crashes. Canary limits the audience; blue-green limits the switch to one atomic moment. Both are exam favorites because they compose only primitives you already know.

Concepts

A canary runs the new revision beside the old under one Service, split by replica counts: 9 old plus 1 new sends roughly a tenth of traffic to the canary. Watch error rates and business metrics on the small slice, then grow it (8/2, 5/5, 0/10) or delete it. The Service selector matches both Deployments by shared labels, which is the entire trick.

Blue-green runs two full environments and flips the Service selector from blue labels to green labels in one apply. Rollback is the reverse flip, instant and total. The cost is double capacity during the switch plus the discipline of keeping both stacks truly identical.

Choose by failure shape. Canary for behavior risk you want to measure on real traffic with bounded blast radius. Blue-green for releases where partial exposure is worse than none (schema-coupled changes, stateful flows) and where instant retreat beats gradual retreat.

Worked example

Same app, two revisions, one service, canary first:

# stable serves 100 percent
kubectl create deployment shop-blue --image=shop:3.1 --replicas=4
kubectl expose deployment shop-blue --port=80  # selector app=shop
# canary joins the same service
kubectl create deployment shop-canary --image=shop:3.2 --replicas=1
kubectl label deployment shop-canary app=shop
kubectl get endpoints shop  # five addresses: four blue, one canary
# promote: scale canary up, blue down, then remove blue
kubectl scale deployment shop-canary --replicas=4
kubectl scale deployment shop-blue --replicas=0

Endpoints prove the split at every stage: count blue versus canary addresses before changing anything. For blue-green, the same two Deployments get distinct selectors and the Service flips between them with one edited selector.

Exam notes

Replica-count splitting is approximate, not exact percentages: say roughly, never exactly. Selector overlap is the classic breakage: a canary sharing too many labels steals all traffic or none. And scaling the old revision to zero keeps instant rollback alive; deleting it ends the safety net.

Quick check

A 4-question self-check. Your answers stay on your device, are never stored or sent. Only a passing score (for example 3 of 4) is saved, and only to unlock lesson progress: at least 3 correct is required before a lesson counts as complete. It never counts toward any certification assessment.

Lesson feedback

No published feedback yet.

Exercise

Design a canary for a fictional checkout change: replica counts per stage, what you measure at each stage, and the exact rollback command. Then state in one sentence when you would have chosen blue-green instead.

Pass criteria

Stages with counts plus a metric per stage; rollback is the canary scale-to-zero (or delete) with the service untouched; blue-green condition names atomic-switch or coupled-state reasoning.