A slow-starting civic reporting app passes its Ready condition quickly but still flakes under load for a few seconds. How does setting minReadySeconds on the Deployment help during a rolling update?
Select an answer to reveal the explanation.
Short Explanation
Passing a smoke test once isn’t the same as staying steady for a bit. minReadySeconds tells the Deployment to wait that long after Ready before counting the Pod as available, which slows the rollout just enough for flaky warm-ups.
Full Explanation
minReadySeconds is a Deployment field that delays considering a newly Ready Pod as available until it has stayed Ready for the specified duration. During RollingUpdate, available Pods gate how quickly old Pods can be terminated under maxUnavailable constraints. It does not change CPU requests, does not disable readiness probes, and does not by itself trigger rollout undo.