How do you debug a Pod stuck in ImagePullBackOff or Pending?

ImagePullBackOff — the kubelet can't pull the image

kubectl describe pod my-app-xyz
# Events:
#   Warning  Failed     kubelet  Failed to pull image "myapp:1.0.": rpc error: ...
#   Warning  BackOff    kubelet  Back-off pulling image "myapp:1.0."

Common causes, in rough order of frequency:

1. Typo in the image name or tag — a trailing period (as in the example above, myapp:1.0. instead of myapp:1.0), a misspelled repository name, or a tag that was never actually pushed. kubectl describe pod shows the exact image string the kubelet tried to pull, and the exact error the registry returned — often enough to spot the typo immediately.
2. Private registry requiring authentication — if the image is in a private registry and no credentials are configured, the pull fails with an authentication/authorization error. Fix by creating a docker-registry Secret and referencing it via imagePullSecrets in the Pod spec, or the associated ServiceAccount, so every Pod using that ServiceAccount picks it up automatically.

spec:
  imagePullSecrets:
    - name: my-registry-credentials
  containers:
    - name: app
      image: private-registry.example.com/myapp:1.0

1. Network connectivity issue — the node genuinely can't reach the registry: a firewall rule, a DNS resolution problem, the registry being down. Worth checking directly from a node or a debug Pod if credentials and image name both check out.
2. Rate limiting — some public registries, notably Docker Hub, impose pull rate limits per IP/account. A burst of Pod creations across many nodes can occasionally hit this, especially without an authenticated account configured for higher limits.

Pending — the scheduler can't place the Pod anywhere

kubectl describe pod my-app-xyz
# Events:
#   Warning  FailedScheduling  default-scheduler  0/5 nodes are available:
#     3 Insufficient memory, 2 node(s) had taint {dedicated: gpu}, that the pod didn't tolerate.

The Events section of describe pod is the essential first stop — it states, in plain language, exactly why every node was rejected during scheduling's filtering phase (see the scheduling question). Common reasons:

1. Insufficient resources — no node has enough unreserved CPU/memory to satisfy the Pod's requests. Either the cluster genuinely needs more capacity (Cluster Autoscaler should address this automatically if configured — see that question), or the Pod's requests are set unrealistically high.
2. Unsatisfied taints/tolerations or node affinity — the Pod requires something, like a specific node label or tolerance for a taint, that no current node provides.
3. Volume/topology issues — a PersistentVolumeClaim can't be bound or provisioned, for example a StorageClass misconfiguration, or a zone-topology mismatch between where the volume was created and where the Pod could be scheduled (see the StorageClass question).
4. PodDisruptionBudget or admission webhook rejection — less common for a purely Pending state, but worth checking if the Events mention an admission controller rejecting the request outright.

The universal first diagnostic command

kubectl describe pod <pod-name>

For both ImagePullBackOff and Pending, this single command's Events section is almost always where the actual, specific, human-readable reason lives. The general debugging instinct should always be "read the events before guessing," rather than jumping straight to speculation about what might be wrong.