Kubernetes pod failures: separate scheduling, startup and readiness

A pod that is not serving traffic may never have been scheduled, may be failing to start a container or may be running without becoming ready. Those states require different investigations. Begin with the correct cluster context and namespace so that every observation refers to the workload you intend to repair.

Build a small evidence set

Inspect the pod summary, describe the affected pod and read its recent events. Record the owning workload, image, container names, resource requests, limits and restart count. Kubernetes events are especially useful when the scheduler cannot place a pod because requests, placement constraints or available capacity do not match.

kubectl get pods -n NAMESPACE
kubectl describe pod POD -n NAMESPACE
kubectl logs POD -n NAMESPACE -c CONTAINER --tail=100
kubectl logs POD -n NAMESPACE -c CONTAINER --previous --tail=100

Replace the uppercase placeholders before running these read-only examples. Previous logs are relevant when the container has already restarted; they are not a substitute for inspecting its termination reason. Logs can contain private application data, so redact them before sharing a question publicly.

Follow the state to the next test

For Pending pods, read scheduling events and compare the requested resources with allocatable capacity and placement rules. Increasing a memory limit will not fix a node selector that matches no node. For image-pull failures, inspect the image reference and registry access rather than changing the application’s readiness endpoint.

For repeated restarts, examine the termination reason, exit code and previous container logs. A process that exits on bad configuration needs a configuration fix. A confirmed memory termination calls for a workload and memory investigation; raising limits without checking node capacity can move the failure elsewhere.

Treat readiness as a contract

A running container is not necessarily ready to receive traffic. Check the configured probe, port, path and response from the application’s network context. Decide which dependencies truly determine readiness and which failures the application should tolerate. Do not remove a failing probe merely to make the deployment appear green.

Change one well-supported cause through the workload controller’s configuration. Watch the rollout, new pod events and actual request behavior. If you use a diagnostic container or more privileged debug mechanism, follow your cluster’s access policy and clean it up afterward. The final evidence should show both a healthy workload and a functioning request path, with the original failure explained.