Service has no endpoints: The Service exists but no ready pod matches its selector

A Service with no endpoints resolves to an address that answers nothing. Either the label selector matches no pods, or the pods it matches are not Ready.

Applies to: All Kubernetes versions

What it means

A Service does not route traffic by itself. The endpoints controller watches for pods matching the Service's selector and adds the ready ones to an EndpointSlice, which is what kube-proxy programs into the node's forwarding rules. If that set is empty, the Service's ClusterIP still resolves in DNS but there is nowhere to send traffic, so connections are refused or time out. Only two things produce an empty set: no pod matches the selector, or every matching pod is not Ready. Distinguishing them takes one command and eliminates most of the guessing.

Most common causes

• The Service's selector does not match the pods' labels — a typo, or labels changed on the workload but not on the Service.
• The pods exist and match, but all of them are failing a readiness probe.
• The pods are in a different namespace. A Service selects only within its own namespace.
• The Service's targetPort names a port the container does not declare.
• No pods exist at all — the Deployment is scaled to zero or nothing was scheduled.
• A Service defined with no selector at all, where endpoints are meant to be managed manually and were not.

How to diagnose it

1. Check the endpoints directly: kubectl get endpointslices -l kubernetes.io/service-name=SERVICE -n NAMESPACE. Empty is the confirmation.
2. Compare selector and labels: kubectl get svc SERVICE -o jsonpath='{.spec.selector}' against kubectl get pods --show-labels -n NAMESPACE.
3. List the pods the selector would match: kubectl get pods -l KEY=VALUE -n NAMESPACE. No results means the selector is wrong.
4. If pods do match, check their READY column. All not-ready means the problem is a readiness probe, not the Service.
5. Check the port mapping: the Service's targetPort must match a container port number or a declared port name.

How to fix it

1. Correct the selector or the pod labels so they match. They are compared exactly, including case.
2. Fix the readiness probe or whatever it is reporting, so pods become ready and are added.
3. Move the Service into the same namespace as its pods, or use an ExternalName or a manually managed endpoint if the target is genuinely elsewhere.
4. Correct targetPort to match the container's declared port.
5. Scale the workload up if it is at zero replicas.

Notes

The DNS name resolves whether or not endpoints exist, so a client sees a connection failure rather than a name resolution failure. This misdirects debugging towards DNS, which is working perfectly.

Related

• Readiness probe failed — The pod was removed from service endpoints
• Ingress 503 — The ingress has no healthy backend

Sources

• Kubernetes documentation — Service
• Kubernetes documentation — EndpointSlices
• Kubernetes documentation — Debug Services