What is a Recreate Deployment Strategy?
Learn how the Recreate deployment strategy works, why it causes downtime, and when it is the right tradeoff versus rolling or blue-green deploys.
Expected Interview Answer
A recreate deployment strategy fully stops all running instances of the old application version before starting any instances of the new version, meaning there is a deliberate window of downtime between the two.
Unlike rolling updates or blue-green deployments, recreate makes no attempt to keep the application available during the switch: every old Pod or instance is terminated first, and only then does the new version begin starting up. This is the simplest possible deployment strategy to reason about because there is never a moment where old and new versions run side by side, which matters for applications that cannot tolerate two schema-incompatible versions accessing the same database simultaneously. The tradeoff is unavoidable downtime lasting from shutdown of the old version until the new version passes its readiness checks, so it is generally reserved for internal tools, batch systems, or environments like staging and development where availability during deploys is not a business requirement. In Kubernetes, this is configured by setting the Deployment’s strategy type to Recreate instead of the default RollingUpdate.
- Simplest strategy to reason about — no mixed-version period
- Avoids running two schema-incompatible versions concurrently
- Requires no extra infrastructure like traffic splitting or a second environment
- Predictable, easy-to-debug deployment behavior
AI Mentor Explanation
A recreate deployment is like a ground fully closing the stadium, removing the entire old pitch surface, and only then laying and preparing the brand-new pitch before play resumes. There is no period where part of the old pitch and part of the new pitch are both in use — the ground is simply unusable until the new surface is ready. This is done when the old and new pitch materials genuinely cannot coexist, such as a full re-turfing. Spectators simply cannot watch cricket at that ground until the whole job is finished.
Step-by-Step Explanation
Step 1
Stop the old version
Terminate every running instance or Pod of the currently deployed version.
Step 2
Confirm full teardown
Wait until zero old-version instances remain serving traffic.
Step 3
Start the new version
Launch instances of the new version from a fresh artifact/image.
Step 4
Wait for readiness
Traffic resumes only once the new instances pass health/readiness checks, ending the downtime window.
What Interviewer Expects
- Understanding that recreate always involves a downtime window
- Knowledge of when it is an acceptable tradeoff (internal tools, incompatible schemas)
- Awareness of how it differs from rolling update and blue-green
- Ability to name the Kubernetes Deployment strategy field
Common Mistakes
- Assuming recreate is zero-downtime like a rolling update
- Using recreate for a customer-facing production service without justification
- Not knowing it is a valid Kubernetes Deployment strategy option
- Confusing recreate with blue-green (recreate has no second environment)
Best Answer (HR Friendly)
“Recreate deployment means we fully shut down the old version before starting the new one, so there is a short window where the service is down. We only use it where a bit of downtime is acceptable, like internal tools or when the old and new versions genuinely cannot run at the same time, for example due to an incompatible database schema.”
Code Example
apiVersion: apps/v1
kind: Deployment
metadata:
name: internal-tool
spec:
replicas: 3
strategy:
type: Recreate
selector:
matchLabels:
app: internal-tool
template:
metadata:
labels:
app: internal-tool
spec:
containers:
- name: internal-tool
image: internal-tool:2.0Follow-up Questions
- When would you deliberately choose Recreate over RollingUpdate?
- How does Recreate avoid schema-compatibility issues during a deploy?
- What is the downtime tradeoff compared to blue-green deployment?
- How would you communicate a Recreate deployment window to stakeholders?
MCQ Practice
1. What is the defining characteristic of a Recreate deployment strategy?
Recreate fully terminates the old version first, creating a downtime window before the new version starts.
2. When is a Recreate strategy an acceptable choice?
Recreate suits cases where mixed old/new versions would cause conflicts, since it guarantees no overlap, at the cost of downtime.
3. In a Kubernetes Deployment manifest, which field selects the Recreate strategy?
Setting spec.strategy.type to Recreate tells Kubernetes to terminate all old Pods before creating new ones.
Flash Cards
What is a Recreate deployment? — Stopping all old instances before starting any new ones, causing planned downtime.
Main tradeoff of Recreate? — Simplicity and no version overlap, at the cost of a downtime window.
When is Recreate appropriate? — Internal tools or when old/new versions cannot coexist, e.g. incompatible DB schemas.
Kubernetes field for Recreate? — spec.strategy.type: Recreate on a Deployment.