The Pods are Running and Ready, the logs are quiet, and still nothing answers. A Service problem has a fixed shape, so walk a fixed checklist, in order, and stop at the first step that fails.

1. Selector and endpoints

kubectl get endpoints market-web
kubectl describe svc market-web | grep Endpoints
kubectl get pods -l app=market-web --show-labels

Endpoints: <none> means no Ready Pod carries the labels in the selector. Compare the selector with the Pod labels character by character; app=web and app=market-web look alike at a glance.

2. Ports

kubectl get svc market-api -o jsonpath='{.spec.ports[0]}'
kubectl logs deploy/market-api --tail=1

port is what clients dial; targetPort is where the Pod listens. Connection refused with endpoints present almost always means targetPort does not match the container. The application's own log line, listening on :8080, is the authority.

3. Readiness

A Pod that is Running but 0/1 is left out of the endpoints on purpose. Fix the readiness probe, or the app behind it, and the endpoint appears by itself.

4. DNS

kubectl exec client -- nslookup market-api
kubectl exec client -- nslookup market-api.wrecks.svc.cluster.local

bad address means the name is wrong or the caller is in another namespace. A bare name only resolves within the caller's own namespace.

5. NetworkPolicy

kubectl get netpol
kubectl exec client -- nc -zv -w 1 market-api 8080

A connection that times out rather than being refused, with everything above correct, is a policy dropping the packets. Chapter 11 has the rules.