A Kubernetes troubleshooting path that follows the request

Start with one failing request

“The application is down” is a starting observation, not a diagnosis. Record one failing request, its time, the expected response and where it was made. A request from inside the cluster and a request from a user’s browser follow different paths.

Choose the smallest useful scope: one application, one namespace and one service. Before running commands, verify that the current Kubernetes context points to the intended cluster. The commands below are read-only examples; replace the example namespace and object names with resources you are authorized to inspect.

kubectl config current-context
kubectl get pods -n example-app -o wide

Keep the original symptom visible while investigating. A list of running Pods does not by itself establish that the application can serve a request.

Inspect the Pod before changing it

kubectl describe pod example-pod -n example-app
kubectl logs example-pod -n example-app -c app --tail=100
kubectl logs example-pod -n example-app -c app --previous --tail=100

Replace app with the container name. The previous-log command is useful only when a previous container instance exists; it may otherwise return an error. Read container state, recent events and relevant logs together. Kubernetes documents this inspection path in Debug Pods.

Separate failure to schedule, failure to start and failure after startup. Those lead to different investigations. Do not discard the initial evidence by immediately deleting a Pod. Even when restarting is an appropriate recovery action, capture enough context first to explain what it changed.

Check the path through the Service

kubectl get service example-service -n example-app
kubectl get endpointslices -n example-app   -l kubernetes.io/service-name=example-service

A Service is not evidence that usable application endpoints exist. Compare its selector and ports with the intended Pods and inspect the EndpointSlice addresses and conditions. The Kubernetes debugging guide includes EndpointSlice inspection for this purpose.

If the service path works from an approved internal test location but the public request fails, continue outward through the relevant ingress, load balancer and DNS configuration. Make one comparison at a time so the result narrows the problem instead of creating another unrelated observation.

Turn the investigation into a reusable exercise

A small lab is useful for learning these distinctions. Start with a known working application, change one selector in a disposable environment, and ask a learner to identify where the request path breaks. Restore the original configuration and repeat the same request to demonstrate recovery.

The exercise is successful when someone can explain why the evidence points to a layer, not merely repeat a command. Ask them to write four short lines: symptom, observation, suspected cause and verification.

This also improves operational handovers. A colleague should be able to understand what was inspected, which hypotheses remain open and what would justify the next action. The application troubleshooting collection provides further paths for more specific failures.