The rolling update strategy's maxSurge/maxUnavailable knobs, kubectl rollout status/undo for monitoring and reverting, readiness gates preventing premature traffic shift, and why config changes don't trigger a rollout automatically.
Published September 23, 2026
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # how many EXTRA pods beyond desired count are allowed during rollout
maxUnavailable: 0 # how many pods are allowed to be DOWN during rollout
A Deployment's default update strategy — rolling update — replaces old pods with new ones gradually, controlled by two knobs: maxSurge (how many pods ABOVE the desired replica count can exist temporarily, e.g. starting new pods before killing old ones) and maxUnavailable (how many pods can be unavailable at once). Setting maxUnavailable: 0 guarantees zero-downtime during a rollout (never fewer than the full desired count is actually available) at the cost of needing extra capacity headroom during the transition (via maxSurge); this is the Kubernetes-native version of Deployment Strategies' more general rolling-update discussion, made concrete with specific, tunable parameters.
kubectl rollout status deployment/order-service # watch progress live, blocks until complete or failed
kubectl rollout undo deployment/order-service # revert to the PREVIOUS ReplicaSet/revision
kubectl rollout undo deployment/order-service --to-revision=3 # revert to a SPECIFIC prior revision
kubectl rollout status is the standard way to watch a deployment's rollout progress in real time (useful in a CI/CD pipeline as an explicit "wait for the deploy to actually succeed" gate, directly relevant to CI/CD Pipeline Design's deploy stage). kubectl rollout undo is what makes a Deployment's ReplicaSet-history (from Core Objects — old ReplicaSets aren't deleted immediately, just scaled to zero) directly useful: reverting is simply shifting replica counts back to a PRIOR ReplicaSet, not a slow rebuild-and-redeploy of the old version from scratch — this is why rollback via kubectl rollout undo is typically fast, on the order of the same time a normal rolling update takes.
A rolling update's new pods only start receiving traffic once they pass their READINESS PROBE (Probes & Autoscaling) — this is what prevents a rollout from routing live traffic to a new pod version that's still initializing (or, worse, broken) before it's actually able to serve requests correctly. This connects the Deployment mechanism directly to the readiness-probe design decisions made earlier: a readiness probe that's too lenient (returns ready before the application is genuinely functional) undermines the safety a rolling update is supposed to provide, letting a broken new version receive real traffic during the transition.
As covered in Config & Secrets, updating a ConfigMap or Secret referenced by a Deployment does NOT, by itself, trigger a new rollout — the Deployment's pod template hash is unchanged (the ConfigMap reference itself didn't change, only its underlying data), so Kubernetes sees no reason to roll anything. The checksum-annotation workaround (hashing the ConfigMap's content into a pod template annotation) is specifically what forces a genuine pod-template change, and therefore a real rollout, whenever the underlying config actually changes — without it, a critical config update can silently sit unused by already-running pods indefinitely.
Q: What happens if a rollout's new pods keep failing their readiness probe indefinitely?
A: The rollout simply stalls — Kubernetes keeps waiting for the new pods to become ready before shifting more traffic/replicas, respecting maxUnavailable's constraint the whole time; this is actually the SAFE failure mode (old, working pods stay serving traffic, broken new pods never receive it) — a stalled rollout should trigger alerting (Alerting Strategy) for investigation, but it doesn't itself cause an outage, which is precisely why the readiness-gated design is valuable.
Q: Is there a limit to how far back kubectl rollout undo --to-revision=N can go?
A: Yes — Kubernetes retains a bounded revision history (configurable via revisionHistoryLimit, commonly defaulting to 10), after which older ReplicaSets are garbage collected; rolling back further than the retained history isn't possible via this mechanism and would require redeploying from a known-good artifact/manifest instead.
Q: Does maxSurge have any cost implications worth considering?
A: Yes — maxSurge pods consume real cluster capacity temporarily (extra CPU/memory beyond steady-state), which matters for capacity planning (and connects to Cost Awareness later in this course) — a cluster sized with zero headroom for maxSurge can fail to schedule the extra pods needed for a zero-downtime rollout, forcing an unplanned trade-off between deployment safety and available capacity right when it's least convenient to discover.
Q: How does this rolling-update mechanism compare to the blue-green and canary strategies covered in Deployment Strategies? A: Kubernetes' native rolling update is essentially the 'rolling update' strategy from that lesson, built in as the Deployment's default; blue-green and canary are DIFFERENT strategies that typically require additional tooling beyond a bare Deployment (a service mesh, a dedicated deployment controller like Argo Rollouts) to implement the more sophisticated traffic-splitting or dual-environment-switch behavior those strategies need.