Debugging Service connectivity between Pods

WHAT THIS TESTS A structured approach to the most common Service failure: a Service that exists but has no working path to its Pods.

A GOOD ANSWER COVERS Start with kubectl get endpoints SERVICE_NAME (or kubectl get endpointslices). The key question is whether the Service lists any backend Pod IPs. Empty endpoints is the classic culprit and usually means the Service selector does not match the backend Pods' labels, or the Pods are failing their readiness probe and so are excluded. Next, kubectl describe service SERVICE_NAME to inspect the selector, the port, and especially the targetPort, since a port mismatch silently breaks traffic. Then kubectl exec -it FRONTEND_POD -- curl the backend Service DNS name and port, to test whether DNS resolves and the connection succeeds. If DNS fails, check CoreDNS; if it resolves but hangs, suspect a NetworkPolicy, which you inspect with kubectl get networkpolicy.

COMMON WRONG ANSWERS Stopping at kubectl get pods once both show Running, which ignores selector, port, readiness, and policy issues. Assuming the Service is wired up just because it exists.

LIKELY FOLLOW-UPS What causes empty endpoints? Label/selector mismatch or unready Pods. How do NetworkPolicies break this? A default-deny policy blocks the frontend. Port confusion? port is the Service port, targetPort is the container port.

ONE CONCRETE EXAMPLE The backend Service selector is app=backend, but the Deployment labels Pods app=back-end. kubectl get endpoints shows none. Fixing the label so it matches the selector immediately populates endpoints, and the frontend's curl to the Service succeeds.