Kubernetes Recreate Deployment

The Recreate strategy (also called Fixed Deployment) is the simpler of Kubernetes’ two built-in deployment strategies. It terminates all old Pods before starting new ones, accepting downtime in exchange for simplicity and guaranteed version isolation.

Operational Mechanism

Clean Cutover - When you update a Deployment using Recreate strategy, Kubernetes first scales the old ReplicaSet to zero, terminating all old Pods. Only after all old Pods are fully terminated does it scale up the new ReplicaSet with updated Pods.

No Version Coexistence - Unlike rolling deployment, old and new versions never run simultaneously. This eliminates compatibility concerns between versions but creates a window where no Pods are running.

Service Disruption - During the cutover window, Services have no healthy endpoints. Clients attempting to connect receive connection errors. The duration of this disruption depends on old Pod termination time plus new Pod startup and readiness time.

When to Use Recreate

Incompatible Versions - Applications that cannot tolerate multiple versions running simultaneously are natural candidates. Examples include:

• Database schema migrations requiring exclusive access
• Stateful applications with version-specific data formats
• Applications sharing state that isn’t version-aware
• Legacy applications not designed for rolling updates

Resource Constraints - Rolling deployment requires temporary excess capacity (controlled by maxSurge). In resource-constrained clusters, this overhead may be unavailable. Recreate uses only the resources needed for the target replica count.

Simplified Rollout - Recreate eliminates the complex coordination of gradual transitions. No managing maxSurge, maxUnavailable, or minReadySeconds. The deployment is simpler to understand and troubleshoot.

Development Environments - In development or testing environments where availability isn’t critical, Recreate’s simplicity often outweighs downtime concerns. Deployments are faster and easier to reason about.

Configuration

Recreate strategy requires minimal configuration:

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

The strategy section simply specifies type: Recreate with no additional parameters. This contrasts with RollingUpdate’s multiple control parameters.

Graceful Termination

Even with Recreate’s acceptance of downtime, proper shutdown remains important:

SIGTERM Handling - Kubernetes sends SIGTERM to old Pods before forcefully killing them. Applications should handle this signal to:

• Complete in-flight requests
• Flush buffers and caches
• Close database connections cleanly
• Update distributed state (session stores, coordination services)

Termination Grace Period - After SIGTERM, Kubernetes waits (default 30 seconds, configurable via terminationGracePeriodSeconds) before sending SIGKILL. Improper shutdown can corrupt data even when downtime is acceptable.

State Persistence - Recreate’s downtime window doesn’t eliminate the need for persistent volumes. Application state must survive Pod termination, whether using PersistentVolumeClaims or external storage services.

Trade-offs

Downtime Acceptance - The fundamental trade-off is availability. Production services with SLA requirements typically can’t accept the downtime window. However, this may be acceptable for:

• Planned maintenance windows
• Internal tools with limited usage
• Applications with external failover mechanisms
• Services behind retry logic with long timeouts

Simplicity Gain - Recreate eliminates several complexity dimensions:

• No version compatibility requirements
• No excess capacity needed
• No gradual rollout coordination
• Simpler troubleshooting (only one version at a time)

Faster Deployment - Without waiting for gradual transitions, Recreate deployments complete faster. Terminating all Pods in parallel and starting all new Pods in parallel (subject to resource availability) is faster than incremental replacement.

Rollback Simplicity - If new Pods fail to start or fail health checks, the failure is immediately obvious (service completely down). With rolling deployment, partial failures can be subtler. Rollback using kubectl rollout undo works identically but affects all replicas simultaneously.

Alternatives for Zero-Downtime

When version incompatibility seems to require Recreate but downtime is unacceptable, consider:

Blue-Green Deployment - Blue-green deployment maintains two complete environments. Traffic switches instantly between them via Service selector changes, providing instant cutover without version coexistence.

Database Migration Patterns - For database schema incompatibilities, use multi-phase migrations:

1. Deploy backward-compatible schema changes
2. Use rolling deployment for application update
3. Remove deprecated schema elements in subsequent release

Feature Flags - Deploy code for both old and new behaviors, controlled by runtime flags. Switch behavior without redeployment, then clean up old code paths in future releases.

Separate Deployments - For stateful incompatibilities, consider splitting into separate Deployments or even separate namespaces, coordinating cutover at the Service level.

Health Checks

While Recreate accepts downtime during deployment, health checks still matter:

Readiness Probes - New Pods must pass readiness checks before the Deployment is considered complete. Poor readiness probes can extend downtime (too strict) or allow broken deployments (too permissive).

Liveness Probes - Detect failed new Pods that need restart. If all new Pods fail liveness checks, you have a complete outage rather than just deployment downtime.

Startup Time Impact - Total downtime equals old Pod termination time plus new Pod startup plus readiness check time. Applications with slow startup (large JVM heap initialization, data loading) extend the downtime window significantly.