Stalled rollouts and progressDeadlineSeconds

WHAT THIS TESTS Failure semantics of rollouts: the system is designed to protect availability when a new version is broken, and to surface a clear failure signal.

A GOOD ANSWER COVERS When new Pods fail readiness, the rolling update stalls. Because maxUnavailable bounds how many old Pods can be removed, and removal only proceeds as new Pods become Ready, the controller stops making progress while keeping the old, healthy Pods running. So the service stays up on the previous version. The Deployment sits in a Progressing state until progressDeadlineSeconds elapses with no progress, at which point the controller sets the Progressing condition to False with reason ProgressDeadlineExceeded. This does not automatically roll back; it marks the rollout failed so CI/CD pipelines and operators can react.

COMMON WRONG ANSWERS Assuming Kubernetes automatically reverts on failure; you must run kubectl rollout undo. Thinking old Pods are deleted regardless, which would cause an outage. Confusing progressDeadlineSeconds with a probe timeout; it measures lack of overall rollout progress, not a single check.

LIKELY FOLLOW-UPS How do you detect a failed rollout in automation? kubectl rollout status returns a non-zero exit and reports ProgressDeadlineExceeded. How to recover? Roll back or fix and reapply. What disables the deadline? Setting it very high effectively disables failure detection.

ONE CONCRETE EXAMPLE A new image has a bad config and its Pods never pass readiness. With maxUnavailable 0, the controller brings up surge Pods that stay NotReady and never removes the old ones, so traffic continues on the old version. After progressDeadlineSeconds (say 600 seconds) of no progress, the Deployment is marked ProgressDeadlineExceeded, and the on-call engineer runs rollout undo.