Rolling Update vs Recreate — Kubernetes Deployment Strategies Explained

Rolling update keeps your app running during deploys. Recreate kills everything then starts fresh. Here's when to use each, plus Blue-Green and Canary explained simply.

Every time you update a Kubernetes Deployment, pods get replaced. How that replacement happens depends on your deployment strategy. Get this wrong and you get downtime. Get it right and your users never notice a deploy.

The Two Built-In Strategies

Rolling Update (Default)

Kubernetes replaces pods gradually, old and new pods coexist temporarily.

Before: [v1] [v1] [v1]

During: [v2] [v1] [v1]   ← 1 new, 2 old
        [v2] [v2] [v1]   ← 2 new, 1 old
        [v2] [v2] [v2]   ← all new

After:  [v2] [v2] [v2]

Users never lose service — traffic is always routing to running pods.

Configuration:

yaml

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1    # Max pods that can be unavailable during update
      maxSurge: 1          # Max extra pods that can be created

maxUnavailable: 1 — Never have more than 1 pod down at a time
maxSurge: 1 — Can temporarily have 4 pods (3 + 1 extra during rollout)
Both can be percentages: maxUnavailable: 25%

How the rollout happens:

Create 1 new v2 pod (now 4 total: 3 old + 1 new)
Wait for new pod to pass readiness probe
Terminate 1 old v1 pod (back to 3)
Repeat until all pods are v2

bash

# Watch rollout in real-time
kubectl rollout status deployment/my-app
 
# See rollout history
kubectl rollout history deployment/my-app
 
# Rollback if something goes wrong
kubectl rollout undo deployment/my-app
 
# Rollback to specific version
kubectl rollout undo deployment/my-app --to-revision=2

Recreate

Kills ALL old pods, then creates ALL new pods.

Before: [v1] [v1] [v1]

During: [  ] [  ] [  ]   ← DOWNTIME: all pods terminated
        [v2] [v2] [v2]   ← all new pods starting

After:  [v2] [v2] [v2]

Configuration:

yaml

spec:
  strategy:
    type: Recreate
    # No rollingUpdate section needed

When to use Recreate:

Your app can't run two versions at the same time (DB schema changes, singleton locks)
Development/staging where brief downtime is acceptable
Stateful apps with shared storage that only allows one writer
When you WANT to ensure old version is completely gone first

When NOT to use Recreate:

Production services with uptime requirements
Any user-facing service

The Critical Role of Readiness Probes

Rolling update is only zero-downtime if your readiness probe is set correctly. Without it, Kubernetes sends traffic to pods before they're ready.

yaml

containers:
  - name: my-app
    image: my-app:v2
    readinessProbe:
      httpGet:
        path: /health/ready    # Must return 200 before traffic is sent
        port: 8080
      initialDelaySeconds: 10   # Wait 10s before first check
      periodSeconds: 5          # Check every 5 seconds
      failureThreshold: 3       # Fail 3 times before marking unhealthy

The rolling update process waits for the readiness probe to pass before proceeding to the next pod. If your probe is wrong, you get half-broken states.

Blue-Green Deployment (Outside Kubernetes Native)

Blue-Green isn't a Kubernetes deployment strategy — it's a pattern you implement using Services.

Blue (current):   [v1] [v1] [v1]  ← Service points here
Green (new):      [v2] [v2] [v2]  ← Running but no traffic

Switch:           Update Service selector to point to Green
                  Service now routes to Green
                  Blue is idle (instant rollback available)

Implementation:

yaml

# Blue Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: blue
  template:
    metadata:
      labels:
        app: my-app
        version: blue
    spec:
      containers:
        - name: my-app
          image: my-app:v1
 
---
# Green Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: green
  template:
    metadata:
      labels:
        app: my-app
        version: green
    spec:
      containers:
        - name: my-app
          image: my-app:v2
 
---
# Service — switch between blue and green
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
    version: blue   # Change to 'green' to switch

bash

# Switch traffic to green (near-instant)
kubectl patch svc my-app -p '{"spec":{"selector":{"version":"green"}}}'
 
# Instant rollback
kubectl patch svc my-app -p '{"spec":{"selector":{"version":"blue"}}}'

When to use Blue-Green:

Zero-downtime deploys with instant rollback
When you want to test new version before switching traffic
Database migration with parallel schema support

Downside: Doubles resource usage during deployment.

Canary Deployment (Gradual Traffic Shift)

Send a small percentage of traffic to new version first.

90% → [v1] [v1] [v1]
10% → [v2]           ← canary

Simple version using replica ratio:

yaml

# Main deployment: 9 replicas (v1)
# Canary deployment: 1 replica (v2)
# Service selects both → ~10% to canary

Production-grade: use Argo Rollouts or Flagger for proper canary with traffic weighting and automated promotion based on error rate.

Strategy Decision Guide

Scenario	Strategy
Standard web app	Rolling Update
Singleton / shared DB writes	Recreate
Need instant rollback	Blue-Green
Risk mitigation for big features	Canary
Dev/staging	Recreate (simpler)
Database migrations	Blue-Green + separate migration job

Setting Good Rolling Update Defaults

For most production deployments:

yaml

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0   # Never reduce capacity (requires maxSurge > 0)
    maxSurge: 1         # Add 1 extra pod during rollout
 
# Combined with readiness probe → zero-downtime guaranteed

maxUnavailable: 0 + maxSurge: 1 means you always have full capacity. Costs slightly more during rollout but guarantees no capacity reduction.

For CKA prep and Kubernetes deployment strategies hands-on labs, KodeKloud walks through rolling updates, rollbacks, and Argo Rollouts canary deployments.

Rolling Update vs Recreate — Kubernetes Deployment Strategies Explained

The Two Built-In Strategies

Rolling Update (Default)

Recreate

The Critical Role of Readiness Probes

Blue-Green Deployment (Outside Kubernetes Native)

Canary Deployment (Gradual Traffic Shift)

Strategy Decision Guide

Setting Good Rolling Update Defaults

Stay ahead of the curve

Related Articles

Jenkins vs Tekton — Which CI Tool Should You Use for Kubernetes in 2026?

What is Blue-Green Deployment? Explained Simply for Beginners (2026)

What is GitOps? Explained Simply for Beginners (2026)

Comments