Kubernetes Service Has No Endpoints - How to Fix It

When kubectl get endpoints <service> returns an empty list but the pods are Running, the Service's label selector and the pod labels don't match. One mismatched label key or value silently drops all traffic. Here's how to find and fix the mismatch.

Kubernetes Engineerkuberneteskubectlservices

How Kubernetes Services find pods

A Service does not track pods by name. It watches all pods in the namespace and builds an endpoint list from every pod whose labels match the Service's selector: block. If even one label key or value differs, the pod is invisible to the Service - and kubectl get endpoints returns an empty ENDPOINTS column.

Diagnose: confirm the Service has no endpoints

# See the pods - they should be Running
kubectl get pods --show-labels

# Check the Service's endpoint list
kubectl get endpoints web

Healthy output looks like 10.42.1.7:80. An empty <none> means no pod matched.

Inspect the selector vs the actual pod labels

Pull both sides and compare them:

# What selector is the Service using?
kubectl get service web -o yaml | grep -A5 selector

# What labels do the running pods actually carry?
kubectl get pods --show-labels

A typical mismatch looks like this in the manifest:

# Service selector - note the typo
selector:
  app: webb        # <-- "webb" (wrong)

# Pod template labels
template:
  metadata:
    labels:
      app: web     # <-- "web" (right)

The Service is looking for app: webb but every pod carries app: web, so ENDPOINTS stays empty and no request ever reaches a pod.

Fix: align the labels and re-apply

Correct the mismatch in deployment.yaml - either fix the pod template labels to match the selector, or fix the selector to match the pod labels - then apply:

# Edit deployment.yaml to make selector and pod template labels agree, then:
kubectl apply -f deployment.yaml

# Confirm endpoints are now populated
kubectl get endpoints web

Once labels align, Kubernetes repopulates the endpoint list within a few seconds and traffic flows without restarting any pods.

Why this is the #2 "service is down" cause

The #1 cause is a crashing pod. The #2 cause is this label mismatch. A one-character typo - webb instead of web, App instead of app (labels are case-sensitive) - produces a total outage with pods that appear perfectly healthy. Checking kubectl get endpoints takes two seconds and instantly tells you whether Kubernetes sees any pods behind the Service.

Want to try it hands-on? HeyDevJob gives you this exact setup in a live cloud workspace in your browser - edit it, run it, and see it work. Free, nothing to install.

Try it in a workspace →

What you'll practice

FAQ

Why does my Kubernetes Service have no endpoints?

The most common cause is a label selector mismatch - the Service's selector: block specifies labels that don't match the labels on the running pods. Check with kubectl get service <name> -o yaml and kubectl get pods --show-labels, then align them.

How do I check if a Kubernetes Service has endpoints?

Run kubectl get endpoints <service-name>. A healthy Service shows IP:port entries. An empty <none> means no pod's labels matched the selector.

Do I need to restart pods after fixing a label selector mismatch?

No. Once you apply the corrected manifest with kubectl apply -f, Kubernetes updates the endpoint list within seconds without restarting any pods - existing pods are just picked up by the selector.

Keep learning

Fix a Kubernetes CrashLoopBackOffKubernetes projectFix a Kubernetes ImagePullBackOffKubernetes projectSchedule a Pending Kubernetes PodKubernetes projectKubernetes roadmapStep by step to hiredKubernetes interview questionsSTAR answersAll Kubernetes projectsProjects hub

Learn it by doing. Open this in a live cloud workspace, make the change yourself, and keep a record of the work you can share.

Open the workspace →