The deploy reports success, pods are Running, but users get 502s. Where do you look?

Question

Accepted Answer

A 502 means something proxied to my service and did not get a usable response, so I work the path from the outside in. Running is not ready, so first I check whether pods are passing readiness, because a pod can run happily while failing readiness and therefore never join the Service. Then I check the endpoints object directly: if it is empty, that is the answer, and the cause is either a label selector that does not match or every pod failing readiness. If endpoints look fine, I check ports, since a targetPort of 8080 against an app listening on 3000 gives exactly this, as does an app bound to 127.0.0.1 rather than 0.0.0.0, which works when you exec in and fails from outside. Then I port-forward straight to one pod and curl it: if that works, the problem is routing, if it does not, the problem is the app. That splits the search space in half in about 20 seconds.

Answer

Endpoints are populated and port-forward works. What is left?

The ingress controller or its config: wrong service name or port in the ingress, TLS mismatch, or an upstream timeout shorter than the app response time. Check controller logs.

Answer

Why would a 504 point somewhere different from a 502?

504 is a timeout, so upstream was reachable but too slow, pointing at application performance or a dependency. 502 is a bad or absent response, pointing at connectivity or the app failing immediately.

The deploy reports success, pods are Running, but users get 502s. Where do you look?

The deploy reports success, pods are Running, but users get 502s. Where do you look?

The follow-ups they ask next

What the interviewer is listening for

What sinks the answer

If you genuinely do not know

Keep going with troubleshooting

Knowing the answer is not the same as recalling it under pressure