# Pod is Terminating but still receives traffic: checking EndpointSlices

Diagnose pod is Terminating but still receives traffic: checking EndpointSlices. Evidence to collect, a worked operational example and recovery checks.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/kubernetes-terminating-endpoints/
Language: en

A Terminating Pod can still have a running process and an EndpointSlice entry. Inspect ready, serving and terminating separately. Removal from ordinary traffic selection, state propagation and completion of established connections occur in different parts of the system.

## Connect the Pod to its Service

Preserve the Pod UID, deletionTimestamp, Service selector and associated EndpointSlices. A Service can have multiple slices, so inspecting only the first object is incomplete. Match the endpoint address and IP family to the intended instance. Identify the actual traffic component too: kube-proxy, ingress, a mesh or an external balancer may have separate updates and existing connections. Kubernetes status cannot establish instantaneous synchronization of every copy.


[Official reference 1](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/).

## Read endpoint conditions

Serving describes the endpoint's ability to serve responses; terminating marks deletion. Ready normally represents serving without terminating, with an exception for publishNotReadyAddresses. Documentation also describes proxy behavior when all available endpoints are terminating. Thus ready=false is useful for ordinary selection but is not a universal contract for every EndpointSlice consumer. Record the effective proxy version and configuration before concluding that its behavior is incorrect.


[Official reference 2](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/).

## Build a timed example

In a test, an operator deletes a Pod, its EndpointSlice receives terminating=true, and the local process continues cleanup. A client using an established connection still receives a response. That does not necessarily mean the Pod was selected for a new connection after proxy update. Test new and established connections separately with synthetic traffic. Do not automatically extend the result to streaming API behavior or interrupted usage accounting.

| Event | Evidence to record |
| --- | --- |
| Pod deletion | UID and precise time |
| Endpoint change | All three conditions and address |
| Proxy update | Evidence from the actual consumer |
| Process exit | Completion of the local handler |

## Correct the specific stage

Check readiness during shutdown and provide a suitable grace period. Investigate how the proxy receives updates and handles terminating endpoints. A fixed sleep is not a substitute for measuring propagation. Traffic through another Service or directly to a Pod IP is outside the selected EndpointSlice's control. Identify the path in every test to avoid combining results from different routes and connection modes.

## Preserve the limits of the conclusion

A successful check establishes that the selected path stops assigning new work according to its intended policy and lets the process finish. It does not establish an atomic distributed update. Save the timeline, selectors, conditions and connection-creation method. Repeat the exercise after replacing ingress or the service proxy: the previous timeline belongs to a particular implementation. This artifact explains observed behavior without promising a universally instantaneous drain.

Record whether the client reused a connection. It can explain a terminating process response without implying the balancer assigned new connections after receiving current state.

Related operational reading: [network and uptime](/journal/network-and-uptime/); [vllm health ready](/journal/vllm-health-ready/).