Kubernetes service "no endpoints available": debugging checklist

TL;DR

No endpoints means the Service's selector matches zero ready pods. The checklist is short: does the selector match the pod labels exactly, are the matched pods actually ready (passing readiness probes), and are the pods in the same namespace. Nine times out of ten it is a label typo or a failing readiness probe, and the fix takes two minutes once you look.

The query

Kubernetes service "no endpoints available": debugging checklist

Use this when

• A Service shows no endpoints
• Traffic to the service blackholes or 503s
• After label or selector changes
• Readiness probes were recently modified

Not for when

• DNS resolution of the service name (endpoints exist, DNS fails)
• Ingress routing to the service
• ExternalName services (they never have endpoints)

Steps

Step 1: Compare the selector against pod labels

Get the service's selector and list pods with those exact labels. Selectors are exact-match; one wrong character or a missing label means zero matches. This is the most common cause. Expected output: the selector either matches pods (move on) or it does not (fix the labels or selector).

Step 2: Check pod readiness, not just existence

Endpoints only include pods that pass their readiness probes. Pods can exist and match the selector but be excluded because readiness fails. Check pod conditions, not just pod phase. Expected output: matched pods confirmed ready, or the failing readiness probe identified.

Step 3: Verify the namespace

Services only select pods in their own namespace. A service in production selecting pods that only exist in staging matches nothing. Cross-namespace selection is not a thing for ClusterIP services. Expected output: service and pods confirmed in the same namespace.

Step 4: Check the port names and numbers

The service's targetPort must match a port the pod actually exposes (by number or by name). A renamed container port without a service update breaks the endpoint mapping even when pods match. Expected output: targetPort resolving to a real container port.

Step 5: Look at the EndpointSlice directly

Inspect the EndpointSlice objects for the service to see exactly what the control plane computed. Empty slices confirm the diagnosis; partially populated slices point at specific unready pods. Expected output: the control plane's endpoint computation visible, confirming the fix.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstrN2Sljuep2ul7JvltFHpg