Kubernetes Deployment Recreate Strategy Management

Kubernetes Deployment Recreate Strategy Management is the practice of correctly identifying when the Recreate update strategy is the appropriate choice and operating a Deployment safely under it, given that it deliberately trades continuous availability for strict version isolation, terminating every old Pod before any new one is created.

Identifying the Right Use Case

Incompatible Concurrent Versions

Recreate is appropriate specifically when running two versions of an application simultaneously would cause active harm, not merely inconvenience, such as a schema migration that old and new code cannot both operate against safely, or a singleton process that must never have two live instances.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: recreate-strategy-example
spec:
  strategy:
    type: Recreate
  template:
    spec:
      containers:
        - name: app
          image: registry.example.com/singleton-app:2.0.0

Distinguishing From RollingUpdate's maxUnavailable

Recreate is not simply RollingUpdate with maxUnavailable set very high; it guarantees zero overlap between old and new Pod versions at any point, a stronger guarantee than any RollingUpdate configuration can express, since even a brief overlap during a rolling transition is unacceptable for the workloads Recreate is meant for.

Planning for the Downtime Window

Expected, Not Accidental, Unavailability

Because Recreate guarantees a full outage of the Deployment's Pods between the last old Pod terminating and the first new Pod becoming ready, management practice treats this window as a planned, expected event, scheduled during low-traffic periods and communicated in advance, rather than something to be minimized through configuration tuning, since the strategy offers no tuning knobs to reduce it.

kubectl rollout status deployment/recreate-strategy-example --timeout=5m

Coordinating With Dependent Systems

Upstream Awareness During the Gap

Any Service or ingress in front of a Recreate-strategy Deployment will have zero available endpoints during the transition window; management practice includes ensuring upstream systems, load balancers, client retry logic, are configured to handle this gap gracefully rather than surfacing hard failures to end users.

apiVersion: v1
kind: Service
metadata:
  name: recreate-strategy-service
spec:
  selector:
    app: singleton-app

Verifying the Migration or Precondition Completed

Sequencing With Init Containers

For the common case of a schema migration motivating the Recreate choice, pairing the strategy with an init container in the new Pod template that verifies migration completion before the application container starts adds an additional safety layer, ensuring the new version never runs against a database still in an intermediate migration state.

spec:
  template:
    spec:
      initContainers:
        - name: verify-migration
          image: registry.example.com/migration-check:1.0.0

Rollback Considerations Unique to Recreate

Rollback Also Incurs Downtime

Because Recreate is symmetric, a rollback to a previous revision goes through the same full-teardown-then-recreate sequence, meaning reverting a bad Recreate rollout is not a fast, low-impact operation the way a RollingUpdate rollback typically is; this should factor into how quickly a go/no-go decision is made during the change window.

kubectl rollout undo deployment/recreate-strategy-example

Recreate Strategy Diagram

Managing a Deployment under Recreate well is less about configuration and more about organizational discipline, deliberately scheduling and communicating a known, unavoidable gap in availability in exchange for the strict version isolation the workload genuinely requires.