Operators want faster failure detection on a civic chat Pod without flapping on brief blips. Which probe timing approach balances speed and stability?
Select an answer to reveal the explanation.
Short Explanation
Probe timing is like a smoke alarm’s sensitivity dial. Shorter periods catch trouble sooner, but you still want a few failed checks—failureThreshold—before you declare the building on fire. Tune both so real outages show up without flapping on hiccups.
Full Explanation
Operators wanting faster failure detection on a civic chat Pod without flapping on brief blips should tune periodSeconds and failureThreshold together so several consecutive failures are required before action, at a cadence that still detects real outages promptly. Speed versus stability is a product of both knobs—not maxing one while ignoring the other—for resident-facing chat reliability.
Why the other options fail by concept: timeoutSeconds 0 is invalid/unsafe and tends to produce instant false failures under load. periodSeconds of 1 with failureThreshold of 1 forever maximizes flapping. Disabling probes in production and paging only after users complain abandons automated remediation Kubernetes probes provide.
Exam caveat: timeoutSeconds must be less than periodSeconds in practical setups and high enough for worst-case health handler latency. successThreshold matters when recovering from readiness failures. Separate liveness (conservative) from readiness (more agile) thresholds for chat Pods under bursty load.
Operational check: Choose periodSeconds and failureThreshold to meet MTTR targets without restart storms, apply, and load-test the civic chat Pod. Watch restart counts and Ready flaps in kubectl get pods -w; adjust until blips do not restart while true hangs are detected within the agreed budget.