maxSurge=0 vs maxSurge=1 for fixed-capacity RollingUpdate with readiness probes

Direct answer

Under a hard fixed capacity ceiling neither setting guarantees uninterrupted Service availability with readiness lag. maxSurge=1 with maxUnavailable=0 preserves the Ready pod count by keeping old pods until new pods become Ready, but it requires one pod of spare capacity. maxSurge=0 respects a hard ceiling by terminating an old pod before creating a new one, and it guarantees a window with fewer Ready pods while the new pod waits for readiness.

If a new pod never becomes Ready, old pods are retained only with maxSurge=1/maxUnavailable=0. With maxSurge=0 the old pod is already terminated and is not restored; the Deployment stays below desired Ready replicas until manual intervention. There is no controller-level guarantee of endpoint availability in the window between old pod termination and new pod readiness. A pod is removed from Service endpoints when it enters Terminating, and the new pod is added only after its readiness probe succeeds.

Confirmed facts

• maxSurge and maxUnavailable are evaluated against the Deployment replica count. At least one of them must be >0; maxSurge=0/maxUnavailable=0 deadlocks progress.
• With maxSurge=1 and maxUnavailable=0 the Deployment controller scales up the new ReplicaSet first and scales down the old ReplicaSet only after the new pods are Ready. Ready capacity never dips below desired replicas while the rollout is progressing.
• With maxSurge=0 the controller must scale down an old pod before creating a new one. During readiness lag the total Ready pod count drops by up to maxUnavailable.
• The Deployment controller does not roll back on readiness failure. A pod that never becomes Ready stalls the rollout. progressDeadlineExceeded marks the Deployment failed but does not revert it.
• Endpoint membership follows pod readiness and lifecycle: a pod is removed from Endpoints on Terminating, and added only after readiness probe passes. No guarantee is made for the termination-to-readiness gap.

Likely explanation for your case

With a true hard ceiling where no additional pod can be scheduled, maxSurge=1 will cause the surge pod to stay Pending. Pending surge pods do not reduce existing availability, they only slow the rollout. If the ceiling is enforced by a ResourceQuota or a hard limit that blocks Pending pods from being created, maxSurge=1 will block progress entirely.

With maxSurge=0 the rollout respects the ceiling but you accept a temporary reduction in Ready pods equal to maxUnavailable while the new pod is initializing and passing readiness probes. The length of that window is controlled by initialDelaySeconds, periodSeconds and failureThreshold of the readiness probe, plus minReadySeconds if set.

Steps needed for this case

1. Confirm the paired maxUnavailable value. Availability behavior is defined by the pair, not maxSurge alone.
2. Check the capacity model: ResourceQuota, LimitRange, node allocatable, or cluster-autoscaler limits. Determine whether a Pending surge pod is harmless or a hard block.
3. Observe rollout behavior on a test Deployment with an intentionally failing readiness probe. Watch kubectl get endpoints and kubectl rollout status deployment and inspect Deployment conditions for ProgressDeadlineExceeded.
4. If you must stay on a hard ceiling, size the Service for N-1 Ready pods during rollout, add preStop sleep + terminationGracePeriodSeconds to drain, and set minReadySeconds to stabilize endpoints before scale-down.

One missing diagnostic detail that changes the recommendation: is the fixed capacity ceiling a hard quota that prevents creation of a Pending pod, or is it a scheduling headroom limit where a Pending surge pod is allowed to wait without evicting existing pods? If it is the latter, maxSurge=1 with maxUnavailable=0 is preferable for availability even with a ceiling.