Why is a Kubernetes Pod Running but the app unreachable?

Our shop Pod says Running, yet curl gets connection refused. Look at the READY column: zero out of one. That's the first clue that Running doesn't mean reachable. This terminal output is illustrative, but the pattern is very real, and it's worth learning to read.

Running only tells you about the last box, the app process. A request first goes from the Client to shop-svc on port 80. The Service selects Pods into Endpoints, but only if they're Ready. Then targetPort must match 8080. Break any link, and traffic stops.

Running means the kubelet started the container process. That's all. Ready means the readiness probe passed, so the app can actually serve requests. Picture a slow-loading app: the process is alive, the light is green, but the sign still says closed, so no traffic arrives.

Watch what the kubelet does. It calls /ready on the shop app, and while the app is still loading, it gets a 503. So the Pod stays out of the endpoints. The kubelet keeps asking. Once shop answers 200 OK, the Pod is marked Ready and its IP joins. If that never happens, you stay at zero of one.

The shop Pod shows Running with READY zero of one. Will shop-svc send it any requests?

No, it stays out of the endpoints. A Service only routes to Pods whose readiness probe has passed. Running just means the container process started, so a Pod that is not Ready is left out of the endpoints and gets no traffic at all.

In the Deployment's Pod template, three lines matter. The label app: shop is what the Service will look for. The containerPort says the app listens on 8080. And the readinessProbe checks /ready on 8080. Get that path or port wrong, and the Pod stays unready forever.

Now the Service side. The selector says app shop, and it has to match the Pod's labels exactly. Clients call port 80, and the Service forwards to targetPort 8080. That's what actually routes traffic. containerPort in the Deployment is mostly informational, so targetPort must match what the app listens on.

Say someone typo'd the label. The Pod is labeled app equals web, but shop-svc looks for app equals shop. Nothing matches, so Endpoints stays empty. The Pod is Running, even Ready, yet the Service has nowhere to send traffic. Requests through shop-svc fail anyway.

The Service accepts traffic on port 80 and forwards it to targetPort 8080. That has to match what the app really does. If shop listens on 3000, connections fail. Same if it binds to 127.0.0.1, because traffic from outside the container gets refused. Bind to 0.0.0.0.

Start with READY. If it's 0/1, that's readiness, so run describe pod and look at the probe failures. Then check endpoints for shop-svc. Empty means the selector doesn't match. If endpoints exist but requests fail, compare the ports.

Running means the process started. Traffic needs Ready, plus a Service that matches. So when an app is unreachable, don't trust STATUS. Check the READY column first, then look at the Service's endpoints. Those two checks tell you which link in the chain broke.