CKAD — Blue-Green & Canary Deployments

2 minute read

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 →

Updated: