Rolling Update vs Recreate
Key Differences in Kubernetes
Rolling Update gradually replaces old Pods with new ones, ensuring zero downtime by keeping some old Pods running while new ones start. Recreate kills all existing Pods before creating new ones, causing a brief downtime window. Rolling Update is the default and preferred strategy for most production workloads; Recreate is used when running two versions simultaneously would cause data corruption or conflicts.
Side-by-Side Comparison
| Dimension | Rolling Update | Recreate |
|---|---|---|
| Downtime | Zero downtime — old and new Pods overlap during the transition | Brief downtime — all old Pods are terminated before new ones start |
| Resource Usage | Temporarily uses more resources (old + new Pods running together) | No extra resources — old Pods are gone before new ones start |
| Version Coexistence | Two versions run simultaneously during the rollout | Only one version runs at a time |
| Rollout Speed | Slower — Pods are replaced incrementally | Faster — all Pods replaced at once after termination |
| Configuration | maxSurge and maxUnavailable control the pace | No configuration parameters |
| Default Strategy | Yes — the default Deployment strategy | Must be explicitly configured |
| Rollback | Can be paused and rolled back during the rollout | Cannot pause — the old Pods are already terminated |
Detailed Breakdown
Rolling Update Strategy
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-api
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
selector:
matchLabels:
app: web-api
template:
metadata:
labels:
app: web-api
spec:
containers:
- name: api
image: my-api:2.0.0
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /ready
port: 8080
periodSeconds: 5
With maxSurge: 1 and maxUnavailable: 1 on a 4-replica Deployment:
- Kubernetes creates 1 new Pod with v2.0.0 (now 5 Pods: 4 old + 1 new)
- Once the new Pod passes its readiness probe, 1 old Pod is terminated (4 Pods: 3 old + 1 new)
- Another new Pod is created (5 Pods: 3 old + 2 new)
- Process repeats until all 4 Pods run v2.0.0
At every step, at least 3 Pods are serving traffic — zero downtime.
maxSurge and maxUnavailable Combinations
These two parameters control the trade-off between speed and resource usage:
# Conservative — zero downtime, needs extra resources
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
# Always maintains desired replica count. Creates 1 new Pod,
# waits for ready, then terminates 1 old Pod.
# Aggressive — faster rollout, brief reduced capacity
rollingUpdate:
maxSurge: 0
maxUnavailable: 1
# Never exceeds desired replica count. Terminates 1 old Pod,
# then creates 1 new Pod. Uses no extra resources.
# Fast — allows both surge and unavailability
rollingUpdate:
maxSurge: 2
maxUnavailable: 2
# Up to 2 extra Pods and 2 fewer Pods at the same time.
# Fastest rollout but needs more resources and has reduced capacity.
# Percentage-based — scales with replica count
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
# For 10 replicas: up to 3 extra, up to 3 unavailable (rounded up/down)
Recreate Strategy
apiVersion: apps/v1
kind: Deployment
metadata:
name: legacy-app
spec:
replicas: 3
strategy:
type: Recreate
selector:
matchLabels:
app: legacy-app
template:
metadata:
labels:
app: legacy-app
spec:
containers:
- name: app
image: legacy-app:2.0.0
ports:
- containerPort: 8080
The Recreate sequence is simple:
- All 3 existing Pods are terminated simultaneously
- Kubernetes waits for all Pods to finish terminating
- 3 new Pods are created with the updated template
- Traffic resumes once the new Pods pass readiness checks
During the gap between steps 2 and 4, the application is completely unavailable.
Visualizing the Difference
Rolling Update (maxSurge=1, maxUnavailable=0, replicas=3):
Time → t0 t1 t2 t3 t4 t5 t6
v1.0 ●●● ●●● ●●○ ●○○ ○○○
v2.0 ◐ ●◐ ●●◐ ●●●
Serving 3 3 3 3 3 3
● = running old Pod ◐ = starting new Pod ○ = terminated
Always 3 Pods serving traffic.
Recreate (replicas=3):
Time → t0 t1 t2 t3
v1.0 ●●● ○○○
v2.0 ◐◐◐ ●●●
Serving 3 0 0 3
Gap with zero Pods serving — downtime.
When Two Versions Cannot Coexist
The primary reason to use Recreate is incompatible versions. Common scenarios:
Database schema migration: Version 2.0 requires a schema change that breaks version 1.0. If both run simultaneously, the old version fails against the new schema.
# V1: SELECT * FROM users WHERE name = ?
# V2: SELECT * FROM users WHERE full_name = ? (column renamed)
# Running both versions causes V1 errors
strategy:
type: Recreate
Singleton workloads: An application that can only have one instance running (e.g., a scheduler or leader-based worker that does not implement proper leader election):
spec:
replicas: 1
strategy:
type: Recreate # Ensures old Pod is gone before new one starts
Exclusive resource access: Applications that hold exclusive locks on files, hardware (GPU), or licensed software:
spec:
replicas: 1
strategy:
type: Recreate # Old Pod releases the resource before new Pod claims it
Readiness Probes Are Critical for Rolling Updates
Without readiness probes, Kubernetes considers a Pod ready as soon as its containers start. With a Rolling Update, this means the old Pod might be terminated before the new Pod is actually serving traffic:
# WITHOUT readiness probe — risky
# New Pod is "ready" instantly, old Pod killed, but new Pod might not be serving yet
spec:
containers:
- name: app
image: my-app:2.0.0
# WITH readiness probe — safe
# Old Pod is kept until new Pod actually passes the readiness check
spec:
containers:
- name: app
image: my-app:2.0.0
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
Always configure readiness probes when using Rolling Update. They are the mechanism that makes zero-downtime deployments actually work.
Monitoring Rollouts
# Watch a rolling update in progress
kubectl rollout status deployment/web-api
# Pause a rolling update for manual validation
kubectl rollout pause deployment/web-api
# Resume after validation
kubectl rollout resume deployment/web-api
# Rollback if the new version has issues
kubectl rollout undo deployment/web-api
Pausing is only possible with Rolling Update. With Recreate, all old Pods are gone — there is nothing to pause.
minReadySeconds
The minReadySeconds field adds a delay before a new Pod is considered available:
spec:
minReadySeconds: 30
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
Even after the readiness probe passes, Kubernetes waits 30 seconds before considering the Pod available and proceeding with the rollout. This gives time to detect issues (crashes, error rate spikes) before replacing more old Pods.
Advanced Rollout Strategies
Rolling Update and Recreate are the only built-in Deployment strategies. For more advanced patterns, use external tools:
- Blue-Green: Deploy the new version as a separate Deployment and switch the Service selector. Tools: Argo Rollouts, Flagger.
- Canary: Route a percentage of traffic to the new version. Tools: Argo Rollouts, Istio, Flagger.
- A/B Testing: Route traffic based on headers or cookies. Tools: Istio, NGINX Ingress annotations.
# Argo Rollouts canary strategy (not a standard Deployment)
apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
strategy:
canary:
steps:
- setWeight: 10
- pause: {duration: 5m}
- setWeight: 50
- pause: {duration: 5m}
These tools build on top of Kubernetes primitives but are not part of the core Deployment API.
Use Rolling Update when...
- •You need zero-downtime deployments for user-facing services
- •Your application is backward-compatible and can handle two versions serving traffic
- •You want the ability to pause and rollback mid-deployment
- •You're running a stateless web application or API
- •You want gradual validation of the new version
Use Recreate when...
- •Your application cannot run two versions simultaneously (e.g., database schema incompatibility)
- •You have a singleton workload that must not have concurrent instances
- •You need to free all resources before starting the new version (GPU, licensed software)
- •You're running a development environment where brief downtime is acceptable
Model Interview Answer
“Rolling Update and Recreate are the two Deployment strategies in Kubernetes. Rolling Update is the default — it gradually replaces old Pods with new ones, controlled by maxSurge (how many extra Pods can exist) and maxUnavailable (how many Pods can be down). This ensures zero downtime because some Pods always remain available. The trade-off is that two versions coexist during the rollout, so the application must handle backward compatibility. Recreate terminates all existing Pods before creating new ones. This causes downtime but guarantees only one version runs at a time. Use Recreate when running two versions simultaneously would cause issues, like database schema conflicts or singleton constraints.”