Debugging Service connectivity between Pods
Systematic Service debugging.
kubectl get endpoints to check the Service has Pod IPs (selector match); kubectl describe service to verify selector and ports; exec into the frontend to curl the Service DNS name.
What's really being asked
A structured approach to the most common Service failure: a Service that exists but has no working path to its Pods.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
kubectl get endpoints shows no addresses for a Service that exists, while its target Pods are Running. What is the most likely cause?
- a.The Service selector does not match the Pods' labels, or the Pods are not ReadyCorrect
- b.The cluster DNS is down
- c.The Pods are on a different node than the Service
- d.The Service needs a public IP assigned
Why? this is the answer
Empty endpoints means no Pods match the selector or none are Ready, since only ready, matching Pods become endpoints. DNS being down would not empty endpoints, and Services are not node-bound.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #debugging
- #services
- #endpoints
- #networking
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles