Service has no endpoints

KubernetesKubernetes

Fix a Service with no endpoints: run kubectl get endpointslices, then match the selector to Pod labels and make the Pods Ready. Covers port mismatches.

easy fix·6 min read·2 causes

By Vishvesh Patel·DevOps Engineer·Updated 16 September 2026

Run these in order. Each one tells you what its output means before you change anything.

• Confirm the Service really has no backends

An empty ENDPOINTS column confirms it. If addresses are listed, the Service is fine and your problem is elsewhere. DNS, the port number, or a NetworkPolicy.

• Find out which of the two causes it is

Compare the selector against the labels the Pods actually carry. No Pod carrying those labels means cause 1. Pods that match but show 0/1 under READY means cause 2.

• Cause 1. Repoint the selector

Use whatever labels the Pods really have. Fix the Service rather than the Pods, since relabelling Pods forces a Deployment rollout. Endpoints populate within about a second.

• Cause 2, find out why the Pods are not Ready

Only Ready Pods become endpoints, which is deliberate. A failing probe here means the path, port or timing is wrong, or the app genuinely is not up yet.

If the steps above did not settle it, these are the causes in the order they are usually responsible. Each section explains why it happens and how to confirm it.

A Service with no endpoints is a dead end. It has a working DNS name and a working virtual IP, and nothing behind it, so connections are accepted and then fail.

The good news: there are exactly two causes, and five minutes of checking distinguishes them.

Empty ENDPOINTS confirms it. The older equivalent still works:

kubectl describe service shows the same thing:

Now: is it the selector, or readiness?

A Service finds its backends by label selector, and Kubernetes never validates that the selector matches anything. A Service with a typo is created successfully, reports healthy, and routes nowhere.

Compare the two directly:

There it is. The Service selects app=payments, the Pods carry app=payments-api. Close enough to miss on a read-through, and completely non-matching to Kubernetes.

Test the selector directly, which is the fastest confirmation:

If that returns nothing, you have found the problem. Fix whichever side is wrong, usually the Service, since changing Pod labels means a Deployment rollout.

• The namespace variant

A Service only selects Pods in its own namespace. Selectors do not cross namespaces, and there is no way to make them.

If the Pods are in a different namespace from the Service, no selector will ever match. Move the Service, or use an ExternalName Service pointing at the real one's FQDN.

Only Ready Pods become endpoints. That is deliberate and is the entire point of a readiness probe, but it means a misconfigured probe silently empties your Service while the Pods look fine at a glance.

STATUS: Running with READY: 0/1 is the signature. The container is up; the probe is failing.

The probe message names the cause. In rough order of frequency:

Two fixes worth knowing beyond the obvious.

A slow-starting application needs a startup probe, not a bigger initialDelaySeconds:

Test the endpoint from inside the Pod, which settles most probe arguments in one command:

If that works and the probe fails, the probe's path or port is wrong. If it fails too, the application is the problem.

Endpoints can be populated and traffic still fail, if targetPort does not match what the container listens on:

The symptom differs: endpoints exist but connections are refused. Using a named port avoids it entirely, since the name survives a port change:

A Service with clusterIP: None shows no cluster IP by design, and kubectl get svc displays None in that column. It still has endpoints, and DNS returns the Pod IPs directly. Check the EndpointSlice rather than the Service's cluster IP before concluding anything is wrong.

Why does my Kubernetes Service have no endpoints?

Two causes only. Either no Pod carries labels matching the Service's selector, or matching Pods exist but are not passing their readiness probe. Distinguish them by running kubectl get pods -l <selector> with the Service's own selector, if that returns nothing it is a label mismatch, and if it returns Pods showing READY 0/1 it is readiness. Kubernetes never validates that a selector matches anything, so a Service with a typo is created happily and routes nowhere.

Why is my pod Running but not Ready?

The container process started but its readiness probe is failing, so Kubernetes deliberately withholds traffic. kubectl describe pod shows the probe's failure message in the events, which usually names the cause directly. A 404 means the wrong path, connection refused means the wrong port or an application still starting, and context deadline exceeded means the probe timed out, which is easy with the default timeoutSeconds of 1. Test the endpoint from inside the Pod with kubectl exec to confirm which side is wrong.

Can a Kubernetes Service select Pods in another namespace?

No. Selectors only match Pods in the Service's own namespace, and there is no way to widen that. If your Service and Pods are in different namespaces, no selector will ever populate the endpoints. Either move the Service into the Pods' namespace, or create an ExternalName Service that aliases the real Service's fully qualified name, payments-api.payments.svc.cluster.local, which is the supported way to reference across namespaces.

Why do I get connection refused even though endpoints exist?

Almost certainly a targetPort mismatch. The Service is forwarding to a port the container is not listening on, so the connection reaches the Pod and is refused. Compare kubectl get svc <name> -o jsonpath='{.spec.ports}' against the container's actual port. Using a named port, declaring name: http on the container and targetPort: http on the Service, removes this class of error, since the name stays correct even if the number changes.

How does a readiness probe affect Service endpoints?

Only Ready Pods are included as endpoints, which is the mechanism that makes rolling updates safe. Traffic is withheld until a new Pod can actually serve. The consequence is that a misconfigured readiness probe empties the Service entirely while the Pods appear to be running normally. If you define no readiness probe at all, Kubernetes treats a started container as Ready immediately, which avoids this failure but reintroduces the one it was meant to prevent.

What is the difference between Endpoints and EndpointSlices?

EndpointSlices are the modern replacement, splitting a Service's backends across multiple smaller objects so a Service with thousands of Pods does not require one enormous object to be updated on every change. The legacy Endpoints object is still maintained for compatibility, so kubectl get endpoints <service> works and shows the same information. New tooling should read EndpointSlices, but for debugging either is fine. Both show an empty list when the Service has no backends.

Free, comprehensive DevOps tutorials and learning roadmaps. Master Docker, Kubernetes, CI/CD, and more.

Get notified about new tutorials and features.

• Roadmaps

• Interview Prep

• Certifications

• Company

© 2026 DevOpsLesson. All rights reserved.