Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Trace one request across every boundary—client or load balancer, Ingress controller, Service, EndpointSlice address, Pod, and the application’s dependencies. Send the same request externally, through the Service DNS name, and directly to a Pod. The first boundary where latency or failure appears is where to investigate; “Running” and “Ready” status alone cannot identify it.
Begin with three identical requests
Choose one URL, method, and payload that reliably stalls. Measure it three ways so that you change only the network boundary:
- External path: call the public hostname through the load balancer and Ingress.
- Service path: from a diagnostic shell inside the cluster, call the Service DNS name and port.
- Pod path: call the same listener directly on a selected Pod IP and port.
A failure only on the external path points toward the load balancer, Ingress route, firewall, or edge health check. A successful external request but a stalled Service request moves the investigation to DNS, EndpointSlices, kube-proxy, network policy, or the CNI. If the direct Pod request is also slow, the platform may be routing correctly and the application or one of its dependencies is the bottleneck. Record elapsed time, HTTP status, and whether the symptom is a timeout, connection refusal, error response, or slow success.
Free tools Windows power users keep installed
One-click scans. No signup required.
Check Ingress and edge routing first
Inspect the route and its events
Start with the Ingress object and verify that its host, path, TLS settings, and backend reference match the request you are sending. Events often reveal an invalid class, rejected annotation, missing Service, or configuration error that Pod status cannot show. Every Service named by the Ingress must exist in the same namespace expected by the route.
#1 Best Overall
kubectl describe ingress <name> -n <namespace>
kubectl get svc <service> -n <namespace>Read the controller’s evidence
Look at the Ingress controller logs at the time of a test request, then inspect the controller’s generated configuration using the mechanism documented for that controller. Compare the requested host and path with the rendered upstream and backend. A route can be syntactically valid while sending traffic to the wrong Service, port, or protocol. The controller’s own error or upstream timing is more useful than an aggregate “all Pods are healthy” view.
kubectl logs -n <ingress-namespace> <ingress-controller-pod>Verify Service discovery and EndpointSlices
Prove the name resolves
From a shell running in the cluster, resolve the exact Service DNS name used by the client. A failed lookup or an unexpected address is a DNS or naming problem, not an application timeout. Make sure the caller is in the namespace you assumed; an unqualified name resolves differently across namespaces.
Check the routing truth
EndpointSlices show which addresses a Service can actually use. Inspect them rather than inferring routing from a Deployment’s replica count. Confirm that the expected addresses exist and that their conditions indicate readiness. If the list is empty or missing a Pod, compare the Service selector with the labels on the Pods:
kubectl get endpointslices -l kubernetes.io/service-name=<service> -n <namespace>
kubectl get pods --show-labels -n <namespace>A selector typo, namespace mismatch, or readiness condition can exclude every Pod while the Deployment remains apparently healthy. Kubernetes troubleshooting specifically identifies selectors, missing endpoints, DNS, and kube-proxy as causes of a Service that fails despite healthy-looking Pods.
Follow every port mapping
Identify the real listener
Write down the port on which the process is listening, the container’s declared port, the Service’s targetPort, the Service port exposed to callers, and the Ingress backend port. Numbers must resolve to the same listener. Named ports must also match exactly; a name that exists in one object but not another can produce an unusable backend.
A containerPort declaration does not make a process listen there, and it does not automatically change a Service’s targetPort. Test the process inside the Pod or inspect its startup configuration if the direct Pod request refuses the connection.
Rank #3
Separate readiness from liveness
Readiness controls traffic eligibility
Kubernetes states: “If the readiness probe fails, the pod will be marked unready and will not receive traffic from any services.” Examine the readiness probe’s path, scheme, port, timeout, and recent events. A probe may be checking a different port or URL from the one your client uses, or it may fail while the process is still accepting some connections.
Liveness controls restart behavior
Liveness is primarily a restart signal. A passing liveness probe does not make a Pod eligible for Service traffic. Conversely, an overly aggressive liveness probe can repeatedly restart a busy process and make latency appear intermittent. Inspect the Pod description and events alongside the probe definitions:
kubectl describe pod <pod> -n <namespace>The Kubernetes Pod Lifecycle documentation distinguishes the checks this way: “The liveness probe passes when the app itself is healthy, but the readiness probe additionally checks that each required back-end service is available.”
Align external health checks (GKE)
On Google Kubernetes Engine, compare the readiness probe port, containerPort, Service targetPort, and the Ingress backend Service port. They must all identify the port that actually serves the request. A mismatch can make the external load balancer mark the backend unhealthy even though the process is running and a direct Pod call works. Treat this as an edge-to-Service alignment problem, not proof that the application is down.
Investigate node and network forwarding
When Pod calls work but Service calls stall
After confirming EndpointSlices and ports, examine cluster DNS responses, kube-proxy programming, network policies, CNI behavior, and node-level packet or conntrack symptoms. A Service request that hangs while the same Pod IP responds indicates a forwarding or policy boundary. Compare Pods on different nodes or zones to determine whether the scope follows one node, one zone, or the entire Service.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteWhen Service calls work but external calls stall
Stay at the load-balancer and Ingress layer. Check Ingress events and controller logs, the rendered backend configuration, firewall rules, TLS or host matching, and the external health-check result. Do not spend time changing application probes until an internal Service request demonstrates an application-path problem.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Use a diagnostic shell for controlled tests
Run a temporary shell in the cluster, subject to your image policy and security controls. From it, resolve the Service name and issue a verbose request to the Service port. Repeat the request several times so that one slow endpoint does not look like a general failure.
kubectl run netshoot --rm -it --image=nicolaka/netshoot -- sh
# from the diagnostic shell:
nslookup <service>
curl -v http://<service>:<port>/...Adapt the image, namespace, protocol, and URL to your environment. If the image cannot be pulled or interactive Pods are prohibited, use an approved diagnostic workload instead; that restriction is unrelated to the request path itself.
When the Pod is the slow boundary
If direct Pod requests reproduce the stall, move above Kubernetes routing. Correlate request timestamps with application logs and inspect:
- Thread, worker, and connection-pool exhaustion.
- CPU throttling, memory pressure, garbage-collection pauses, and container restarts.
- Request queues and lock contention.
- Latency or connection limits in databases, caches, and downstream APIs.
- Whether only one Pod, node, zone, route, or request type is affected.
These checks are application-specific: Kubernetes health signals establish that a process is running and, when ready, eligible for traffic, but they do not guarantee that every dependency can serve a request quickly.
Match the symptom to the boundary
| Observed symptom | Most likely boundary | Evidence to collect | Next action |
|---|---|---|---|
| Public request times out; Service request succeeds | Load balancer or Ingress | Ingress events, controller logs, rendered backend, firewall and health-check status | Fix host/path, backend port, TLS, firewall, or edge health alignment |
| Service DNS fails or returns no usable addresses | DNS, selector, readiness, or EndpointSlice | DNS lookup, Service selector, EndpointSlice conditions | Correct naming or labels and resolve excluded endpoints |
| Service request stalls; direct Pod request succeeds | Service forwarding or policy | EndpointSlices, kube-proxy, CNI, network policy, node packet and conntrack data | Narrow by node or zone and repair the forwarding path |
| Direct Pod request is refused | Process or port mapping | Listener configuration, probe and port declarations, Pod events | Make the process and all port fields identify the same listener |
| Direct Pod request is slow but succeeds | Application or dependency | Application timing, resource metrics, queues, downstream latency | Relieve saturation or repair the slow dependency |
A practical stopping rule
Stop moving outward once two adjacent tests agree on the boundary: external versus Service, Service versus Pod, or Pod versus application dependency. Preserve the exact request, timestamp, endpoint address, response code, and latency for that boundary. This evidence lets the team fix the failing hop without repeatedly changing probes, selectors, or workloads that are already behaving correctly.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
