Introduction

If a Kubernetes Service uses a selector, the Pods behind it are usually the Pods matching that selector and appearing in the Service's endpoints. The subtle part is that "selected by the Service" and "actually serving traffic right now" are related but not identical, so the most reliable answer comes from EndpointSlice data.

Start with the Service selector

Most normal Services define a label selector. You can inspect it first:

kubectl get service my-service -o yaml

If the selector is something like app=my-api,component=web, you can list matching Pods with:

kubectl get pods -l app=my-api,component=web -o name

This is a useful first check, but it does not guarantee those Pods are currently part of the actual endpoints being routed to. Readiness and endpoint population still matter.

EndpointSlice is the stronger answer

Kubernetes represents the real backing endpoints of a Service through EndpointSlice resources. Those slices can include a targetRef for each Pod, which gives you the Pod name directly.

kubectl get endpointslices \
  -l kubernetes.io/service-name=my-service \
  -o jsonpath='{range .items[*].endpoints[*]}{.targetRef.name}{"\n"}{end}'

This is often the closest answer to "which Pod names are behind this Service right now?" because it comes from the endpoint layer rather than just the selector definition.

If the output is empty, the Service may have no ready endpoints, no selector, or no matching Pods.

Why selectors are not always enough

A Pod can match the Service labels and still not serve traffic if it is not Ready. Kubernetes normally excludes unready Pods from regular Service endpoints unless the Service is configured to publish not-ready addresses.

That is why debugging based only on labels can mislead you. Label matching tells you which Pods are candidates. EndpointSlice tells you which endpoints the Service is actually advertising.

Special case: Services without selectors

Not every Service selects Pods. Some Services point to manually managed endpoints or external backends. In those cases, there may be no Pod names to list because the Service is not fronting Pods at all.

That is another reason the endpoint view is better than assuming every Service maps cleanly to a Deployment selector.

Namespace and tooling details

If the Service is not in the default namespace, add -n your-namespace to the commands. It is also common to combine the EndpointSlice query with a normal Pod listing when debugging readiness, restarts, and IPs together.

The practical workflow is:

1. inspect the Service selector
2. inspect the EndpointSlices
3. inspect the backing Pods directly

That sequence usually explains mismatches quickly.

In older clusters or quick one-off debugging, people still query the legacy Endpoints object. That can be helpful for IP visibility, but EndpointSlice is the better long-term source when you want Pod names and modern endpoint state.

Common Pitfalls

• Assuming every Service uses a selector and points directly to Pods.
• Listing selector-matching Pods and treating them as guaranteed traffic recipients.
• Ignoring readiness, which affects whether Pods appear in normal endpoints.
• Forgetting the namespace and accidentally querying the wrong Service or Pod set.
• Using old mental models of Endpoints only and overlooking EndpointSlice data.

Summary

• Service selectors tell you which Pods are intended candidates.
• EndpointSlice is the best source for the Pod names actually backing a Service.
• A matching Pod may still be absent from endpoints if it is not Ready.
• Some Services have no selector at all, so there may be no Pod names to list.
• For real debugging, inspect selector, EndpointSlice, and Pod state together.