A busy records-search API is healthy but occasionally slow under load. An aggressive liveness httpGet treats latency as death and restarts Pods, causing a thundering herd. What design lesson applies?
Select an answer to reveal the explanation.
Short Explanation
Liveness is the ejector seat, not the speedometer. If you fire it just because the app is busy, you restart healthy Pods and stampede the survivors. Save liveness for truly stuck processes; let readiness pull traffic when the instance is overloaded.
Full Explanation
Poorly designed liveness probes that fail on transient latency restart containers that were still making progress, reducing capacity and amplifying load on remaining Pods. Liveness should target conditions that warrant process restart (deadlock, wedged event loop). Readiness is the appropriate control to stop sending traffic to an overloaded but living instance. Probing the API server from app Pods or inventing unrelated thresholds does not fix conservative liveness design.