Deployment Strategies: Blue-Green, Canary, Rolling Updates

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Max 1 extra pod during update (25% of 4)
      maxUnavailable: 1   # Max 1 pod can be unavailable (25% of 4)

  selector:
    matchLabels:
      app: myapp

  template:
    metadata:
      labels:
        app: myapp
        version: v2.0  # Updated version
    spec:
      containers:
      - name: myapp
        image: myapp:v2.0  # New image version
        ports:
        - containerPort: 8080

        # Critical: Health checks ensure new pods are ready
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5

        livenessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 10

# Blue deployment (current version v1.0)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-blue
spec:
  replicas: 4
  selector:
    matchLabels:
      app: myapp
      version: v1.0
  template:
    metadata:
      labels:
        app: myapp
        version: v1.0
    spec:
      containers:
      - name: myapp
        image: myapp:v1.0

---
# Green deployment (new version v2.0)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-green
spec:
  replicas: 4
  selector:
    matchLabels:
      app: myapp
      version: v2.0
  template:
    metadata:
      labels:
        app: myapp
        version: v2.0
    spec:
      containers:
      - name: myapp
        image: myapp:v2.0

---
# Service - controls which version receives traffic
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
    version: v2.0  # Change this to switch versions
                   # v1.0 = blue, v2.0 = green
  ports:
  - port: 80
    targetPort: 8080

# Currently on blue (v1.0)
kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"v2.0"}}}'
# Now on green (v2.0) - instant switch!

# Rollback to blue if needed
kubectl patch service myapp-service -p '{"spec":{"selector":{"version":"v1.0"}}}'
# Back to blue (v1.0) - instant rollback!

# Stable version (v1.0)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-stable
spec:
  replicas: 9  # 90% of traffic
  selector:
    matchLabels:
      app: myapp
      track: stable
  template:
    metadata:
      labels:
        app: myapp
        track: stable
        version: v1.0
    spec:
      containers:
      - name: myapp
        image: myapp:v1.0

---
# Canary version (v2.0)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-canary
spec:
  replicas: 1  # 10% of traffic
  selector:
    matchLabels:
      app: myapp
      track: canary
  template:
    metadata:
      labels:
        app: myapp
        track: canary
        version: v2.0
    spec:
      containers:
      - name: myapp
        image: myapp:v2.0

---
# Service selects both stable and canary
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp  # Matches both stable and canary
  ports:
  - port: 80
    targetPort: 8080

# Start: 10% canary
kubectl scale deployment myapp-stable --replicas=9
kubectl scale deployment myapp-canary --replicas=1

# Increase to 30% canary
kubectl scale deployment myapp-stable --replicas=7
kubectl scale deployment myapp-canary --replicas=3

# Increase to 50% canary
kubectl scale deployment myapp-stable --replicas=5
kubectl scale deployment myapp-canary --replicas=5

# Complete rollout: 100% canary
kubectl scale deployment myapp-stable --replicas=0
kubectl scale deployment myapp-canary --replicas=10

✅ Use When:
- Standard application updates
- Limited infrastructure budget
- Changes are low-risk
- Quick deployments needed
- Kubernetes native support desired

❌ Avoid When:
- Zero tolerance for partial rollouts
- Need instant rollback capability
- Database schema changes incompatible with old version

✅ Use When:
- Deploying to production databases
- Regulatory compliance requirements
- Need full environment testing
- Instant rollback is critical
- Can afford 2x infrastructure

❌ Avoid When:
- Resource constrained
- Stateful applications (hard to maintain two)
- Database migrations are complex

✅ Use When:
- Major version upgrades
- Architecture changes
- Uncertain about performance impact
- Good monitoring infrastructure exists
- Can analyze real user metrics

❌ Avoid When:
- No good metrics to validate
- Can't split traffic easily
- Changes must be all-or-nothing
- Rapid rollout needed

# Essential for any deployment strategy
readinessProbe:
  httpGet:
    path: /health/ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 3
  successThreshold: 1

livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 3

Deployment N-1:    Deployment N:      Deployment N+1:
Schema v1          Schema v1 + v2     Schema v2
Code reads v1      Code reads v1/v2   Code reads v2
                   Code writes v2     Code writes v2