← Problem Library
K8s L4 K8S 1194 · 20 min

kubectl exec works but the in-cluster service call still times out because the NetworkPolicy path is narrower than expected

Direct debugging into a pod succeeds, yet service-to-service traffic still fails because the effective policy only allows a subset of the intended path.

K8sPlatform ReliabilityLevel 4Pro20 min
Scenario

A public policy example was adapted to production. Debug access into the pod works, but normal service calls still time out because the policy does not allow the actual source path.

What to check first
  • Identify the primary failure signal in the Policy Path Debug scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Compare the debug path with the real service path before relaxing the entire policy.

Questions worth viewing together
What should you verify first when kubectl exec works but the in-cluster service call still times out appears?

Community-derived Kubernetes connectivity problem based on Reddit and Stack Overflow threads where NetworkPolicy blocked service traffic despite success... A successful kubectl exec test does not prove peer-to-peer network policy is open.

What usually causes kubectl exec works but the in-cluster service call still times out in production?

Teams often treat this like a DNS or app bug because an interactive shell test succeeds.

What should you document after resolving kubectl exec works but the in-cluster service call still times out?

NetworkPolicy validates source and direction; manual pod access proves less than teams assume.