Service has no endpoints

Before you start

• kubectl access to the Service's namespace with read permission on services, pods and endpointslices (API group discovery.k8s.io). kubectl auth can-i list endpointslices.discovery.k8s.io -n <namespace> tells you whether you have the last one.
• The namespace the workload really runs in. Pass -n <namespace> on every command, because a Service only selects pods in its own namespace.
• A way to send a request from inside the cluster: permission to kubectl exec into a running pod whose image has wget or curl, or to start a short-lived test pod as the Debug Services page does with kubectl run -it --rm.
• A cluster on Kubernetes v1.21 or later, where EndpointSlices are stable. From v1.33 the older Endpoints API is deprecated, and kubectl get endpoints prints a warning.
• Write access to the Service, or to the Deployment that owns the pods, and agreement from their owner. Any change to a Deployment's pod template starts a rollout that replaces its pods.

Work out which cause you have

A few questions to narrow the list. Every answer ends in a command that confirms or rules the cause out — this cannot see your cluster, so nothing here is a certainty until you have checked.

Check it with a tool

• Check the Service and Deployment manifests→
• What that status code means→

Or diagnose it manually

In this order. The first command usually contains the whole answer.

1. Step 1

   kubectl get endpointslices -l kubernetes.io/service-name=<service>

   Confirms the symptom and tells you immediately whether this is the problem you have. EndpointSlices replace the deprecated Endpoints API, and list pods that are not Ready too, so read ready for each address. An empty list here is the whole diagnosis of where the fault is not.

   Look for ENDPOINTS showing <unset>, or every address with ready: false in -o yaml

2. Step 2

   kubectl get svc <service> -o jsonpath='{.spec.selector}'; echo; kubectl get pods --show-labels

   Puts the selector next to the labels that exist, which resolves the most common cause by reading rather than guessing.

   Look for A key or value in the selector that no pod carries

3. Step 3

   kubectl get pods -l app=<label> -o wide

   Separates 'no pods match' from 'pods match but are not Ready'. These look identical at the Service and need entirely different fixes.

   Look for READY 0/1 with STATUS Running, which points at the readiness probe

4. Step 4

   kubectl describe svc <service>

   Shows the resolved ports and any events the Service itself recorded.

   Look for TargetPort, and an Endpoints line confirming what the control plane computed

Every cause, and how to fix it

Ordered by how often each one turns out to be the answer.

kubectl get pods -l "$(kubectl get svc <service> -o jsonpath='{.spec.selector}' | tr -d '{}"' | tr ':' '=')" --show-labels

kubectl get svc <service> -o jsonpath='{.spec.selector}'; echo; kubectl get deploy <deployment> -o jsonpath='{.spec.template.metadata.labels}'

kubectl get pods -l app=<label> -o wide

kubectl get svc <service> -o jsonpath='{.spec.ports[*]}{"\n"}'; kubectl get pod <pod> -o jsonpath='{.spec.containers[*].ports[*]}{"\n"}'

kubectl get svc <service> -o jsonpath='{.metadata.namespace}{"\n"}'; kubectl get pods -A -l app=<label> -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name

kubectl get deploy -n <namespace>; kubectl get rs,pods -n <namespace> -l app=<label>

How to know it is actually fixed

• ✓kubectl get endpointslices -l kubernetes.io/service-name=<service> -o yaml lists at least one address with ready: true.
• ✓A request from inside the cluster to the Service name succeeds — test from a pod, not from your laptop.
• ✓Delete one pod and confirm the endpoint list drops it and then restores it. An endpoint list that is correct only while nothing changes is not yet correct.
• ✓If an Ingress was returning 503, confirm it now returns the application's own response rather than assuming it followed.

Stopping it happening again

• Generate the Service selector from the same labels the Deployment template sets, rather than writing it twice.
• Give every workload a readiness probe that checks something real, and confirm it fails when the application is genuinely unhealthy.
• Use named ports so the Service and the container cannot drift apart numerically.
• Add an endpoint-count check to deploy verification. A rollout that reports success against an empty Service is the failure this page exists for.

Security considerations

• A Service selects by label alone, within its namespace. Anyone who can create a pod with matching labels there can receive the Service's traffic once that pod is ready, so keep selectors specific and limit who can create pods in production namespaces.
• Do not set publishNotReadyAddresses: true to make addresses appear. It marks every matching pod as ready in the EndpointSlice, so traffic reaches pods that have not passed their readiness probe.
• If the Debug Services steps lead you to a NetworkPolicy, add a narrow allow rule for the client and port instead of deleting the policy. A pod that no policy selects for ingress accepts connections from everywhere.
• Testing from inside the cluster means running commands in a production pod with kubectl exec, or starting a test pod. Use an image your cluster allows, and let --rm delete the test pod when you exit, as the Debug Services command does.