A Kubernetes Service exists and its backing pods are Running, but requests to the Service's cluster IP hang, and the EndpointSlice for that Service lists no ready addresses. What causes an empty endpoint list, and how do you track it down?

## How a Service acquires backends A `Service` object of type ClusterIP contains a stable virtual IP, one or more port definitions, and a label `selector`. It does not contain pod addresses. A controller in the control plane continuously lists pods in the Service's namespace, keeps the ones whose labels match the selector, and writes their IPs into **EndpointSlice** objects (the modern, shardable replacement for the older single `Endpoints` object; both may be present because Endpoints are mirrored for compatibility). On every node, kube-proxy watches those slices and programs iptables or IPVS rules that DNAT traffic aimed at the cluster IP to one of the ready backend addresses. So "no endpoints" means the middle step produced nothing, and everything downstream — DNS, kube-proxy, NetworkPolicy — is irrelevant until it does. The symptom is usually a hang or immediate failure with no backend ever contacted. ## Cause 1: the selector does not match any pod labels This is where most people go wrong, because a Deployment has labels in three places: ```yaml metadata: labels: {app: web, managed-by: platform} # labels ON the Deployment object spec: selector: matchLabels: {app: web} # how the Deployment finds ITS pods template: metadata: labels: {app: web, version: v2} # labels ON THE PODS <-- the ones that matter ``` A Service's selector is matched against the third set. Copying labels from the Deployment's `metadata` is a classic error, as is adding a key to the Service selector (`app: web, tier: backend`) that the pod template does not carry — selectors are pure AND, so an extra key that no pod has matches nothing. Check it mechanically rather than by eye: ``` kubectl get svc web -o jsonpath='{.spec.selector}' kubectl get pods -l app=web,tier=backend --show-labels ``` If the second command returns nothing, you have found the bug. ## Cause 2: namespace scope Services select only within their own namespace. A Service in `frontend` cannot select pods in `backend`; cross-namespace access is done by addressing the other namespace's Service (`api.backend.svc.cluster.local`), or with an ExternalName Service. Manifests copied between namespaces frequently trip this. ## Cause 3: pods match but are not Ready This is the case that fools people, because `kubectl get pods` shows `Running` — but look at the READY column: `0/1` means the container is up and the readiness probe is failing. The EndpointSlice controller still records the address, with `conditions.ready: false`, and kube-proxy excludes it. Effectively the Service has no usable backends. ``` kubectl get endpointslice -l kubernetes.io/service-name=web -o yaml | grep -A3 conditions kubectl describe pod <pod> | grep -A5 Readiness ``` Causes of failing readiness are the usual probe problems: wrong path or port, the app bound to `127.0.0.1` so the kubelet cannot reach it, an aggressive `timeoutSeconds` (default 1s), or a genuine dependency the app is waiting on. Note the design intent: readiness failing *is* the system protecting you from routing to a pod that cannot serve. The bug is in the pod or the probe, and "fixing" it by deleting the readiness probe converts a visible outage into 500s for users. ## Cause 4: port resolution A Service port may specify `targetPort` as a **name** rather than a number. That name must exist in `ports[].name` on the container. If it does not, the port cannot be resolved for that pod and it contributes no endpoint for that port. Numeric `targetPort` values do not have this problem — the endpoint is created regardless of whether anything is listening, which is why a wrong number gives you endpoints plus connection-refused rather than empty endpoints. ## Cause 5: the Service has no selector A selectorless Service is legitimate — it is how you point a cluster-internal name at an external database by writing EndpointSlices yourself, and how `ExternalName` Services (which are pure DNS CNAMEs and have no endpoints by design) work. If someone removed the selector, no controller will populate anything. ## A repeatable checklist 1. `kubectl describe svc <name>` — read Selector, Port/TargetPort, and the Endpoints line. 2. `kubectl get pods -n <ns> -l <selector> --show-labels` — do any pods match at all? 3. If pods match, check the READY column and each pod's readiness probe. 4. `kubectl get endpointslices -l kubernetes.io/service-name=<name> -o yaml` — addresses present but `ready: false` confirms readiness as the cause. 5. Only once endpoints are ready and non-empty is it worth looking at DNS, ports or network policy. The ordering matters: it converts a vague "the service is down" into one of a handful of concrete states within a minute.