Troubleshooting Pods

Let's think about it this way for a second

There are several pod statuses to know — Pending (the scheduler hasn't found a node yet, or the image is still being pulled), CrashLoopBackOff (the container keeps crashing and restarting over and over), ImagePullBackOff (the image can't be downloaded from the registry). `kubectl describe pod` shows the event log, giving you context on what's happening. `kubectl logs` lets you see the container's stdout/stderr output, which helps you find application-level errors (code exceptions, missing config). `kubectl exec -it <pod> -- /bin/sh` lets you go directly into the pod for interactive debugging (though if the container only runs briefly before crashing, you might not be able to exec into it at all).

Let's connect this to a real scenario

When you run into CrashLoopBackOff, the first thing to check is `kubectl logs <pod-name> --previous` (the log of the container that crashed) — it should point to error messages like bad config, connection errors, or a port already in use. For ImagePullBackOff, you can usually find things like an image name typo or a registry authentication error in the Event section of `kubectl describe pod`.

kubectl describe pod = check the event log (to find scheduling/pulling issues)
kubectl logs [--previous] = check the container's output/error messages
kubectl exec -it -- /bin/sh = go directly into the pod for interactive debugging

Let's look at it together

bash

# See why a pod isn't starting
kubectl describe pod <pod-name>

# See its logs
kubectl logs <pod-name>

# See logs from a crashed container's previous run
kubectl logs <pod-name> --previous

# Get an interactive shell inside a running pod
kubectl exec -it <pod-name> -- /bin/sh

# Watch pod status change in real time
kubectl get pods --watch

You should see

Events:
  Type     Reason     Age   From     Message
  ----     ------     ----  ----     -------
  Warning  Failed     10s   kubelet  Failed to pull image "my-app:v99": not found

5-Minute Try-It

Create a Pod with a deliberately wrong image name (like `image: my-app:does-not-exist`) — use `kubectl describe pod` to track down the ImagePullBackOff error.

A Quick Word of Caution

Manually patching a file/config inside a live production container via `kubectl exec` is only a temporary fix — since the pod gets recreated eventually (rolling update, crash) and wipes everything out, you still need to fix the root cause at the YAML/code level.