Deployment Strategies

Strategy comparison

Blue/Green and Canary are not built-in: patterns implemented using multiple Deployments and Service label selectors.

RollingUpdate (default)

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 40%
      maxSurge: 10%
  minReadySeconds: 60       # must stay Ready this long before proceeding

• Service routes to both old and new Pods during rollout
• Breaking API changes risky: keep backward compatible

Recreate

spec:
  strategy:
    type: Recreate

• All old Pods terminated before new ones start: downtime

Blue/Green: switch via Service selector

# Blue Deployment (current)
metadata:
  name: webapp-blue
  labels: {app: webapp, version: blue}
spec:
  template:
    metadata:
      labels: {app: webapp, version: blue}

# Green Deployment (new version)
metadata:
  name: webapp-green
  labels: {app: webapp, version: green}
spec:
  template:
    metadata:
      labels: {app: webapp, version: green}

# Service initially points to blue:
spec:
  selector:
    app: webapp
    version: blue   # change to green to switch all traffic instantly

kubectl patch svc webapp --type=merge -p '{"spec":{"selector":{"version":"green"}}}'

• Rollback = flip selector back

Canary: split traffic by replica ratio

# Stable deployment: 9 replicas
metadata:
  name: webapp-stable
  labels: {app: webapp, track: stable}

# Canary deployment: 1 replica (10% traffic)
metadata:
  name: webapp-canary
  labels: {app: webapp, track: canary}
spec:
  replicas: 1          # 1 out of 10 total = 10% traffic
  template:
    metadata:
      labels:
        app: webapp    # SAME label as stable: Service routes to both
        track: canary

# Service selects BOTH:
spec:
  selector:
    app: webapp        # matches both stable and canary pods

Exam gotchas

• Canary: second Deployment with same app label, different image; Service selector on app only → routes to both; ratio = replica counts
• Canary needs shared label on both Deployments for same Service