A modern cluster runs an app that needs several minutes to warm caches. Engineers only set a large initialDelaySeconds on liveness. What is the preferred modern pattern?
Select an answer to reveal the explanation.
Short Explanation
initialDelaySeconds is a fixed nap timer; startupProbe is a real ‘tell me when you’re ready’ handshake. For long warmups on modern clusters, prefer startupProbe so liveness doesn’t guess a single delay. Once startup passes, normal probes take over.
Full Explanation
On a modern cluster, an app that needs several minutes to warm caches should prefer a startupProbe for long initialization so liveness and readiness remain gated until startup succeeds. Relying only on ever-larger initialDelaySeconds is the older, coarser approach; startupProbe explicitly models “still starting” for municipal apps with heavy warm-up.
Why the other options fail by concept: Keeping raising initialDelaySeconds alone and never adding a startupProbe is outdated relative to the preferred pattern and delays all probing rigidly. Replacing the app with a CrashLoop makes probes irrelevant by making the service useless. Moving health checks into a CronJob that restarts the Deployment hourly is not a substitute for correct container probes.
Exam caveat: Configure startupProbe failureThreshold × periodSeconds ≥ worst-case warm-up. After startup, use tighter liveness/readiness suited to steady state. initialDelaySeconds can still appear, but should not be the only tool for multi-minute init. Ensure cache warm-up failure eventually fails startup so bad deploys surface.
Operational check: Add startupProbe covering cache warm-up, reduce reliance on huge initialDelaySeconds, roll the Deployment, and confirm no liveness kills during init via kubectl describe/events. Measure time-to-Ready and set progressDeadlineSeconds accordingly for the civic app.