What problem does the Kubernetes startupProbe solve, and how does it interact with the liveness and readiness probes while it is still running?

## The problem Some containers take a long and *variable* time to become useful: a JVM warming JIT and connection pools, an app replaying a changelog or rebuilding an index, a legacy application server. A liveness probe that starts checking too early kills the container mid-boot; it restarts, boots slowly again, and you get a permanent CrashLoopBackOff that looks like an application bug but is really probe misconfiguration. Before Kubernetes 1.16 the only lever was to make the liveness probe itself tolerant - a huge `initialDelaySeconds` or `failureThreshold`. That works during boot and ruins steady state: afterwards, the same tolerance means a genuinely hung process takes minutes to be detected. One knob was being asked to serve two opposite requirements. ## What startupProbe does `startupProbe` is a third probe with the same handler options (`exec`, `httpGet`, `tcpSocket`, `grpc`) and the same timing fields. Its role is to answer one question once: *has this container finished starting?* Semantics while it is pending: - **Liveness is disabled.** The kubelet will not restart the container for liveness reasons, however long boot takes, as long as the startup probe has budget left. - **Readiness is disabled and the container is not ready**, so it stays out of Service endpoints. There is no window in which a half-started Pod receives traffic. - The startup probe itself retries every `periodSeconds` up to `failureThreshold` times. When it **succeeds**, it never runs again for that container instance, and liveness and readiness begin their normal cadence immediately. If it **exhausts** its budget, the kubelet kills the container and `restartPolicy` applies - usually another restart, with the budget starting over. ## Sizing it The maximum tolerated startup time is: `initialDelaySeconds + failureThreshold x periodSeconds` Set that to comfortably exceed the **worst** observed cold start - a node under memory pressure, a cold image cache, a slow dependency at boot - not the median. A common shape is `periodSeconds: 10, failureThreshold: 30` for a five-minute allowance. Keep `periodSeconds` small enough that a fast boot is noticed promptly, since the container is not marked ready until the next scheduled check. The payoff: liveness can now be aggressive - `periodSeconds: 10, failureThreshold: 3` gives roughly 30-second detection of a genuine hang, which would be unsafe without a startup probe. ## Choosing the handler Often the startup probe reuses the readiness endpoint, or a cheaper dedicated one. A `tcpSocket` startup probe is tempting but weak - the listener may open long before the app can serve. Prefer an HTTP endpoint that succeeds only when initialisation genuinely finished. ## Common mistakes - **Keeping a large `initialDelaySeconds` on liveness as well** - redundant and confusing; the startup probe has taken over that role. - **Making the startup budget too small**, producing a boot-time crash loop easily misdiagnosed as an application failure. The tell is a rising `restartCount` with `Startup probe failed` events and logs that always end mid-initialisation. - **Assuming the startup probe keeps running.** It does not; after the first success only liveness and readiness matter, so a container that degrades later is caught by liveness - which is why you still need one. - **Using it in place of an init container** for ordered prerequisites. A startup probe observes the app's own progress; it does not perform setup. ## Interview shape A complete answer names the old dilemma, states the three interactions (liveness disabled, readiness disabled, runs once), gives the budget formula, and closes with the practical benefit: tight liveness timings become safe.