A Kubernetes container is Running, but the Service sends it no traffic

An example pod’s process remains running, but its readiness probe fails. The application listens on a different port from the one configured in the probe. The team proposes removing readiness checks to restore traffic. How should the mismatch be handled?

Compare the application’s actual listener with the probe’s configured port, path and protocol. Confirm the intended readiness contract, then correct the mismatch in the controller-managed configuration. Running describes process state; readiness determines whether the workload should receive traffic through the relevant service path.

Removing the probe can make an unhealthy or unreachable process appear eligible for traffic. Instead, validate the corrected probe and a representative request. Check startup timing and dependencies separately if the application still does not become ready.

Could a 200 from an unrelated health endpoint hide a broken dependency?

Yes. Define what readiness must guarantee for this application. A trivial endpoint proves only what it checks; make that limitation explicit.

Review Service target ports and selectors after the pod becomes ready if traffic still fails. A correct readiness probe does not prove the complete routing configuration.

A Kubernetes container is Running, but the Service sends it no traffic

Sources & further reading

2 answers

Your perspective belongs here.

0 question comments