In this article
If Kubernetes repeatedly kills a Pod during legitimate initialization, inspect startupProbe. It provides a separate startup window while liveness and readiness are held back. Measuring initialization stages is more useful than guessing a larger initialDelaySeconds value.
If Kubernetes repeatedly kills a Pod during legitimate initialization, inspect startupProbe. It provides a separate startup window while liveness and readiness are held back. Measuring initialization stages is more useful than guessing a larger initialDelaySeconds value.
Identify each restart cause
Preserve Pod events, lastState and previous-container logs. Separate probe failure from OOMKilled, application exit and image-pull failure. The timeline should include container creation, preparation, the first successful check and termination. If the application exits before checks matter, a startup probe will not fix the original defect. Confirm that the check addresses the intended container rather than an adjacent sidecar.
Calculate the startup allowance
For startupProbe, failureThreshold multiplied by periodSeconds gives a nominal failure window, subject to the complete configuration and implementation. Other probes start after startup succeeds. Readiness controls suitability for Service traffic; liveness can trigger a restart. They are not interchangeable merely because both use HTTP. An unnecessarily expensive check can itself consume resources and distort startup measurements.
Use a measured example
Suppose normal preparation takes approximately 180 seconds in a separate test. A startup probe with periodSeconds 10 and failureThreshold 30 provides a nominal 300-second window. This illustrates the arithmetic rather than recommending one timeout for every model. Measure several cold starts and starts with locally available artifacts. Network downloading and process initialization can produce different timing distributions.
| Stage | Supporting evidence |
|---|---|
| Container exists | Runtime state |
| Initialization continues | Preparation logs and startupProbe |
| Traffic may be accepted | Application-appropriate readiness |
| Process hangs after startup | A separate liveness check |
Change only the probe policy
Keep the image, resources and inputs unchanged while updating the Pod template with the measured allowance. Raising memory limits and changing engine settings simultaneously would obscure the explanation for improvement. For an exec probe, verify the command exists in the image. For a network probe, check address, port and timeout. If startup never succeeds, investigate application state and dependencies rather than indefinitely extending the waiting period.
Verify the transition out of startup
Confirm that a successful startup check enables the later probes and that readiness does not admit an unprepared process to traffic. Separately reproduce a post-startup hang with a test application. Retain the probe manifest, timeline and restart events. This artifact demonstrates both sides of the policy: sufficient patience for normal preparation and detection of a later failure. It does not establish generation quality or guarantee a maximum customer-response latency. Recheck the allowance when a deployment changes artifact preparation, because the previous startup distribution may no longer apply.
Record successful and interrupted starts separately. A repeatedly killed process does not reveal normal initialization duration, so failed-restart timings alone cannot justify the startup allowance.
Related operational reading: vllm health ready; autoscaling gpu cold start.