What is the difference between rolling updates and recreate deployment strategies?
Compare Kubernetes rolling update and recreate deployment strategies: zero-downtime rollouts, maxSurge and maxUnavailable, and when each strategy fits best.
Expected Interview Answer
A rolling update replaces pods gradually so the app stays available throughout the rollout, while a recreate strategy terminates all old pods first and then starts the new ones, causing brief downtime.
Rolling updates are the default Deployment strategy: Kubernetes spins up new-version pods and removes old ones incrementally, bounded by maxSurge and maxUnavailable, so a mix of both versions runs during the transition. Recreate scales the old ReplicaSet to zero before creating the new one, guaranteeing only a single version runs at a time. Choose recreate when versions cannot coexist — for example incompatible database schema changes or exclusive resource locks.
- Rolling updates give zero-downtime releases
- Recreate guarantees only one version runs at once
- Rolling updates support gradual, controllable rollout via maxSurge/maxUnavailable
- Recreate avoids version-coexistence bugs
- Both integrate with automated rollback
AI Mentor Explanation
Think of substituting a fielding side. A rolling update is like sending fresh fielders on one at a time so ten players always hold the field and play never stops. Recreate is like calling every fielder off the ground, emptying it completely, then walking a brand-new eleven out together — the pitch sits idle in between and no ball can be bowled until they arrive.
Step-by-Step Explanation
Step 1
Pick the strategy
Set spec.strategy.type to RollingUpdate (default) or Recreate in the Deployment manifest.
Step 2
Tune rolling bounds
For RollingUpdate, set maxSurge (extra pods allowed above desired) and maxUnavailable (pods that may be down) to control pace.
Step 3
Trigger the rollout
Update the pod template (e.g. the container image); Kubernetes creates a new ReplicaSet and begins the transition.
Step 4
Observe the swap
Rolling scales new up while scaling old down incrementally; Recreate scales old to zero, then scales new from zero.
Step 5
Verify and roll back
Watch with kubectl rollout status; use kubectl rollout undo if readiness probes report failures.
What Interviewer Expects
- Knowing RollingUpdate is the default and gives zero downtime
- Explaining maxSurge and maxUnavailable
- Recognising that both versions coexist during a rolling update
- Knowing when Recreate is required (incompatible versions)
- Awareness of readiness probes and rollback
Common Mistakes
- Thinking rolling updates cause downtime
- Believing Recreate is the default strategy
- Ignoring maxSurge/maxUnavailable and their effect on capacity
- Forgetting readiness probes, which lets broken pods receive traffic
- Not considering version coexistence issues with a rolling update
Best Answer (HR Friendly)
“A rolling update swaps the app version out piece by piece so users never notice any downtime, while a recreate approach stops the whole old version first and then starts the new one, which briefly takes the app offline. Teams pick recreate only when the two versions genuinely cannot run side by side.”
Code Example
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 4
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: myorg/web:2.0
readinessProbe:
httpGet:
path: /healthz
port: 8080apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 4
strategy:
type: Recreate
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: myorg/web:2.0Follow-up Questions
- How do maxSurge and maxUnavailable interact during a rollout?
- How do you roll back a failed deployment?
- What role do readiness probes play in a rolling update?
- When would a blue-green or canary strategy be better than either?
- How does kubectl rollout status detect a stuck rollout?
MCQ Practice
1. Which is the default Deployment strategy in Kubernetes?
RollingUpdate is the default; it replaces pods incrementally to avoid downtime.
2. Which field allows extra pods above the desired count during a rolling update?
maxSurge sets how many pods can be created above the desired replica count during the rollout.
3. When is the Recreate strategy most appropriate?
Recreate guarantees a single version runs at once, which is needed when versions are incompatible.
Flash Cards
Default Deployment strategy? — RollingUpdate — replaces pods gradually for zero downtime.
What does Recreate do? — Terminates all old pods, then starts new ones — causes brief downtime but only one version runs.
maxSurge vs maxUnavailable — maxSurge = extra pods allowed above desired; maxUnavailable = pods allowed to be down during rollout.
Why use Recreate? — When new and old versions cannot coexist, e.g. breaking schema changes or exclusive locks.