Kubernetes Pod Endpoint Lifecycle

Kubernetes Pod Endpoint Lifecycle is the sequence of additions and removals a Pod's IP address undergoes within Service Endpoints and EndpointSlice objects as that Pod moves through readiness, unreadiness, and termination. This lifecycle is what actually connects Pod health signals to real traffic routing, since kube-proxy and any Service-aware load balancer act only on the endpoint list, not on the Pod's status fields directly.

Becoming an Endpoint

The Selector Match

A Pod becomes a candidate for a Service's endpoint list the moment its labels match that Service's selector, regardless of the Pod's readiness state. Matching alone is not sufficient for inclusion as a serving address; readiness still gates that.

apiVersion: v1
kind: Service
metadata:
  name: endpoint-lifecycle-example
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

Readiness Gates Inclusion

Only once the Pod's Ready condition becomes True, driven by container readiness probes and any readiness gates, does the endpoint controller add the Pod's IP and port to the Service's Endpoints object (or the corresponding EndpointSlice) as a ready address.

kubectl get endpoints endpoint-lifecycle-example

Tracking Not-Ready Addresses

Visibility Without Traffic

A Pod that matches the selector but is not yet ready is not simply omitted; it appears in the notReadyAddresses field of the legacy Endpoints object, or with a ready: false condition in an EndpointSlice, giving visibility into Pods that are in progress toward becoming eligible without ever routing traffic to them.

subsets:
  - addresses:
      - ip: 10.244.1.12
    notReadyAddresses:
      - ip: 10.244.1.19
    ports:
      - port: 8080

Transitioning Between Ready and Not Ready

Live Toggling

Because readiness is re-evaluated continuously, a Pod already listed as a ready endpoint can be removed the moment its readiness probe starts failing, and re-added automatically once it passes again, all without the Pod itself restarting or being replaced.

Removal at Termination

Immediate Removal on Deletion

The instant a Pod's metadata.deletionTimestamp is set, the endpoint controller removes it from the ready address list, independent of its current readiness probe result and before any preStop hook or SIGTERM handling begins. This immediate removal is what starts the traffic-draining window a preStop sleep is typically designed to cover.

metadata:
  deletionTimestamp: "2026-07-18T11:45:00Z"

Propagation Delay

Because kube-proxy and external load balancers must observe and apply the endpoint change asynchronously across potentially many nodes, there is a brief window after removal during which some paths in the cluster may still route traffic to the terminating Pod, which is the underlying reason graceful termination practice recommends a short delay before the application itself stops accepting connections.

EndpointSlice as the Modern Mechanism

Sharding for Scale

EndpointSlice replaces the older, single-object Endpoints resource for large Services, splitting the address list across multiple slice objects to avoid a single object growing unbounded as a Service scales to thousands of Pods, while preserving the same ready and not-ready address tracking semantics per slice.

kubectl get endpointslices -l kubernetes.io/service-name=endpoint-lifecycle-example

Endpoint Lifecycle Diagram

Understanding this lifecycle separately from Pod-level readiness is essential because the two are not synchronized instantaneously; the propagation lag between a readiness change and its effect across the cluster's data plane is a frequent source of brief connection errors during rapid scaling or deployment events.