Kubernetes · Orchestration under pressure
How do you run a safe rolling update?
Short answer
Use maxSurge and maxUnavailable to control capacity, readiness probes to gate traffic, and disruption budgets to protect availability during the rollout.
A Deployment's RollingUpdate strategy replaces pods gradually. maxSurge controls how many extra pods can exist above the desired count, and maxUnavailable controls how many can be unavailable. The controller waits for new pods to become ready before continuing, so readiness correctness is essential.
- Set maxUnavailable to 0 for critical services and use surge capacity
- Ensure PodDisruptionBudgets cover voluntary disruptions such as drains
- Use a preStop hook and graceful shutdown to finish in-flight requests
- Watch rollout status and error rates, not just pod readiness
- Database migrations must be backward compatible across both versions
kubectl set image deployment/api api=registry.example.com/api:1.5.0
kubectl rollout status deployment/api --timeout=5m
kubectl get pods -l app=api -w
kubectl rollout pause deployment/apiZero downtime is a property of the whole system, not just the Deployment. Load balancer draining, connection handling, schema compatibility and external dependencies all matter. A canary or progressive delivery controller can reduce blast radius further by shifting a small percentage of traffic first.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What do maxSurge and maxUnavailable control?
- 2Why are readiness probes critical during a rollout?
- 3How do you handle a backward-incompatible database migration?
- 4What would make you choose a canary deployment?
Say it in the interview
A rolling update replaces pods gradually using maxSurge and maxUnavailable, and readiness gates when new pods receive traffic. I set maxUnavailable to zero for critical services and pair rollouts with disruption budgets and graceful shutdown. I also treat schema changes as backward compatible so both versions can run at once. During the rollout I watch error rates, not just pod status, and pause or roll back if they move.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.