A failed readiness probe removes a Pod from the live endpoint list within moments.

Behind each Service is an EndpointSlice listing ready Pod IPs. A headless Service skips the virtual IP and returns the Pod IPs directly.

The readiness link

Probe fails, the EndpointSlice controller drops the Pod, kube-proxy updates its rules. Traffic stops reaching it, but the container keeps running.

Headless ServiceclusterIP: None

DNS returns the individual Pod IPs and no load-balancing layer sits in between. With a StatefulSet each Pod gets its own name: pg-0.postgres.shop.svc.cluster.local.

no endpoints? start here

$ kubectl get endpointslices -l kubernetes.io/service-name=checkout
$ kubectl describe svc checkout | grep -A3 Endpoints
# empty = selector matches no Ready Pods

Headless Services and the EndpointSlice behind every Service

Under every Service there is an EndpointSlice (the scalable successor to Endpoints) listing the IP addresses of the Pods that match the selector and are ready. The EndpointSlice controller keeps it up to date from Pod status. kube-proxy on every node watches it and updates routing rules.

This is the exact mechanism that connects readiness probes to traffic. When a Pod's readiness probe fails, the controller removes its IP from the EndpointSlice and every node's rules are updated within moments, so no new requests reach it while it recovers. When it becomes ready again it is added back.

A headless Service sets clusterIP to None. There is no virtual IP; the DNS name resolves to the Pod IPs directly. That is what clients need when they must choose between individual backends, and it is what gives each StatefulSet Pod a stable DNS name such as pg-0.postgres. A regular ClusterIP Service can only route to some ready Pod, never to a specific one.

Debugging tip: when a Service seems to do nothing, check its endpoints first. An empty list means the selector matches no Pods or none are Ready, which is far more common than a networking fault.