Tuning maxSurge and maxUnavailable

WHAT THIS TESTS Real-world rollout tuning and the trade-off between never dropping capacity and finishing the update fast, constrained by cluster resources.

A GOOD ANSWER COVERS maxSurge defines how many extra Pods, above the desired replica count, the Deployment may create during an update. maxUnavailable defines how many Pods, below the desired count, may be unavailable at any moment. Both can be expressed as integers or percentages of the desired count. The controller uses them together as upper and lower bounds while it scales the new ReplicaSet up and the old one down.

ZERO DOWNTIME, FASTEST ROLLOUT To guarantee that full serving capacity is always available, set maxUnavailable to 0, which forbids dropping below the desired count. To make the rollout as fast as possible, set maxSurge high, for example 100 percent, so an entire second set of new Pods can come up in parallel before the old ones are removed. The cost is roughly double the resources during the rollout window, so this only works if the cluster has the headroom.

COMMON WRONG ANSWERS Claiming zero downtime while leaving maxUnavailable above 0, which permits a capacity dip. Setting maxSurge so high that scheduling fails for lack of CPU or memory. Forgetting that both cannot be 0 simultaneously, since that would stall progress.

LIKELY FOLLOW-UPS What if both are 0? The rollout cannot proceed. How do readiness probes interact? New Pods must be Ready before old ones are removed under maxUnavailable 0. Percentage rounding? maxSurge rounds up, maxUnavailable rounds down.

ONE CONCRETE EXAMPLE For a six-replica web tier needing zero downtime, set maxUnavailable: 0 and maxSurge: 100%. The controller launches six new Pods alongside the six old ones, waits for all new Pods to pass readiness, then removes the old six at once, briefly running twelve Pods.