LAB 01 · EASY · 5–10 MIN

The Service Has No Endpoints

A Deployment is healthy. The Service exists. Requests to the Service go nowhere. Find the break without rebuilding the workload.

Goal: Make api-svc route traffic to the running API pods.

Start the lab

Apply the broken manifest to a disposable cluster:

kubectl apply -f broken.yaml
kubectl get all -n breakfix-01

View broken.yaml · cleanup.sh

Hint 1

Do not start with DNS. Ask whether the Service has any backing endpoints at all.

Hint 2

Compare the Service selector with the labels on the pods.

Solution

Useful first checks:

kubectl get pods -n breakfix-01 --show-labels
kubectl get svc api-svc -n breakfix-01
kubectl get endpointslice -n breakfix-01 -l kubernetes.io/service-name=api-svc
kubectl describe svc api-svc -n breakfix-01

The Service selects app=backend, while the pods are labeled app=api. Kubernetes is doing exactly what you asked: selecting zero pods.

Change the Service selector to app: api. The EndpointSlice should populate almost immediately.

kubectl patch svc api-svc -n breakfix-01 -p '{"spec":{"selector":{"app":"api"}}}'
kubectl get endpointslice -n breakfix-01 -l kubernetes.io/service-name=api-svc

Then test the Service:

kubectl run curl --rm -it --restart=Never \
  --image=curlimages/curl:8.12.1 -n breakfix-01 \
  -- curl -s http://api-svc

Keep this: When a Service exists but has no backends, check labels before you start blaming DNS, kube-proxy, the CNI, or the phase of the moon.

Next lab: Pending Forever →