A re-create strategy replaces a deployed workload directly: Kubernetes deletes every Pod running the old version, then schedules Pods for the new version. Because the versions never run together, the application usually has a period of unavailability, followed by reduced capacity while the first replacement starts. section 4.2.2
Choose re-create when operational simplicity matters more than continuous availability:
- Avoids requiring compatibility between old and new application versions. section 4.2.2
- Uses no additional compute capacity because the new version directly replaces the old one. section 4.2.2
- Fits development and staging environments, or legacy single-instance services that must not run two copies simultaneously. section 4.2.2 section 4.2.4
- Generally avoids production use when downtime is unacceptable; RollingUpdate is the usual zero-downtime alternative, while blue/green offers near-instant cutovers with more tooling and resources. section 4.2.4 section 4.3
Deployment configuration
Set the Deployment strategy to Recreate. Readiness checks can limit how long traffic waits for the first replacement Pod, but they cannot remove the intentional gap between versions. section 4.2.2
