Recreate Deployment

Terminate all old pods then start new pods. Simple but causes brief downtime.

Recreate deployment terminates all existing pods before creating new ones. It is the simplest strategy but causes brief downtime. It is the right choice when two versions of your application absolutely cannot coexist.

How It Works

When you set strategy.type: Recreate, Kubernetes scales the old ReplicaSet to 0, waits for all pods to terminate, then creates the new ReplicaSet. There is a gap where no pods are running. The duration depends on termination grace period + new pod startup time.

WarningRecreate causes downtime. Only use it when running two versions simultaneously would cause worse problems than brief unavailability (e.g., exclusive hardware access, database lock contention, or incompatible schema changes).

When to Use

GPU workloads requiring exclusive device access
Legacy monoliths that cannot run in mixed-version state
Database schema migrations that break old version
Embedded/IoT edge deployments with limited resources

When NOT to Use

Customer-facing services with SLA requirements
Any service where downtime is unacceptable
Frequent deployments (each one causes an outage)

Real-World Examples

Siemens - IoT Edge Gateways

Siemens IoT edge gateways require exclusive access to serial port hardware. Running two versions simultaneously would cause device contention. Recreate strategy during scheduled maintenance windows ensures clean hardware handoff.

Riot Games - Match History Service

Riot Games deploys match history database schema updates during off-peak hours (3-4 AM). The Recreate strategy ensures no pod tries to read a half-migrated schema. Planned 60-second downtime is communicated via status page.

Step-by-Step Implementation

1. Set Recreate strategy

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: edge-gateway
spec:
  replicas: 3
  strategy:
    type: Recreate    # No rolling - kill all, then create all
  selector:
    matchLabels:
      app: edge-gateway
  template:
    metadata:
      labels:
        app: edge-gateway
    spec:
      terminationGracePeriodSeconds: 30
      containers:
      - name: gateway
        image: myregistry/gateway:2.0.0
        resources:
          limits:
            nvidia.com/gpu: 1
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 10

2. Apply during maintenance window

bash

# Announce downtime
echo "Starting maintenance window..."

# Apply - all old pods terminate, then new ones start
kubectl apply -f deployment.yaml

# Watch the gap
kubectl get pods -l app=edge-gateway -w

Common Pitfalls

Pitfall	Symptom	Fix
CrashLoopBackOff on new version	All pods are down with no way to serve traffic	Test thoroughly in staging; have rollback plan ready before deploying
Long termination grace period	Downtime window longer than expected	Tune terminationGracePeriodSeconds; implement graceful shutdown
No health checks on new pods	Service appears up but is not ready	Always set readinessProbe; use startupProbe for slow apps
Deploying during peak hours	User impact from unplanned downtime	Schedule Recreate deployments during maintenance windows