SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
FixMyError.net
Kubernetes 34 errors

Kubernetes Errors

CrashLoopBackOff, ImagePullBackOff, OOMKilled, RBAC, scheduling and storage.

Understanding Kubernetes errors

Kubernetes errors are best read as a state machine that got stuck. Pending means the scheduler could not place the pod (resources, taints, or an unbound volume). ImagePullBackOff means kubelet could not fetch the image (name, credentials, or registry). CrashLoopBackOff means the container starts and exits, so the answer is in the container's own logs. OOMKilled means the kernel killed it for exceeding its memory limit. Each state points at a different subsystem, and kubectl describe almost always contains the exact reason in its events.

How to debug Kubernetes errors

  1. Start with kubectl describe pod <name> and read the Events section at the bottom. It names the precise failure, including registry errors and scheduling constraints.
  2. For CrashLoopBackOff, read the previous container's logs: kubectl logs <pod> --previous. The current container may not have produced output yet.
  3. Check resource pressure with kubectl top pod and kubectl top node, and compare against the pod's requests and limits.
  4. Test RBAC directly: kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<ns>:<sa>. This answers permission questions definitively.
  5. For networking, confirm the Service has endpoints (kubectl get endpoints) before suspecting DNS, Ingress or the CNI.

Tools worth reaching for

  • kubectl describe
  • kubectl logs --previous
  • kubectl auth can-i
  • kubectl top
  • kubectl events --sort-by=.lastTimestamp
  • k9s

All 34 Kubernetes errors

Other categories