Skip to main content

Kubernetes Update Strategies: RollingUpdate vs Recreate vs Blue-Green

The deployment strategy you choose determines how Kubernetes transitions from the old version of your application to the new one. Each strategy has different tradeoffs in availability, resource usage, rollback speed, and complexity.

✓ RollingUpdate vs Recreate ✓ maxSurge & maxUnavailable tuning ✓ Blue-green & canary ✓ Argo Rollouts
Share this tool: X / Twitter LinkedIn
✓ 60,000+ developers use DevPlaybook ★★★★★ 4.8 / 5 on Gumroad ✓ MIT licensed · Instant download ✓ No login required

Related Products

on Gumroad

You Might Also Need

More Free Tools

Enjoying this tool? Get more like it.

Weekly developer tool guides, productivity playbooks & AI tricks. Free. No spam.

DevPlaybook Pro 7 days free

Unlock AI-Powered Dev Tools

  • ⚡ AI Code Review, Doc Generator & SQL Builder
  • ⚡ All premium templates & early access
  • ⚡ Member discounts on Gumroad products
Start Free Trial →

$9/mo after trial · Cancel anytime

Want the full toolkit?

Get DevPlaybook Pro

Every template, guide, boilerplate, and automation script in one bundle. 13 premium products — grab them all at once and save big.

$79
$241 separately Save $162 (67% off)
Get DevPlaybook Pro — $79 →

MIT licensed · Instant download · No subscription

See what's included → Browse all deals →

Strategy Comparison

Strategy Downtime Extra Resources Rollback Speed Dual Version Complexity
RecreateYesNoneNew deployNoLow
RollingUpdateNo (configurable)maxSurge podskubectl rollout undoBrieflyLow
Blue-GreenNo2x (cutover window)Instant (selector switch)No (one at a time)Medium
CanaryNoCanary pods onlyFast (scale down canary)Yes (controlled %)Medium-High

RollingUpdate: maxSurge and maxUnavailable

spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      # Max pods above desired during rollout
      maxSurge: 2         # Up to 12 pods temporarily

      # Max pods below desired (Unavailable) during rollout
      maxUnavailable: 0   # Never drop below 10 ready pods
Configuration Behavior Use case
maxSurge:1, maxUnavailable:0Zero-downtime, slow (one-at-a-time)Production critical services
maxSurge:0, maxUnavailable:1Resource-conservative, brief capacity lossResource-constrained environments
maxSurge:25%, maxUnavailable:25%Fast rollout, some capacity varianceNon-critical or batch workloads
maxSurge:100%, maxUnavailable:0Blue-green via RollingUpdateFull-capacity validation before cutover

Blue-Green with Kubernetes Services

# Deploy the green (new) version
kubectl apply -f deployment-green.yaml
# deployment-green.yaml has labels: version: green

# Wait for green to be fully ready
kubectl rollout status deployment/myapp-green

# Switch Service from blue to green (instant)
kubectl patch service myapp \
  -p '{"spec":{"selector":{"version":"green"}}}'

# Validate green is serving correctly
# ...smoke tests...

# Roll back instantly if needed:
kubectl patch service myapp \
  -p '{"spec":{"selector":{"version":"blue"}}}'

# Once validated, scale down or delete blue
kubectl scale deployment myapp-blue --replicas=0

Canary Deployments

Without a service mesh, approximate canary by replica ratio. 1 canary pod out of 10 total = 10% canary traffic (assuming equal-weight routing).

# Both deployments share the same Service selector label: app=myapp
# Service routes to both via label matching

# Stable: 9 replicas
apiVersion: apps/v1
kind: Deployment
metadata: {name: myapp-stable}
spec:
  replicas: 9
  selector:
    matchLabels: {app: myapp, version: stable}

---
# Canary: 1 replica = ~10% traffic
apiVersion: apps/v1
kind: Deployment
metadata: {name: myapp-canary}
spec:
  replicas: 1
  selector:
    matchLabels: {app: myapp, version: canary}

---
# Service selects on 'app: myapp' — matches BOTH deployments
kind: Service
spec:
  selector:
    app: myapp   # Routes to both stable and canary pods

Advanced: Argo Rollouts

Argo Rollouts replaces the standard Deployment controller with a custom resource that supports precise traffic splitting, automated analysis, and progressive delivery.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 5      # 5% traffic to canary
      - pause: {duration: 5m}  # Wait 5 minutes
      - analysis:         # Run automated analysis
          templates:
          - templateName: success-rate
      - setWeight: 50     # Increase to 50%
      - pause: {}         # Manual approval gate
      - setWeight: 100    # Full promotion