Recreate deployment — the downtime cost and the cases that justify it

Recreate is the simplest deployment pattern and the only one that produces guaranteed downtime. The old version is stopped; the new version is started; during the gap, no version serves traffic. For workloads where downtime is unacceptable, recreate is wrong. For workloads where downtime is acceptable, or where the alternative patterns are unsafe, recreate is the right choice.

How recreate works

flowchart LR
    A["Old v1 running"] --> B["Stop v1"]
    B --> C["No traffic served"]
    C --> D["Start v2"]
    D --> E["New v2 running"]

The pattern has one decisive property: at no point do old and new versions coexist. The switch is total. The cost is the window between old stopped and new ready, during which the service is unavailable.

The downtime window is the sum of three components:

• Stop time. How long the old version takes to drain in-flight requests and shut down gracefully. A preStop hook with a sleep adds to this; an aggressive termination grace period shortens it.
• Image pull time. How long the new image takes to download on the node. A small image, a warm pull-through cache, or a node that already has the image compressed into a minute.
• Start time. How long the new version takes to initialise and become ready. A startup probe with a long initialDelay lengthens this; a fast-starting service shortens it.

For a typical containerised service, the window is seconds to tens of seconds. For a stateful service with a slow initialisation (database warm-up, cache priming), the window is minutes. The pattern is right only when the team has measured the window and accepted the user impact.

When recreate is acceptable

Recreate fits workloads where:

• The environment is non-production. Development, staging, and ephemeral preview environments do not have paying customers; downtime is invisible.
• The workload is single-instance and cannot run two versions. A database migration job, a leader-elected service, a legacy application with file-based locking.
• The change is fundamentally incompatible. A new runtime that replaces the binary, a major version upgrade that changes the on-disk format, a breaking schema migration that cannot be made backward-compatible.
• The downtime is planned and communicated. A maintenance window for a known-incompatible upgrade, with users notified in advance.

Recreate is wrong for production user-facing services where the downtime window is observable to paying users and the pattern is chosen for convenience rather than necessity.

Minimising the recreate window

When recreate is unavoidable, three tactics shorten the window:

• Pre-pull the new image. A DaemonSet or init container that downloads the new image before the recreate begins so the image pull is not in the critical path.
• Tune termination grace and preStop. A short terminationGracePeriodSeconds cuts the stop time, but too short loses in-flight requests. A preStop hook that drains the load balancer before SIGTERM prevents new traffic from arriving during the shutdown.
• Warm-start the new version. A readiness probe that reports ready before the service is fully initialised is a lie that returns 5xx; a startup probe that holds the readiness signal until initialisation completes is the truthful alternative.

These tactics do not eliminate the window; they compress it. The compressed window must still be measured and accepted.

kubectl rollout status deployment/$NAME
kubectl rollout undo deployment/$NAME

The same commands work for recreate as for rolling update. The status command blocks until the new version is ready (or fails); the undo command reverses the rollout if the new version never becomes ready.

When recreate is wrong

Recreate is the wrong pattern when:

• The workload serves paying users in production. The window is observed downtime.
• A rolling update or canary is feasible. If the change is backward-compatible, the rolling update avoids the window; if the change is high-risk, canary reduces the blast radius without the window.
• The downtime window is unmeasured. A recreate window that the team cannot estimate is a recreate window that surprises the team.

Production discipline

1. Default to rolling update or canary. Recreate is the exception, not the default.
2. Measure the recreate window. Stop time, image pull, start time - each must be known.
3. Communicate the window to stakeholders. Recreate in production requires a maintenance window or a documented user-impact agreement.
4. Compress the window with pre-pull, tuned termination, and warm-start tactics. A 30-second window is better than a 5-minute one.

Cross-course references

• Kubernetes for Production Sysadmins - Part XIV (Workloads) covers the Deployment strategy field that selects between RollingUpdate and Recreate.
• This course, Part LVIII-01 (The deployment pattern taxonomy) establishes where recreate sits in the trade-off space.
• Linux for Production Sysadmins - Part XXII (ChangeMgmt) covers the maintenance-window discipline that historically authorised recreate-style deploys.

Quiz