Kubernetes Deployment Strategies: Rolling, Blue-Green & Canary

In this tutorial, you'll learn about Kubernetes Deployment Strategies: Rolling, Blue. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

Kubernetes Deployment strategies control how application updates roll out to production, with rolling updates as the default and blue-green and canary strategies providing advanced traffic management.

What You'll Learn

This tutorial covers rolling updates with maxSurge and maxUnavailable, blue-green deployments using Services, canary releases with weight-based traffic splitting, and A B testing with header-based routing.

Why It Matters

Choosing the wrong deployment strategy causes downtime, slow rollouts, or widespread failures. Blue-green and canary strategies reduce Blast Radius, enabling safe deployments to thousands of pods.

Real-World Use

Lyft uses canary deployments with Envoy-based traffic splitting to release new versions to one percent of users before full rollout. GitHub uses blue-green deployments for zero-downtime database migrations.

Rolling Update Strategy

Rolling update is the default strategy. It replaces pods incrementally without downtime.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
  template:
    spec:
      containers:
      - name: app
        image: myapp:2.0

maxSurge controls how many extra pods can be created above the desired count. maxUnavailable controls how many pods can be down during the update.

# Perform rolling update
kubectl set image deployment/myapp app=myapp:2.0

# Monitor rollout status
kubectl rollout status deployment/myapp

# Rollback if needed
kubectl rollout undo deployment/myapp

Blue-Green Deployment

Blue-green maintains two identical environments. Only one serves live traffic at a time.

apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
    version: blue

Deploy the green version alongside blue, test it, then switch the service selector.

# Deploy blue version
kubectl apply -f deployment-blue.yaml

# Deploy green version
kubectl apply -f deployment-green.yaml

# Switch traffic to green
kubectl patch service myapp -p '{"spec":{"selector":{"version":"green"}}'

# Verify green is healthy
kubectl get pods -l version=green

# Remove blue when confident
kubectl delete -f deployment-blue.yaml

Canary Deployment

Canary releases send a small percentage of traffic to the new version.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-canary
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: app
        image: myapp:2.0

With 10 stable replicas and 2 canary replicas, approximately 17 percent of traffic goes to the new version.

# Deploy canary
kubectl apply -f deployment-canary.yaml

# Scale canary gradually
kubectl scale deployment/myapp-canary --replicas=5

# Promote canary to stable
kubectl set image deployment/myapp-stable app=myapp:2.0

# Remove canary
kubectl delete deployment myapp-canary

Advanced Canary with Service Mesh

Using Istio or Linkerd provides fine-grained traffic splitting.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp
  http:
  - match:
    - headers:
        x-canary:
          exact: "true"
    route:
    - destination:
        host: myapp
        subset: v2
      weight: 100
  - route:
    - destination:
        host: myapp
        subset: v1
      weight: 90
    - destination:
        host: myapp
        subset: v2
      weight: 10

Practice Questions

1. What is the difference between maxSurge and maxUnavailable? maxSurge controls extra pods during update. maxUnavailable controls how many can be unavailable.

2. How does blue-green deployment achieve zero downtime? Both environments run simultaneously. Traffic switches instantly when the new version is ready.

3. What traffic percentage does a canary with 2 out of 12 replicas receive? Approximately 17 percent traffic to the canary replicas.

4. Why use a service mesh for canary deployments? Service mesh provides weight-based and header-based traffic splitting without duplicating services.

5. How do you rollback a rolling update? Use kubectl rollout undo deployment/myapp to revert to the previous revision.