Your Kubernetes Pod Is Running — So Why Is Your Application Still Not Receiving Traffic?

The pod is Running. The Deployment looks healthy. The Service exists. And yet the application gets no traffic.

This is one of the most common production issues we see in Kubernetes. The fix is almost never in the pod itself. It is somewhere on the path between the user and the container. This guide walks that path hop by hop.

1. Running doesn't mean ready to receive traffic

Start with the pod, but read the READY column, not just the STATUS.

kubectl get pods -n <namespace> -o wide

• 1/1 Running: the container is up and passing its readiness check.

• 0/1 Running: the container is up, but Kubernetes has removed it from traffic.

• Restarts climbing: the app is crashing and coming back, so traffic is hitting a moving target.

If the pod is 1/1 and stable, the problem is further up the path.

2. Check the Service

The Service is what turns a group of pods into one stable address. Check that it exists and points where you expect.

kubectl get svc -n <namespace>

kubectl describe svc <service-name> -n <namespace>

Look at three fields: Selector, Port and TargetPort. Most traffic problems live in one of them.

3. The small label mismatch that breaks everything

A Service finds pods by label. If the Service selects app=backend and the pods are labelled app=backend-api, the Service matches nothing, and no error is shown anywhere.

Check whether the Service has any endpoints:

kubectl get endpointslices -n <namespace> -l kubernetes.io/service-name=<service-name>

Then compare with the pod labels:

kubectl get pods -n <namespace> --show-labels

4. Then check the ports

Three port numbers must line up:

• Service port: the port clients call, for example 80.

• targetPort: the port the Service forwards to on the pod, for example 8080.

• containerPort: the port the application actually listens on.

If targetPort says 8080 but the app listens on 3000, every request fails.

Check what the app is really listening on inside the pod:

kubectl exec -n <namespace> <pod-name> -- ss -ltn

5. Readiness can remove a running pod from traffic

A failing readiness probe keeps the pod Running but takes it out of the Service. Check the events:

kubectl describe pod <pod-name> -n <namespace>

Look for "Readiness probe failed" near the bottom. Common causes:

• The probe calls the wrong path or port.

• The probe timeout is shorter than the app's response time.

• The app needs a database or cache that is not reachable yet.

6. If the Service works, move up the traffic path

Next stop is the Ingress or Gateway in front of the Service.

kubectl describe ingress <ingress-name> -n <namespace>

Check the host, the path, the backend Service name and port, and the ingressClassName. A typo in any of them sends traffic nowhere.

Then check the ingress controller logs for errors on your host:

kubectl logs -n ingress-nginx deploy/ingress-nginx-controller --tail=50

Adjust the namespace and deployment name if you use a different controller.

7. Test from inside the cluster

Cut the outside world out of the test. Call the Service directly from a temporary pod:

kubectl run curl-test --rm -it --image=curlimages/curl -n <namespace> -- curl -sv http://<service-name>:80/

• Works inside, fails outside: the problem is the Ingress, load balancer, DNS or firewall.

• Fails inside too: the problem is the Service, endpoints, ports or the app.

You can also bypass the Ingress from your laptop:

kubectl port-forward svc/<service-name> 8080:80 -n <namespace>

8. Don't forget NetworkPolicy

If a NetworkPolicy exists in the namespace, any traffic it does not allow is silently dropped.

kubectl get networkpolicy -n <namespace>

Make sure a policy allows traffic from the ingress controller's namespace to your pods on the right port.

9. Follow the traffic, not just the pod

When an app is unreachable, walk the path in order and stop at the first broken hop:

1. DNS: does the hostname resolve to your load balancer?

2. Load balancer: is it healthy and pointing at the ingress controller?

3. Ingress or Gateway: do the host, path and backend match?

4. Service: do the selector and ports match?

5. EndpointSlice: does it list ready pod IPs?

6. Pod readiness: is the pod 1/1?

7. Container port: is the app listening on the right port and on 0.0.0.0?

8. NetworkPolicy: is the traffic allowed?

The engineering takeaway

A Running pod is the start of the investigation, not the end. Most "Kubernetes is broken" incidents are a label, a port or a probe that drifted from what everyone assumed.

Teams that fix this for good add guardrails: consistent labels from templates, readiness probes that test the real dependency, and alerts on Services with no ready endpoints.

How Turf Dev can help

Turf Dev reviews Kubernetes platforms for exactly these silent failures: Service and Ingress configuration, probes, network policies and the alerting that should have caught them. If your team is losing hours to "it's running but nothing works", reach out at turfdev.in.