Blue-Green and Canary Deployments
Ship without downtime using nothing but Deployments, Services, and labels: stand a workload up behind a Service, cut over blue-green by flipping the selector, and run a canary by weighting replica counts behind one Service.
Your mission
A rolling update — the Deployment default — is fine for most releases, but two release patterns give you more control, and both are built from parts you already know: Deployments, a Service, and labels. No service mesh, no extra controllers.
- Blue-green. Run the old version (blue) and the new version (green) side by side. A Service selects one of them by a label. To release, you flip the selector from blue to green — an instant, atomic cutover. To roll back, flip it straight back. Blue stays running the whole time, so rollback is free.
- Canary. Send a small slice of traffic to the new version while most stays on the stable one. The trick with a plain Service: it load-balances across every Pod its selector matches, in proportion to how many there are. Run 3 stable Pods and 1 canary Pod behind one Service and the canary gets ~25% of requests — a weighted release with nothing but replica counts.
The through-line: a Service routes to Pods by label, and it splits traffic evenly across all matching Pods. Master that and both strategies fall out of it.
In this lab you'll stand a workload up behind a Service, cut it over blue-green, then run a canary.
Useful aliases
In your terminal, k is aliased to kubectl and completion is configured. The
jumpbox also has k9s, jq and yq installed.