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

A Kubernetes pod showing Running looks reassuring.

The container started. Kubernetes isn't reporting a crash. The Deployment may even show all replicas as available.

But users still can't reach the application.

This is one of those Kubernetes problems where everything appears healthy at first glance:

🟢 Pod — Running

🟢 Deployment — Available

🟢 Service — Active

🔴 Application — Not Reachable

So the real question becomes:

🔍 If the pod is running, where is the traffic actually getting lost?

🔍 Running Doesn't Mean Ready to Receive Traffic

The first thing to understand is that Running only describes the pod's current lifecycle state.

We started by checking the application pods:

kubectl get pods -n <namespace> -o wide

A pod might show:

NAME READY STATUS RESTARTS
backend-7d8f9c6b5-x2k9p 1/1 Running 0

That tells us the container is running.

It doesn't prove that the entire traffic path is working.

A typical Kubernetes request may travel through several components:

User → Load Balancer → Ingress/Gateway → Service → Pod

A failure at any point in that path can make the application unreachable even while the pod itself remains perfectly healthy.

💡 Pod health and application reachability are two different things.

📡 We Checked the Service Next

Once the pod looked healthy, the next step was to check whether the Kubernetes Service could actually discover it.

kubectl get svc -n <namespace>

Then we checked the Service in more detail:

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

The important thing here isn't simply whether the Service exists.

We need to know whether it has the correct endpoints behind it.

kubectl get endpoints <service-name> -n <namespace>

If the output shows:

ENDPOINTS
<none>

we have found an important clue.

The Service exists, but it currently has no backend pods receiving traffic.

🎯 The Small Label Mismatch That Can Break Everything

One of the first things to compare is the Service selector and the labels on the application pods.

Imagine the Deployment creates pods with:

metadata:
labels:
app: backend

But the Service is configured with:

selector:
app: backend-api

Those values don't match.

The pods can still be:

🟢 Running

🟢 Ready

🟢 Healthy

But the Service won't select them.

The result looks like this:

Service

↓

Selector: app=backend-api

↓

❌ No Matching Pods

↓

🔴 No Endpoints

↓

🔴 No Application Traffic

A very small configuration mismatch can therefore break the entire request path.

🔌 Then We Checked the Ports

Having endpoints isn't enough either.

The Service must forward traffic to the port where the application is actually listening.

For example:

ports:
- port: 80
targetPort: 8080

This means the Service accepts traffic on port 80 and forwards it to port 8080 inside the selected pods.

If the application is actually listening on:

3000

instead of:

8080

the Service can have valid endpoints and the pod can remain Running, but requests can still fail.

So we verify both sides:

Service targetPort

and

Application listening port

Inside the pod, depending on the container image and available tools, we can also verify the listening sockets.

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

The goal is simple:

⚙️ Make sure Kubernetes is sending traffic to the same port where the application is actually listening.

❤️ Readiness Can Remove a Running Pod From Traffic

There is another important layer: the readiness probe.

A container can be running while Kubernetes considers the application not ready to receive traffic.

For example:

readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10

Now imagine the application responds correctly on:

/healthz

but the readiness probe checks:

/health

The application process may be running normally, but the readiness check can continue failing.

Check it with:

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

You may see events related to the readiness probe.

This distinction is important:

Running → The container process is running.

Ready → Kubernetes considers the pod ready to receive Service traffic.

A pod can therefore be:

🟢 Running

but

🔴 Not Ready

⚠️ When troubleshooting traffic, always check the READY column — not only STATUS.

🌐 If the Service Works, Move Up the Traffic Path

Suppose the Service has valid endpoints.

The ports are correct.

The pods are Ready.

But external users still can't reach the application.

Now the investigation moves one layer higher.

Check the Ingress:

kubectl get ingress -n <namespace>

Then:

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

If you're using Gateway API, check the relevant Gateway and HTTPRoute resources instead.

At this point we're looking for issues such as:

⚠️ Incorrect hostname

⚠️ Wrong backend Service

⚠️ Incorrect Service port

⚠️ Route not attached

⚠️ TLS configuration problems

⚠️ Ingress/Gateway controller errors

The important principle is to troubleshoot one hop at a time.

🧪 Test From Inside the Cluster

External access involves DNS, load balancers, ingress controllers, certificates and other infrastructure.

Before investigating all of those layers, it helps to answer a simpler question:

Can the application be reached from inside Kubernetes?

A temporary test pod can be useful:

kubectl run curl-test \
--image=curlimages/curl \
--rm -it \
--restart=Never \
-- sh

From there, test the Service:

curl http://<service-name>.<namespace>.svc.cluster.local

If this works:

🟢 Pod is responding

🟢 Service routing is working

🟢 Internal Kubernetes networking is working for that path

The problem is likely further upstream.

If it doesn't work, continue investigating the Service, endpoints, ports, readiness and network policies before focusing on external ingress.

💡 Testing from inside the cluster helps divide one large traffic problem into smaller, easier problems.

🔒 Don't Forget NetworkPolicy

Sometimes everything looks correct:

🟢 Pod Running

🟢 Pod Ready

🟢 Service has endpoints

🟢 Ports match

But communication is still blocked.

If the cluster uses Kubernetes NetworkPolicy or another network-policy implementation, check whether traffic is actually permitted.

kubectl get networkpolicy -n <namespace>

A restrictive policy can allow the application to run normally while preventing traffic from reaching it from another workload or ingress component.

So the problem isn't always the application.

Sometimes the network is doing exactly what it was configured to do.

🔄 Follow the Traffic, Not Just the Pod

When an application isn't reachable, repeatedly checking:

kubectl get pods

only tells part of the story.

Instead, follow the complete request path.

👤 User

↓

🌐 DNS / Load Balancer

↓

🚪 Ingress or Gateway

↓

📡 Kubernetes Service

↓

🎯 Service Endpoints

↓

📦 Ready Pod

↓

⚙️ Application Process

At each step, ask one question:

Can traffic successfully reach the next component?

This approach usually narrows the problem much faster than randomly restarting pods or changing infrastructure.

💡 The Engineering Takeaway

A Kubernetes pod showing Running is only the beginning of the investigation.

When the application still isn't receiving traffic, check:

🔍 Is the pod actually Ready?

🎯 Does the Service selector match the pod labels?

📡 Does the Service have endpoints?

🔌 Does targetPort match the application's listening port?

❤️ Is the readiness probe succeeding?

🚪 Is the Ingress or Gateway routing to the correct Service?

🔒 Is a NetworkPolicy blocking the traffic?

🌐 Does the application work from inside the cluster?

Don't start by restarting everything.

Start with the request path.

🚀 User → Gateway → Service → Endpoint → Pod → Application

A Running pod tells you the container started. It doesn't tell you that traffic can reach it.