A library client reaches a Service ClusterIP but receives connection refused. Endpoints list a Pod IP. What is a likely cause?
Select an answer to reveal the explanation.
Short Explanation
You found the building and buzzed the suite—but nobody’s home on that door number. ClusterIP got you there; targetPort has to match where the app actually listens.
Full Explanation
When a library client reaches a Service ClusterIP but receives connection refused and Endpoints list a Pod IP, a likely cause is that nothing is listening on the Pod's targetPort—the Service port mapping does not match the container's listen port. You found the building and buzzed the suite, but nobody is home on that door number. Using the wrong kubeconfig user does not always produce connection refused to ClusterIPs; kubeconfig affects API access, not east-west Service TCP resets inside the cluster. Enabled node swap is not translated by Kubernetes into TCP resets for Services as a defined mechanism for this symptom. An expired API server certificate blocks kubectl to the API; it does not generally reset east-west Service traffic between pods. Exam caveat: Connection timed out often implicates NetworkPolicy or CNI; connection refused more often means the port is closed on the target. Confirm with kubectl exec and ss/curl to the pod IP:port. Operational check: Align Service port/targetPort with the container listen port, roll if needed, and retest ClusterIP access for the library client. In municipal production practice, record the finding in the incident ticket with command output snippets, confirm the fix under change control, and re-validate the user-facing civic service before closing the change window.