--- title: "Three Kubernetes Probes Make Different Decisions for an Inference Worker" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/inference-startup-readiness-liveness-probe-actions" last-updated: "2026-10-20" --- # Three Kubernetes Probes Make Different Decisions for an Inference Worker Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. An offered Kubernetes health-check integration needs to identify both the condition it tests and the consequence of that result. A configured startup probe holds back readiness and liveness checks until it succeeds. Readiness governs eligibility for ordinary matching-Service traffic. Repeated liveness failure can trigger a container restart. Those functions answer different needs; none alone establishes useful inference performance. ## Read the tested condition and the resulting action together A supplier can describe an inference worker as health checked while leaving the purchase unclear. Does its integration keep a starting application from being judged prematurely, withhold traffic from an unready worker, or respond to a process that cannot progress? Naming the endpoint without its probe role leaves that action unanswered. Kubernetes performs probes against containers. The diagnostic can run code or make a network request, and success means the specified diagnostic passed. For inference, ask what application state lies behind that response: an accessible process, the selected model loaded, or some other defined condition. A successful response carries no automatic claim about model accuracy, completed useful output or request latency. This comparison uses the official Kubernetes v1.34 documentation snapshot, checked October 20, 2026. The proposed software supplier must identify the release and application behavior it actually offers. The discussion explains integration scope rather than prescribing production checks or settings. References: [KP2](https://v1-34.docs.kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes) ## Startup success releases the other two checks When a startup probe is configured, Kubernetes disables that container's readiness and liveness probes until the startup probe succeeds. This gives startup its own decision: whether the application has reached the condition defined by that diagnostic. Startup probing is confined to startup; it is not a continuing substitute for the other checks. The practical distinction is between a check that has failed and a check that has not started. While startup still gates the container, the absence of a liveness failure supplies no observation that a liveness diagnostic passed. An offer that reports only a green overall health label can hide this difference. Startup gating also does not allow unlimited unsuccessful initialization. Reaching the configured startup failure criterion can terminate the container, with restart behavior governed by the applicable restart policy. The application determines what startup success means. Do not assume the diagnostic includes model warmup or a useful inference request. The related model-warmup guide examines initialization and request clocks; here the question is which checks startup success permits to begin. References: [KP1](https://v1-34.docs.kubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/), [KP2](https://v1-34.docs.kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes), [KP4](https://v1-34.docs.kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) ## Readiness changes regular traffic eligibility while the container can keep running A failed readiness result makes the worker unavailable for ordinary traffic through matching Kubernetes Services, without that readiness failure itself restarting the container. The kubelet continues running the container and checking readiness. That separation permits a worker to remain alive while it is unsuitable for the requests the Service would send it. The routing statement has a defined scope. EndpointSlices describe Service backends and their conditions. This article considers nonterminating Pods, ordinary matching-Service routing, no override that publishes unready addresses, and endpoint conditions that have caught up with the Pod state. Direct access or a separately managed routing path needs its own explanation from the supplier. Pod readiness can also depend on other containers and additional readiness conditions. A successful inference-container check alone does not settle every possible Pod-level requirement. In the worked snapshot below, those additional requirements are stipulated satisfied so that the three probe roles remain visible. References: [KP3](https://v1-34.docs.kubernetes.io/docs/concepts/services-networking/endpoint-slices/#conditions), [KP4](https://v1-34.docs.kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) ## Liveness failure has a different consequence from temporary unavailability Liveness checks do not wait for readiness checks to succeed. Once any startup gating has ended, readiness failure is not a pause button for liveness. Repeated liveness failure reaching the configured failure criterion leads to termination of the affected container and restart handling under the applicable policy. This concerns that container, rather than automatically creating a replacement Pod or supplying another GPU. Consider two conceptual faults. In the first, an inference process remains able to progress but a dependency required by its request path is temporarily unavailable. An integration might represent that state as unready while its separate liveness diagnostic still succeeds. Restarting that process would not, by itself, restore the unavailable dependency. In the second, the process remains present but cannot make progress because of a deadlock. Kubernetes identifies this as an example of a condition liveness probing can detect. The buyer needs to understand whether the offered diagnostic distinguishes these states or treats both as reasons to restart. These examples select no production check. They explain why the meaning of failure matters commercially: an integration that withdraws traffic and one that triggers restarts deliver different behavior even if both display the word unhealthy. A restart trigger also leaves successful application recovery to be demonstrated. References: [KP1](https://v1-34.docs.kubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/), [KP2](https://v1-34.docs.kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes), [KP4](https://v1-34.docs.kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) ## HP-222: three assigned GPUs, one traffic-eligible Pod Original hypothetical HP-222 takes one settled snapshot of three placed Pods, A, B and C. Each has one inference container assigned one exclusive whole-GPU resource. All match the same ordinary Kubernetes Service. The Pods are nonterminating, other Pod readiness requirements are satisfied, no unready-address override applies, and Service endpoint conditions reflect the stated readiness. These are invented inputs, not observations from a deployment. A has not yet passed its startup probe and remains within its allowed startup period. Its readiness and liveness probes have not begun. It is not ready for ordinary Service traffic. A has neither passed nor failed a liveness check in this snapshot: that check is still suppressed. B completed startup and passes liveness, but its readiness result is failed. Its container keeps running and retains its stipulated GPU assignment. B is excluded from regular matching-Service traffic; the failed readiness result does not itself call for a restart. C completed startup and passes both readiness and liveness. With the other stipulated conditions satisfied, C is the one Pod eligible for ordinary Service traffic. The resource count is one plus one plus one, or three assigned GPUs. The traffic-eligible population is zero plus zero plus one, or one Pod. The two totals answer different questions. A hardware allocation report can accurately show three GPUs while an offer describing three ready serving workers overstates this snapshot. Suppose a later fictional snapshot changes only B's readiness result to a successful state, with the corresponding endpoint update complete. The eligible population becomes two without adding a GPU or requiring a restart of B. If A merely completes startup, that releases its other probes; A's eligibility still needs the ensuing readiness result. HP-222 establishes eligibility counts under its assumptions. It supplies no throughput, latency or continuity result and makes no claim about existing connections or requests already in flight. References: [KP1](https://v1-34.docs.kubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/), [KP3](https://v1-34.docs.kubernetes.io/docs/concepts/services-networking/endpoint-slices/#conditions), [KP4](https://v1-34.docs.kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) ## Compare the behavior included in the health-check offer Ask the software supplier to connect each offered diagnostic to its application condition, probe role and consequence. A response saying that the model endpoint is checked still leaves open whether failure withholds traffic, triggers restart handling, or belongs only to startup. Even if the same endpoint is used in more than one role, those consequences remain distinct. Use HP-222 as a clarification question. Can the proposed reporting distinguish A's checks not yet running, B's live but unready state and C's traffic eligibility? A single healthy-worker count cannot answer all three. Ask which Pod and container the observation concerns, when it was collected and how it relates to the routing path the offer includes. Then separate the promised application result from the probe observation. If the proposal promises response quality or latency, request evidence for the stated model, software and workload. Probe success supports its defined diagnostic; the performance guide linked below addresses evidence for useful inference work. Choose the integration according to the behavior your application team needs to obtain. The linked quota and placement guide explains admission and placement; the replica and node-autoscaling guide explains changes to worker populations. An assigned GPU or an increased replica target still leaves the probe action unspecified. References: [KP1](https://v1-34.docs.kubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/), [KP2](https://v1-34.docs.kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes) ## Connect a separate physical project to the receiving platform team Kubernetes probe integration and inference acceptance belong with the appointed software or platform supplier. If the selected equipment also needs physical installation, Leviathan's Complete Physical Infrastructure Deployment service can scope agreed receiving, rack integration, onsite installation, IT cabling and physical handoff records. Use the related service and project inquiry to share a nonconfidential equipment, site and IT connection outline, identifying the team receiving the physical handoff. That inquiry concerns the physical package and its availability; it does not offer Kubernetes administration or managed model serving. References: [L1](https://www.leviathansystems.co/services/turnkey-gpu-deployment) ## Primary sources - [KP1 — Kubernetes v1.34: Liveness, Readiness, and Startup Probes](https://v1-34.docs.kubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/). Checked 2026-10-20. Versioned conceptual account of startup suppression, readiness traffic eligibility and repeated liveness failure. The snapshot is not the current-release documentation; applicability must match the offered platform. - [KP2 — Kubernetes v1.34: Pod Lifecycle — Container probes](https://v1-34.docs.kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). Checked 2026-10-20. Diagnostic mechanisms, probe outcomes, container-level actions and restart-policy relationship. Application diagnostics determine the condition tested; a passed probe does not define an inference benchmark. - [KP3 — Kubernetes v1.34: EndpointSlices — Conditions](https://v1-34.docs.kubernetes.io/docs/concepts/services-networking/endpoint-slices/#conditions). Checked 2026-10-20. Backend readiness and the exception for Services publishing unready addresses. Used for ordinary routing eligibility of nonterminating Pods, without claims about existing connections or in-flight requests. - [KP4 — Kubernetes v1.34: Configure Liveness, Readiness and Startup Probes](https://v1-34.docs.kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). Checked 2026-10-20. Conceptual introduction, Pod readiness dependencies and failure consequences: readiness failure leaves the container running; startup or liveness failure can trigger termination and restart handling. No tutorial configurations or timing values are adopted. - [L1 — Leviathan Systems: Complete Physical Infrastructure Deployment](https://www.leviathansystems.co/services/turnkey-gpu-deployment). Checked 2026-10-20. Defined physical delivery stages and installation records, with software commissioning and broader system acceptance separately assigned. ## Related Leviathan resources - [Model warmup, readiness and first useful response](/articles/inference-model-warmup-versus-ready-steady-state) - [Quota admission, Pod placement and worker readiness](/articles/gpu-kueue-quota-admission-versus-pod-placement) - [Inference replica scaling and GPU node provisioning](/articles/gpu-inference-replica-versus-node-autoscaling) - [Compare performance for the actual inference workload](/articles/which-gpu-is-fastest-workload-benchmarks) - [Scope complete physical infrastructure deployment](/services/turnkey-gpu-deployment) - [Discuss equipment installation and IT cabling](/contact?service=turnkey-gpu-deployment&from=%2Farticles%2Finference-startup-readiness-liveness-probe-actions) ## Does the selected equipment need physical installation? Share a nonconfidential equipment, site, IT connection and receiving-team outline to discuss physical deployment scope, records and availability. [Discuss the scope](/contact?service=turnkey-gpu-deployment&from=/articles/inference-startup-readiness-liveness-probe-actions)