CKAD — Blue-Green & Canary Deployments
Advanced Deployment Patterns
Kubernetes does not have built-in blue-green or canary support, but you can implement them using labels and Services. Understanding these patterns helps for both the CKAD exam and real-world production deployments.
Blue-Green Deployments
In a blue-green deployment, you run two identical environments — one serving live traffic (blue), one with the new version (green). You switch traffic instantly by changing the Service selector.
How It Works
┌─────────────┐
│ Service │
│ selector: │
│ version: │
┌────────│ blue ←─────│─── Switch to "green"
│ └─────────────┘
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Blue (v1) │ │ Green (v2) │
│ 3 replicas │ │ 3 replicas │
│ nginx:1.26 │ │ nginx:1.27 │
└─────────────┘ └─────────────┘
Implementation
# Blue Deployment (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: nginx
image: nginx:1.26
---
# Green Deployment (new version)
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: nginx
image: nginx:1.27
---
# Service points to blue
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web
version: blue # ← Switch to "green" to cut over
ports:
- port: 80
# Switch traffic from blue to green
kubectl patch svc web -p '{"spec":{"selector":{"version":"green"}}}'
# Roll back by switching back to blue
kubectl patch svc web -p '{"spec":{"selector":{"version":"blue"}}}'
Blue-Green Pros and Cons
| Pros | Cons |
|---|---|
| Instant switchover | Requires 2x resources |
| Easy rollback (just switch selector) | Both versions must be running simultaneously |
| No mixed traffic during transition | More complex to set up |
Simple Canary with Replicas
A canary deployment sends a small percentage of traffic to the new version while the majority goes to the old version. If the new version works, you gradually increase its traffic.
Implementation
# Main Deployment: 9 replicas of v1
kubectl create deployment web-stable --image=nginx:1.26 --replicas=9
# Canary Deployment: 1 replica of v2 (same "app" label)
kubectl create deployment web-canary --image=nginx:1.27 --replicas=1
Both Deployments need the same app label so the Service routes to both:
# Service selects by "app" label (matches both Deployments)
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web # Matches Pods from both web-stable and web-canary
ports:
- port: 80
Since the Service routes equally to all matching Pods:
- 9 out of 10 requests → stable (v1)
- 1 out of 10 requests → canary (v2)
- ~10% canary traffic
Scaling the Canary
# Increase canary traffic to ~30%
kubectl scale deployment web-stable --replicas=7
kubectl scale deployment web-canary --replicas=3
# Full promotion — all traffic to v2
kubectl scale deployment web-stable --replicas=0
kubectl scale deployment web-canary --replicas=10
# Or roll back — remove canary
kubectl delete deployment web-canary
kubectl scale deployment web-stable --replicas=10
Pattern Comparison
| Pattern | Traffic Switch | Resource Cost | Rollback Speed | Complexity |
|---|---|---|---|---|
| Rolling Update | Gradual (built-in) | Normal | Fast (rollout undo) |
Low |
| Blue-Green | Instant | 2x during transition | Instant | Medium |
| Canary | Percentage-based | Slightly more | Fast (delete canary) | Medium |
Exam tip: The CKAD exam typically tests rolling updates and rollbacks (built-in). Blue-green and canary are tested conceptually — know how to implement them with labels and Services.
Next: Put it all together with Deployments Lab →