The CKAD syllabus contains one line that quietly worries a lot of candidates: “Use Kubernetes primitives to implement common deployment strategies (e.g. blue/green or canary).” It sounds like it needs a service mesh, an ingress controller with weighted routing, or a progressive-delivery tool like Argo Rollouts. It does not. On the exam you implement both strategies with three objects you already know cold: Deployments, Services, and labels. Everything else is a distraction.
This guide treats blue/green and canary as mechanical label-shuffling exercises. By the end you will be able to read a scenario, decide whether it wants an all-at-once cutover or a gradual traffic shift, and write the YAML and kubectl commands from memory under the two-hour clock. It falls squarely inside the Application Deployment domain, worth roughly 20% of the exam, and it layers directly on top of the rolling updates you already practise.
The One Mental Model: Services Route by Labels
Before either strategy makes sense, internalise the single fact that powers both. A Service does not point at Pods by name. It points at any Pod whose labels match its selector. Change which Pods carry the matching label, and you have changed where traffic goes — instantly, with no rescheduling and no downtime.
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web
version: blue # <-- this line decides everything
ports:
- port: 80
targetPort: 8080That selector is the steering wheel. Blue/green is “flip the wheel from blue to green in one move.” Canary is “leave the wheel pointed at a label that several Deployments share, and control the mix by counting replicas.” Once you see traffic routing as a label-matching problem, both strategies collapse into a few commands.
If your Service-and-selector fundamentals are shaky, pause and review the CKAD services and networking guide first — this whole topic assumes you can create a Service and reason about its selector without thinking.
Strategy 1: Blue/Green — Two Full Environments, One Instant Switch
A blue/green deployment runs two complete versions side by side. Blue is the current production version serving all traffic. Green is the new version, fully deployed and tested, receiving none. When you are confident in green, you flip the Service selector so 100% of traffic moves to green in a single atomic change. If anything breaks, you flip back — rollback is one command and takes effect immediately because blue was never torn down.
Step 1: Deploy Blue (the current version)
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-blue
spec:
replicas: 3
selector:
matchLabels:
app: web
version: blue
template:
metadata:
labels:
app: web
version: blue
spec:
containers:
- name: web
image: myapp:1.0
ports:
- containerPort: 8080Notice each Pod carries two labels: app: web (the constant that says “I am part of this app”) and version: blue (the discriminator). The Service above selects on both, so right now it only reaches blue Pods.
Step 2: Deploy Green alongside it
Green is an identical Deployment with version: green and the new image. It is created and fully running before it takes any traffic:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-green
spec:
replicas: 3
selector:
matchLabels:
app: web
version: green
template:
metadata:
labels:
app: web
version: green
spec:
containers:
- name: web
image: myapp:2.0
ports:
- containerPort: 8080At this point the cluster runs six Pods, but the Service still selects version: blue, so green sits idle. This is exactly when you would run smoke tests against green — reach it directly with a temporary Service or a kubectl port-forward deploy/web-green 8080:8080.
Step 3: Flip the switch
The cutover is a one-line patch to the Service selector:
kubectl patch service web \
-p '{"spec":{"selector":{"app":"web","version":"green"}}}'The moment that command returns, every new connection lands on green. To roll back, patch it right back to blue. This is the property the exam loves about blue/green: instant, reversible cutover with zero in-flight version mixing — a request is served entirely by one version or the other, never half by each.
| Property | Blue/Green |
|---|---|
| Traffic split during rollout | None — 0% or 100%, nothing in between |
| Rollback speed | Instant (one patch back to blue) |
| Resource cost | 2× — both versions run at full scale |
| Version mixing | Never — a request hits one version only |
| Best for | Risky releases, DB migrations, “no mixed traffic” requirements |
When the exam question mentions “no downtime,” “instant rollback,” or “clients must never see two versions at once,” it is describing blue/green.
Strategy 2: Canary — Shift a Slice of Traffic First
A canary deployment releases the new version to a small fraction of traffic, watches it, and widens the rollout only if it behaves. The trick without a service mesh: run the stable and canary Deployments so their Pods share the label the Service selects on, then control the traffic ratio by counting replicas. A Service load-balances roughly evenly across all matching Pods, so 9 stable Pods + 1 canary Pod ≈ 10% canary traffic.
Step 1: A Service that selects only the shared label
The key difference from blue/green: the Service selector is deliberately loose — it matches the common label only, not the version.
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web # note: no "version" here — matches BOTH tracks
ports:
- port: 80
targetPort: 8080Step 2: Stable and canary Deployments both carry app: web
# Stable: 9 replicas of v1
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-stable
spec:
replicas: 9
selector:
matchLabels: { app: web, track: stable }
template:
metadata:
labels: { app: web, track: stable }
spec:
containers:
- name: web
image: myapp:1.0
---
# Canary: 1 replica of v2
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-canary
spec:
replicas: 1
selector:
matchLabels: { app: web, track: canary }
template:
metadata:
labels: { app: web, track: canary }
spec:
containers:
- name: web
image: myapp:2.0Ten Pods total, all matching app: web, so the Service spreads traffic across all of them. One of ten is the canary → about 10% of requests hit v2. The track label lets you tell the two apart and lets each Deployment own its own Pods, while the Service ignores track entirely.
Step 3: Widen or abort by scaling
Increasing the canary’s share is just arithmetic on replica counts:
# Go from ~10% to ~50%: 5 canary + 5 stable
kubectl scale deployment web-canary --replicas=5
kubectl scale deployment web-stable --replicas=5
# Happy? Complete the rollout: canary to full, stable to zero
kubectl scale deployment web-canary --replicas=10
kubectl scale deployment web-stable --replicas=0
# Unhappy? Abort instantly:
kubectl scale deployment web-canary --replicas=0Once the canary is at full scale and stable is at zero, you clean up by deleting web-stable (and typically renaming/relabeling canary to become the new stable for the next cycle).
| Property | Canary |
|---|---|
| Traffic split during rollout | Gradual — controlled by replica ratio |
| Rollback speed | Fast (scale canary to 0) |
| Resource cost | ~1× total (you rebalance, not double) |
| Version mixing | Yes — both versions serve simultaneously |
| Best for | Validating a release on real traffic before full commit |
When the question mentions “expose to a small percentage of users,” “gradually increase,” or “monitor the new version on real traffic first,” it is describing canary.
Blue/Green vs. Canary vs. Rolling Update: Picking the Right One
The exam rewards choosing the strategy that matches the constraints in the scenario. Keep this decision table in your head:
| Signal in the question | Strategy |
|---|---|
| ”Update in place, one Pod at a time, minimal extra resources” | Rolling update (default Deployment behaviour) |
| “Instant cutover, instant rollback, never mix versions” | Blue/green |
| ”Release to 10% of users, watch, then ramp up” | Canary |
| ”Downtime is acceptable, replace everything at once” | Recreate (strategy.type: Recreate) |
Rolling update is the built-in default and the subject of its own dedicated CKAD guide — it changes the image on a single Deployment and lets the Deployment controller replace Pods incrementally. Blue/green and canary are the two you build manually from primitives, and they are what this syllabus line is testing.
Fast Imperative Moves You’ll Actually Use
Under time pressure you generate manifests rather than type them from scratch. These are the highest-leverage commands:
# Skeleton a Deployment, then edit labels/replicas in the file
kubectl create deployment web-green --image=myapp:2.0 \
--replicas=3 --dry-run=client -o yaml > green.yaml
# Change the live Service selector (the blue/green flip)
kubectl patch service web \
-p '{"spec":{"selector":{"version":"green"}}}'
# Or edit it interactively
kubectl edit service web
# Scale the canary/stable ratio
kubectl scale deployment web-canary --replicas=5
# Confirm which Pods a Service actually targets
kubectl get endpoints web -o wide
kubectl get pods -l app=web -L version,trackThat last pair is your verification reflex. kubectl get endpoints web lists the Pod IPs currently behind the Service — if green isn’t in there after a flip, your labels don’t match. kubectl get pods -l app=web -L version,track prints every app Pod with its version and track columns so you can see the split at a glance. Keep the full CKAD kubectl cheat sheet open while you drill these.
Verifying and Troubleshooting a Cutover
Three failure signatures cover almost everything that goes wrong with these strategies on the exam:
- Traffic doesn’t move after a blue/green flip. The Service selector and the target Pods’ labels disagree. Run
kubectl get endpoints web— empty or wrong IPs means the selector matches nothing. Re-check that green Pods carry the exact label you patched the Service to. - The canary gets too much or too little traffic. Your replica ratio is off, or some Pods aren’t
Ready. A Pod that isn’t Ready is pulled from the Service endpoints, so a canary with a failing readiness probe silently receives zero traffic. Confirm withkubectl get pods -l app=weband verify probes — this is where liveness and readiness probes intersect with deployment strategy. - Both versions get traffic when you wanted a clean blue/green. Your Service selector is too loose (matching only
app: web) so it’s picking up both tracks. Tighten it to include theversionlabel. This is the exact mistake that turns an intended blue/green into an accidental canary.
The verification loop is always the same: patch or scale, then immediately kubectl get endpoints and kubectl get pods -l <selector> to confirm reality matches intent. Never trust that the command “worked” without looking at the endpoints.
How This Fits the Rest of the Exam
Deployment strategies don’t live in isolation. A blue/green flip depends on Services and selectors (services and networking); a safe canary depends on correct readiness probes so unhealthy Pods stay out of rotation (probes); and both assume you can drive a Deployment’s replicas and image comfortably (rolling updates). Seeing them as one connected system — labels steering Services, replicas weighting traffic, probes gating readiness — is what turns a slow, uncertain answer into a 90-second one. For the full weighting of every domain, keep the CKAD exam domains breakdown as your map.
Practice Until the Flip Is Reflex
Reading these YAML blocks is not the same as writing them against a live cluster with the clock running. The CKAD is a performance exam — you are graded on working objects, not multiple-choice recall — so the only preparation that transfers is repetition in a real terminal. Build a blue Deployment and a Service that selects it. Add a green Deployment, port-forward to smoke-test it, then kubectl patch the Service to green and confirm with kubectl get endpoints. Tear it down and rebuild it as a canary: one loose Service, two tracks, and shift the ratio with kubectl scale. Do each three times and the muscle memory sticks.
If you want that repetition under realistic exam conditions — a browser-based terminal, timed scenarios, and a detailed explanation for every task — the Sailor.sh CKAD Certification Ready Mock Exam Bundle runs five full performance labs that cover deployment strategies alongside the rest of the syllabus. It’s built as hands-on practice, not a question dump, so you finish knowing you can do a blue/green flip, not just describe one. Warm up first with the free CKAD practice guide to make sure your cluster reflexes are sharp before you commit to a full mock.
Frequently Asked Questions
Do I need a service mesh or Ingress controller to do canary deployments on the CKAD?
No. The exam expects you to implement canary with core primitives: two Deployments whose Pods share the label the Service selects on, with the traffic ratio controlled by replica counts. Service meshes and weighted Ingress give you finer, percentage-exact control in the real world, but they are out of scope for CKAD and unnecessary for the tasks you’ll be graded on.
What is the core difference between blue/green and canary?
Blue/green switches 100% of traffic from the old version to the new version in a single atomic step by changing the Service selector — no request is ever served by a mix of versions. Canary shifts traffic gradually (say 10% → 50% → 100%) by adjusting replica ratios, so both versions serve real traffic simultaneously while you monitor the new one.
How does changing a Service selector move traffic instantly?
A Service routes to whichever Pods currently match its selector, tracked live as Endpoints. When you patch the selector from version: blue to version: green, Kubernetes recomputes the Endpoints immediately, so new connections go to green Pods with no rescheduling and no restart. That’s why blue/green cutover and rollback are effectively instant.
Why is my canary receiving no traffic even though its Pod is running?
Almost always a readiness problem. A Pod that isn’t Ready is removed from the Service’s Endpoints, so a canary with a failing or slow readiness probe gets zero traffic despite showing Running. Check kubectl get pods -l app=web for the READY column and verify the readiness probe, then confirm with kubectl get endpoints.
How do I roll back a blue/green deployment quickly?
Patch the Service selector back to the old version: kubectl patch service web -p '{"spec":{"selector":{"version":"blue"}}}'. Because the blue Deployment was never deleted during the release, traffic returns to it the instant the selector changes — no redeploy required. This is the main advantage of keeping both environments alive during the cutover.
Is this deployment-strategies topic actually on the CKAD exam?
Yes. “Use Kubernetes primitives to implement common deployment strategies (e.g. blue/green or canary)” is an explicit item in the Application Deployment domain, roughly 20% of the exam. Expect a task that asks you to stand up a second version and shift traffic to it using Deployments, a Service, and labels — exactly the mechanics covered here.