A web Pod for a tax-filing helper fails its liveness probe and restarts in a loop, yet the process is only slow to finish initializing. What probe change best stops premature kills?
Select an answer to reveal the explanation.
Short Explanation
Slow starters need a warmup lap before the referee starts calling fouls. A startupProbe gives the app time to initialize; liveness stays quiet until startup succeeds. That stops the restart loop caused by checking too early.
Full Explanation
When a web Pod for a tax-filing helper fails its liveness probe and restarts in a loop only because the process is slow to finish initializing, the best fix is to add or tune a startupProbe so liveness (and readiness) wait until initialization completes. startupProbe is the modern Kubernetes pattern for long startup: it disables the other probes until success, preventing premature kills of healthy-but-slow civic apps.
Why the other options fail by concept: Removing every probe abandons failure detection entirely. Pointing liveness at an unrelated sidecar port that is always open masks real main-container death. Setting failureThreshold to 1 on liveness makes restarts happen even faster, worsening the crash loop during slow init.
Exam caveat: Size startupProbe failureThreshold × periodSeconds to cover worst-case warm-up with margin. After startup succeeds, configure separate realistic liveness/readiness. initialDelaySeconds-only workarounds are older and less precise than startupProbe for long init. Ensure the startup endpoint/command actually reflects “ready to be probed,” not merely process start.
Operational check: Add a startupProbe aligned to the tax helper’s init signal, apply, and kubectl get pods -w to confirm the Pod reaches Ready without CrashLoopBackOff. kubectl describe pod should show startup probe progressing before liveness begins failing.