Kubernetes Recreate Deployment Strategy
The Recreate deployment strategy is the simplest approach Kubernetes offers: it terminates all existing Pods before creating new ones. During the switch there is a brief period of downtime — no Pods are serving traffic until the new version starts.
While this sounds undesirable, certain workloads require it. If two versions of an application cannot run simultaneously — for example, because they hold exclusive locks on a database schema, a file, or a message queue — Recreate is the safest option. It guarantees that the old version is fully stopped before the new version starts.
Kubernetes Deployments default to the RollingUpdate strategy. To use Recreate you set spec.strategy.type: Recreate in the Deployment manifest.
Core Concepts
Step 1: How Recreate Works — The Sequence
- You update the Deployment (e.g., change the image tag).
- Kubernetes terminates all Pods in the current ReplicaSet.
- It waits until every old Pod has fully stopped (
Terminatedstate). - It creates a new ReplicaSet with the updated spec.
- New Pods start up and become Ready.
Between step 2 and step 5, zero Pods are serving traffic. The length of this downtime depends on how fast your application shuts down and starts up.
Step 2: When to Use Recreate
| Scenario | Use Recreate? | Reason |
|---|---|---|
| Database migration that requires exclusive access | Yes | Old and new versions would conflict on schema. |
| App holds an exclusive file lock or lease | Yes | Two versions cannot hold the same lock simultaneously. |
| Incompatible message-queue consumer versions | Yes | Old consumer might misinterpret new message format. |
| Stateless web API with zero-downtime requirement | No | Use RollingUpdate, Blue/Green, or Canary instead. |
| Development / staging environment | Yes | Downtime is acceptable; simpler and faster than rolling update. |
Step 3: Recreate vs RollingUpdate
| Feature | Recreate | RollingUpdate |
|---|---|---|
| Downtime | Yes (brief) | No (zero-downtime) |
| Two versions running at the same time | Never | Yes, during the rollout |
| Configuration | strategy.type: Recreate | Default — no config needed |
| Rollback | kubectl rollout undo | kubectl rollout undo |
| Extra resources during update | None (old Pods are gone first) | Yes (surge Pods overlap) |
Step 4: Minimising Downtime
Even with Recreate you can reduce the gap:
- Fast shutdown: Handle
SIGTERMgracefully. Close connections, flush buffers, and exit quickly. KeepterminationGracePeriodSecondsreasonable (default 30s). - Fast startup: Optimise your .NET application startup. Use compiled ahead-of-time (AOT) or reduce dependency injection registration time.
- ReadinessProbe: Use a readiness probe so the Service does not send traffic until the new Pod is genuinely ready.
Step 5: The Manifest — Key Section
The only change compared to a normal Deployment is adding two lines under spec.strategy:
Note: when using Recreate, you do not set maxSurge or maxUnavailable — those parameters only apply to RollingUpdate.
Hands-On: Kubernetes Commands
Deploy the Application
Verify the Strategy Type
Output should show StrategyType: Recreate.
Watch Pods During an Update
Open this in a separate terminal so you can observe the stop-then-start sequence in real time.
Trigger an Update (Change the Image Tag)
Check Rollout Status
View Rollout History
Rollback to Previous Version
Step-by-Step Example
Scenario 1: Initial Deployment
We have a .NET 10 Notification API that processes messages from a Service Bus queue. Only one version should consume messages at a time, so we use the Recreate strategy.
1. Apply the Deployment Manifest
2. Verify All 3 Pods Are Running
You should see 3 Pods in Running state.
Scenario 2: Updating with Recreate
A new version (2.0) changes the message schema. Running 1.0 and 2.0 side by side would cause deserialization errors, so Recreate is the correct strategy.
3. Open a Watch Window
4. Update the Image
5. Observe the Sequence
In the watch window you will see:
- All 3 old Pods move to
Terminatingsimultaneously. - Once all 3 are gone, 3 new Pods appear in
ContainerCreatingstate. - New Pods transition to
Runningas the containers start.
During the gap between steps 1 and 3, the application is unavailable. For our Notification API consuming from a queue, this is acceptable — messages wait in the queue until the new Pods are ready.
Scenario 3: Rollback
If the new version has a bug, roll back. This also uses the Recreate pattern — old Pods are terminated first, then the previous version is recreated.
6. Undo the Rollout
7. Confirm the Rollback
The image should show notification-api:1.0 again.
Summary
- Recreate terminates all old Pods before creating new ones—there is a brief downtime window.
- Set
spec.strategy.type: Recreatein the Deployment manifest. Do not setmaxSurgeormaxUnavailable. - Use Recreate when two versions cannot coexist — exclusive locks, incompatible schemas, or shared resources that do not support concurrent access.
- Minimise downtime by handling SIGTERM quickly, optimising startup, and using readiness probes.
- Rollback works the same as RollingUpdate:
kubectl rollout undo. - For workloads that need zero downtime, use RollingUpdate, Blue/Green, or Canary instead.