Recreate — destructive but simple when downtime is acceptable

Recreate is the simplest Deployment strategy and the easiest to misuse. It deletes every old Pod before creating the new ones. The Deployment is offline for the duration of the rollout. That property — provable, deliberate downtime — is both its only advantage and its only danger.

How Recreate works

apiVersion: apps/v1
kind: Deployment
metadata:
  name: db-migrator
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: db-migrator
  template:
    metadata:
      labels:
        app: db-migrator
    spec:
      containers:
      - name: migrator
        image: migrator:v2

When the Pod template changes:

flowchart LR
    A["Old RS: 1/1 ready"] -->|step 1| B["Old RS: 0/0 terminating"]
    B -->|wait SIGKILL| C["Old RS: 0/0 gone"]
    C -->|step 2| D["New RS: 0/1 pending"]
    D -->|wait ready| E["New RS: 1/1 ready"]

1. The old ReplicaSet is scaled to 0 replicas. Every old Pod receives SIGTERM, waits its termination grace period, and is then killed.
2. Once all old Pods are gone, the new ReplicaSet is scaled to replicas and the new Pods are created.
3. The new Pods come up, pass readiness, and the rollout completes.

There is no overlap. At step 1→2, the Deployment has zero Pods serving traffic.

When Recreate is the right choice

Recreate is correct only when running two versions concurrently is impossible or unsafe:

• Schema-breaking database migrations. If v1 writes a schema v2 cannot read, the new Pod must not start until the old Pod has stopped writing. With RollingUpdate, the old Pod might still be draining in-flight writes while the new Pod is starting and reading — corrupting the database. The pattern: a separate Job performs the migration against the database; the Deployment then performs a Recreate rollout of the application.
• Single-replica batch workloads. A nightly job that owns a lock file or a local cache that two instances would corrupt. There is no second replica anyway.
• Native-sidecar rebuilds that change the initContainers list. Some sidecar-projection changes (e.g., swapping an Istio proxy version) require a Pod restart and there is no rolling semantics that produces a clean result.
• Local-storage workloads. Where each Pod needs a different local disk, the new Pod cannot share with the old and the old must be gone first.

In every other case, Recreate is wrong.

When Recreate is dangerous

The most common production mistake: an operator sets strategy.type: Recreate on a Deployment with replicas: N serving user-facing traffic. The first rollout causes a hard outage of every replica simultaneously. If the rollout fails mid-way (bad image, wrong ConfigMap, readiness timeout), the Deployment has zero Pods ready and the service stays down until the operator intervenes.

# WRONG — never do this on a multi-replica serving workload
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 6
  strategy:
    type: Recreate
  ...

PodDisruptionBudget interaction

PodDisruptionBudget is irrelevant to Recreate. PDBs apply to voluntary disruptions — drain, delete, eviction. The Deployment controller’s scale-to-zero-then-scale-up is a rollout and PDBs do not block it. The PDB only protects against kubectl drain and similar operator actions.

If the operator runs kubectl drain against a node hosting a single-replica Recreate Deployment, the PDB will block the drain until the deadline expires, then the Pod is evicted. The Deployment sees the eviction and creates a new Pod; the rollout itself is unaffected.

Termination behaviour

The duration of the “downtime” gap in a Recreate rollout is:

gap = max(old_pod_termination_grace_period,
         new_pod_startup_to_ready) + API roundtrip

• terminationGracePeriodSeconds (default 30) controls how long old Pods have to drain in-flight requests.
• preStop hooks can extend the gap deliberately (sleep for load balancer drain).
• The new Pod’s startupProbe or readinessProbe controls how long until the new Pod is considered Ready. Until then the Service has no Endpoints.

A common production pattern is to set a preStop that runs longer than the upstream load balancer’s drain interval:

spec:
  terminationGracePeriodSeconds: 60
  containers:
  - name: web
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep 15"]

This ensures the kube-proxy / CNI / external load balancer have time to remove the Pod from the routing table before the Pod stops accepting connections.

Inspecting a Recreate rollout

kubectl get pods -l app=db-migrator -n data -w
# NAME                  READY   STATUS        RESTARTS   AGE
# db-migrator-old-1     1/1     Running       0          5m
# db-migrator-old-1     1/1     Terminating   0          5m
# db-migrator-new-1     0/1     Pending       0          0s
# db-migrator-new-1     0/1     ContainerCreating   0    2s
# db-migrator-new-1     1/1     Running       0          12s

The gap between Terminating and ContainerCreating is the outage window.

$ kubectl describe deployment db-migrator -n data

Name:                   db-migrator
StrategyType:           Recreate
RollingUpdateStrategy:  25% max unavailable, 25% max surge
...

The StrategyType: Recreate line confirms the strategy.

Quiz

Production discipline

• Recreate is opt-in for a reason. The review process should require an explicit justification in the manifest comment and the change ticket.
• Single-replica is the safety floor. A multi-replica Deployment with Recreate is an outage waiting to happen.
• Pair with terminationGracePeriodSeconds set deliberately. The default 30 seconds is rarely the right value; longer is usually safer.
• Pre-flight the rollout in staging with the same image digest. Recreate rollouts are not retryable mid-flight; if the new Pod crashes, the Deployment has zero Pods ready and recovery requires a manual intervention.
• Audit. A scheduled query that lists every Deployment with strategy.type = Recreate AND replicas > 1 is one of the most valuable pre-incident queries in a Kubernetes estate.

Recreate is a sharp tool. Use it when no other strategy works, never because it is easier to write.