Kubernetes Endpoint Termination: Follow the Requests Already in Flight

Identify which promise the endpoint offer makes

A proposal may use the word drained to mean that a backend has left regular target selection. A buyer may understand the same word to mean that every request already accepted there has received its complete response. The purchase remains ambiguous until the supplier connects each meaning to its evidence.

For inference, that distinction matters whenever a response is unfinished when its worker begins leaving service. A new destination for subsequent selections answers where later work may be sent. It leaves the earlier response obligation attached to a different question: what happened to that identified request?

This explanation uses the official Kubernetes v1.34 documentation snapshot, checked October 20, 2026. The supplier must identify the offered release, application and routing implementation. The discussion evaluates proposal evidence; it selects no shutdown procedure or operating settings.

Read serving, terminating and ready together

EndpointSlices expose three related conditions. For a Pod-backed endpoint, serving follows the Pod's Ready condition. Terminating indicates deletion has begun, normally before the containers exit. Ready is essentially serving combined with not terminating; however, a Service with spec.publishNotReadyAddresses=true makes ready true.

Under the normal policy, an endpoint can therefore have serving=true, terminating=true and ready=false. It can retain serving capability during departure while being excluded from ordinary new selection. These conditions describe endpoint state, with no per-request completion record.

References: [KD01]

The shutdown lifecycle leaves application completion to explain

The Pod lifecycle account describes local shutdown and control-plane endpoint evaluation proceeding alongside one another. Terminating endpoints are retained during the transition. It distinguishes finishing open connections from applications that also need session draining and completion. The serving condition helps consumers assess continuing readiness during termination.

Shutdown does not wait indefinitely for arbitrary application work: the documented lifecycle ultimately permits forcible termination when the applicable grace period expires. A promise to finish responses therefore needs an application account of how that result is supported within the offered lifecycle.

Neither the start of termination nor a later container exit supplies the content of a response received by its caller. The supplier needs evidence at the boundary where it promises completion, tied to the earlier accepted request identities.

References: [KD03]

OPS-DRAIN-01: one new-selection target, two unfinished responses

Wholly fictional case OPS-DRAIN-01 has two inference endpoints, A and B, behind one normal Kubernetes Service. No unready-address publication override applies. Conditions are current and reconciled, and the stipulated routing consumer ignores terminating A for new selection. B remains ready=true, serving=true and terminating=false. This is an invented state comparison, not a deployment or test.

Before departure, A accepted two identified requests, R1 and R2. For this case, completion means the stipulated complete response received at the caller's application boundary. A first token does not meet that finish criterion.

Now A has serving=true, terminating=true and ready=false. R1 and R2 are both unfinished. B is the one normally eligible target for new selection. Separately, two earlier accepted requests remain unfinished on A. One endpoint and two requests are different populations; subtracting one from two would explain nothing about either response.

Later, independently supplied application evidence reports R1 complete and R2 still unfinished at its observation cutoff. The original population reconciles as one completed plus one unfinished: 1 + 1 = 2 requests. That evidence establishes one completion. It leaves the promise of both complete responses unfulfilled at that cutoff.

The case supplies no migration to B, cancellation or retry outcome. It also supplies no connection, batch or GPU-kernel count; none is assumed to equal one request. B's eligibility does not move R2 or finish it. The useful change in the later account comes from new application evidence about R1, rather than a different interpretation of A's conditions.

References: [KD01]

Keep the consumer and routing exceptions in the promise

Kubernetes documents that Service proxies normally disregard terminating endpoints, but may select serving-and-terminating endpoints when every available endpoint is terminating. OPS-DRAIN-01 excludes that fallback because B remains eligible. The publication override described above is another reason to inspect the actual Service policy.

Endpoint updates also have to reach the consumer. A current control-plane observation alone cannot establish that a particular routing component has applied it. The example explicitly supplies that settled state; a real proposal needs to identify the relevant observation and implementation.

Direct access and custom routing require their own account. Even an accurate endpoint-state report cannot establish that every request path follows ordinary Service selection, or that existing connections admit no further work. The conditions support a scoped selection explanation, rather than a universal promise that no new traffic can reach A.

References: [KD02][KD03]

Compare the offers against R1 and R2

Suppose offer W promises withdrawal from regular new selection through the stated Service consumer. Under OPS-DRAIN-01's assumptions, B remaining eligible while A is ignored can answer that need. The buyer can purchase that function while retaining responsibility for earlier accepted work elsewhere.

Suppose offer C additionally promises complete responses for all requests accepted before departure. Its evidence must follow that population through the transition. In the later fictional account, R1 is complete and R2 remains unfinished. C's endpoint report supplies no missing R2 result. B becoming the only eligible target answers neither whether R2 completes nor what the caller eventually receives.

For an actual comparison, ask the supplier to identify the acceptance event, the requests accepted before departure, the promised completion boundary and the observation cutoff. Connect those request outcomes to the endpoint's transition and the routing consumer's observation, rather than presenting an endpoint screenshot and an unrelated total of successful responses. A total that includes later work on B cannot silently substitute for the original population on A.

Read the result at its stated scope. A response observed complete by the server leaves caller receipt unresolved if the promise ends at the caller. An unfinished response at the cutoff establishes neither eventual success nor eventual failure. Any later outcome must come from later evidence. The broader completion promise needs that account even when endpoint withdrawal worked as offered.

Use the related guides for the decisions around departure

The probe guide explains startup gating, readiness and liveness actions for nonterminating workers. The PDB guide explains whether a covered eviction can proceed. Neither result supplies the subsequent response history examined here.

Quota admission and Pod placement, replica and node scaling, and model warmup address obtaining workers and preparing them to serve. They do not resolve the departing worker's R1/R2 obligations. The deadline guide follows caller abandonment and cancellation; the HTTP/2 guide separates transport streams from model batches. Use those guides for their own questions without converting their counts or events into evidence that prior requests finished.

For a streamed response, the related stream-completion guide develops the application finish boundary. OPS-DRAIN-01 simply stipulates its complete-response criterion so the endpoint transition remains the decision under review.

Connect a separate equipment project to its physical handoff

If a separately selected equipment change also requires physical installation, Leviathan's Complete Physical Infrastructure Deployment service can discuss agreed receiving, rack integration, onsite installation, IT cabling and physical handoff records. Use the related service and project inquiry with a nonconfidential equipment, site, connection and receiving-team outline to discuss scope and availability.

That inquiry concerns the physical equipment package. Kubernetes administration, routing behavior and inference request completion remain with the appointed platform and application providers.

References: [L1]