Rollouts via ReplicaSets
Rollouts via ReplicaSets
A Deployment never runs pods itself — it manages ReplicaSets. When the pod template changes, it creates a new ReplicaSet and shifts weight while honoring maxUnavailable and maxSurge:
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 1
maxUnavailable: 0 keeps ready capacity at or above replicas; maxSurge: 1 allows exactly one extra pod during the swap. Progress depends on readiness — pods that never pass the readiness probe stall the rollout, and progressDeadlineSeconds (default 600) marks it failed.
Old ReplicaSets are retained at zero replicas as rollout history.
Controlling a Release
Controlling a Release
kubectl set image deploy/web app=registry.example.com/web:1.5.0
kubectl rollout status deploy/web
kubectl rollout pause deploy/web
kubectl rollout resume deploy/web
kubectl rollout history deploy/web
kubectl rollout undo deploy/web --to-revision=3
Pausing freezes the Deployment's reactions so you can apply several edits — labels, env vars, images — before resuming once. Pair releases with a PodDisruptionBudget so voluntary evictions cannot empty the fleet mid-rollout.
rollout status exits non-zero on failure, which makes it the CI gate: never mark a deploy successful because the command returned without drama.
Pitfalls and Interview Angles
Pitfalls and Interview Angles
Pitfall 1 — readiness that does not reflect serving ability. With maxUnavailable: 0, traffic safety rests entirely on the readiness probe; a trivial probe lets the rollout replace healthy pods with broken ones.
Pitfall 2 — changes that trigger no rollout. Only pod-template edits create a new ReplicaSet — editing Deployment labels or pointing at an image tag that did not move does nothing. revisionHistoryLimit (default 10) controls how many old revisions remain available to undo.
Interview-ready: compute surge and unavailable numbers for replicas=3, explain the pod-template-hash label separating ReplicaSets, and clarify rollback scope — undo swaps the pod template back; it never restores deleted Services or ConfigMaps.
Quiz
1. With replicas=3, maxUnavailable=0, maxSurge=1, how many pods may exist mid-rollout?
2. What does kubectl rollout pause actually stop?
3. A rollout hangs with old pods still serving. What should you check first?
Flashcards
Question
maxSurge vs maxUnavailable
Click to reveal answer
Answer
Surge caps extra pods during rollout; unavailable caps how many may be down — surge trades capacity for safety.
Question
rollout undo scope
Click to reveal answer
Answer
Reverts the pod template to an earlier revision; dependent objects like Services are untouched.
Question
progressDeadlineSeconds
Click to reveal answer
Answer
Default 600s — after this without progress the rollout is marked failed.
Question
PodDisruptionBudget role
Click to reveal answer
Answer
Limits voluntary evictions so drains cannot take a Deployment below its healthy minimum mid-release.
Revision Notes
Key Takeaways
- 1. Deployments manage ReplicaSets; template changes create new ones
- 2. Readiness gates rollout progress more than any other setting
- 3. rollout status is your verification gate — make it a CI step
Interview Tips
- • Do the surge/unavailable math aloud for a small replica count
- • Separate what undo restores (pod template) from what it does not (deleted resources)
Cheat Sheet
RollingUpdate bounded by maxUnavailable + maxSurge; readiness drives progress; pause batches edits; undo reverts template only; PDB protects voluntary evictions.