Blue/Green and Canary Deployment Strategies

Kubernetes has no API object literally named "blue-green" or "canary" — the CKAD curriculum calls for implementing these with plain primitives: labels, a Service's selector, and ordinary Deployments. A Service routes traffic to whichever Pods currently match its spec.selector; it has no idea which Deployment those Pods came from.

A blue/green release runs two full Deployments at once — "blue" (live) and "green" (new) — each with its own distinct label such as version: blue or version: green. The Service selector initially matches blue. Once green is verified, the cutover is a single edit to the Service's selector so it matches green's Pods instead — new connections land on green immediately, and rolling back is the same edit in reverse, instant because blue's Pods never stopped running.

# Before: Service routes to the "blue" Deployment's Pods
spec:
  selector:
    app: web
    version: blue

# After: same Service, now routing to "green" instead
spec:
  selector:
    app: web
    version: green

A canary release instead runs a small second Deployment that shares the same labels the Service already selects on — typically just app: web, without a version label in the selector at all — so the Service load-balances across both the stable Deployment's Pods and the canary's. If stable runs 9 replicas and canary runs 1, roughly one in ten connections reaches the canary, because a Service spreads connections across all matching Pods without favoring one Deployment over another.

That "roughly" matters: a plain Kubernetes Service has no concept of a configured traffic percentage — the split just falls out of the replica ratio, connection by connection, with no guarantee any single request lands one way or the other. Precise, percentage-exact traffic splitting needs a service mesh or an Ingress controller with weighted-routing support; it isn't a feature of the core Service object itself.