Lab · Foundations
Lab: Fix a Broken Service Selector
Practice service routing fundamentals: selectors, endpoints, and the common ways Services become empty while pods look healthy.
Prerequisites
What you should have before you begin.
- A cluster and namespace
- kubectl installed
- Basic understanding of labels/selectors
Lab text
Follow the sequence. Change one thing at a time.
Goal
You will learn the canonical checks for “service not routing”: whether endpoints exist, whether selectors match labels, whether ports align, and whether readiness gates traffic.
- Confirm endpoint population.
- Confirm selectors match labels.
- Confirm targetPort/port alignment.
Inspect endpoints first
If endpoints are empty, routing is impossible regardless of DNS or ingress.
- Empty endpoints usually means label mismatch or pods not Ready.
- EndpointSlices are the modern source; check both for clarity.
kubectl
shell
kubectl get svc,ep,endpointslices -n <ns>
kubectl describe svc <svc> -n <ns>Selector vs labels
A Service selector is exact. One character off is zero endpoints.
- If selectors are missing, Service is probably headless/manual endpoints.
- If labels differ across pods, you might have multiple ReplicaSets or mixed deployments.
kubectl
shell
kubectl get svc <svc> -n <ns> -o yaml | rg -n "selector|port|targetPort"
kubectl get pods -n <ns> --show-labelsPorts and readiness
Even with endpoints, traffic can fail if the pod listens elsewhere or readiness never becomes true.
- Confirm containerPort and the actual listener port.
- Confirm readinessProbe matches the serving path.
- Remember: Services send traffic only to Ready endpoints.
Fix and verify
Make the smallest edit: correct the selector or labels, then watch endpoints repopulate.
- Endpoints appear.
- Port-forward succeeds.
- Requests return expected responses.
kubectl
shell
kubectl get endpointslices -n <ns> -w
kubectl port-forward svc/<svc> 8080:<port> -n <nsRelated
Canonical link
Canonical URL: /labs/service-selector-mismatch