After readiness failures, a flaky health endpoint flickers. Which probe field requires multiple consecutive successes before marking the Pod ready again?
Select an answer to reveal the explanation.
Short Explanation
Coming back online shouldn’t be a single lucky ping. successThreshold on readiness says ‘pass me N times in a row’ before Endpoints take you back. That smooths flaky health endpoints without ignoring real recovery.
Full Explanation
After readiness failures, when a flaky health endpoint flickers, successThreshold (greater than 1) on the readiness probe requires multiple consecutive successes before the Pod is marked Ready again. That hysteresis prevents municipal Services from rapidly oscillating Endpoints membership when a permits or 311 health check is intermittently flaky during recovery.
Why the other options fail by concept: timeoutSeconds alone does not demand three successes before Ready. periodSeconds is the probe interval, not a success counter, even when greater than 10. failureThreshold counts consecutive failures before marking unready/restarting—it does not count successes after failure for readiness recovery.
Exam caveat: For liveness, successThreshold must be 1 (Kubernetes enforces this); elevated successThreshold is a readiness (and startup) tool. Combining higher successThreshold with sensible periodSeconds defines recovery time. Fix flaky endpoints properly—hysteresis is mitigation, not a cure for a broken /readyz.
Operational check: Set readiness successThreshold to 3 on a test Deployment, induce failures then recovery, and watch kubectl get pod -w Ready column: it should require consecutive passes before Ready=True and before Endpoints re-add the Pod.