Why might a pod be Running but not receiving any traffic?

This is a genuinely common real-world confusion: kubectl get pods shows Running, everything looks healthy at a glance, yet requests to the Service time out or fail. The phase: Running field alone is not sufficient evidence the Pod is actually reachable — several other conditions have to also be true.

Cause 1: Failing readiness probe (the most common cause)

kubectl get pods
# NAME        READY   STATUS    RESTARTS   AGE
# my-app-xyz  0/1     Running   0          5m     <- Running, but READY shows 0/1

READY: 0/1 alongside STATUS: Running is the telltale sign — the container is executing, but its readiness probe (see that question) is currently failing, so the Pod has been removed from (or never added to) the Service's endpoints. Confirm directly:

kubectl describe pod my-app-xyz
# Look for: Readiness probe failed: ... in the Events section

Fix by understanding why the readiness check is failing (a slow-to-warm-up dependency, an incorrect readiness endpoint path, a genuine application problem) — this is functioning exactly as designed (the whole point of readiness probes is to prevent traffic from reaching a Pod that isn't actually able to serve it), so the fix is addressing the underlying readiness condition, not disabling the probe.

Cause 2: Service selector doesn't match the Pod's labels

kubectl get endpoints my-service
# NAME         ENDPOINTS   AGE
# my-service   <none>      10m      <- no endpoints at all, even though pods exist and are Ready

If a Service's selector doesn't match any Pod's actual labels (a typo, or the Pod's labels were changed without updating the Service, or vice versa), the Service has zero endpoints, regardless of how many perfectly healthy, Ready Pods exist elsewhere in the namespace. Compare the Service's selector directly against the Pod's actual labels:

kubectl get service my-service -o jsonpath='{.spec.selector}'
kubectl get pod my-app-xyz --show-labels

Cause 3: Port mismatch between Service and container

# Service expects the container to listen on 8080...
spec:
  ports:
    - port: 80
      targetPort: 8080
# ...but the container actually listens on a different port
containers:
  - name: app
    ports:
      - containerPort: 3000    # mismatch!

Even with correct labels and a passing readiness probe, if the actual application inside the container listens on a different port than the Service's targetPort expects, connections will fail once they reach the Pod — this is a configuration mismatch between the Service spec and the actual application, not something Kubernetes can detect or warn about on its own.

Cause 4: NetworkPolicy blocking the traffic path

If NetworkPolicies are enforced in the cluster (see the networking topic), a policy scoped to the target Pod might be blocking ingress from the specific source attempting to connect — worth checking explicitly (kubectl get networkpolicy -n <namespace>) if labels, readiness, and ports all check out but traffic still isn't getting through, especially in a namespace with a default-deny posture where a needed allow rule might simply be missing.

The systematic debugging order

1. Check READY column in kubectl get pods — is the Pod actually marked Ready, not just Running?
2. Check kubectl get endpoints <service> — does the Service actually have any endpoints listed at all?
3. Compare the Service's selector against the Pod's actual labels directly.
4. Verify the Service's targetPort matches what the container actually listens on.
5. Check for NetworkPolicies that might be blocking the specific traffic path, if steps 1-4 all check out.

Working through these in order, rather than guessing, resolves the overwhelming majority of "Running but unreachable" cases quickly.