The Kubernetes Pod Keeps Restarting

Step 1 — Understand the symptoms

CrashLoopBackOff means Kubernetes is repeatedly starting a container, watching it exit, and backing off before trying again — it's a description of the restart behavior, not a diagnosis of why the container is exiting. A container can enter this state for reasons that have nothing to do with CPU or memory: a missing config file, a bad environment variable, a failed connection to a dependency on startup, an application crash on a specific input, or actual resource exhaustion. "Increase the resources" is only the right fix for the last of those.

Step 2 — Identify the likely bottleneck

The fastest way to stop guessing is to ask Kubernetes what it already knows. kubectl describe pod and the previous container's logs will very often state the reason directly rather than leaving it a mystery:

kubectl describe pod <pod-name>

Check the Last State section for a Reason — OOMKilled specifically means the container was killed for exceeding its memory limit, which is the one case where "increase memory" is genuinely the right first move. Any other reason — a non-zero exit code from an application error, a failed liveness probe, an image pull failure — points somewhere else entirely, and more resources won't fix it.

Step 3 — Investigation

kubectl logs <pod-name> --previous

This is the single most useful command here — it shows the logs from the last crashed container instance, which usually includes the actual application error right before it died: a stack trace, a failed connection message, a config-parsing error.

From there:

• Exit code — describe pod shows this too. 137 typically means OOMKilled or a SIGKILL; other codes point at an application-level failure.
• Configuration and secrets — did a recent change to a ConfigMap or Secret this pod depends on introduce a bad or missing value?
• Environment variables — a missing or malformed one is one of the most common causes of an application crashing immediately on startup.
• Probes — is a liveness probe killing the container before it's finished starting up, misreading a slow boot as a hang?
• Dependencies — does the application fail fast if it can't reach a database or another service on startup, and is that dependency actually available?

Step 4 — Recommended action

Only increase resources if the evidence actually points there — OOMKilled in the Last State, or memory usage climbing toward the limit in metrics right before each crash. Otherwise, fix the actual cause the logs and describe output point to: correct the bad config, fix the environment variable, adjust a probe that's too aggressive, or address the dependency the application can't reach.

Increasing resources without evidence has a real cost beyond wasted effort — it can mask the actual problem for a while (more memory headroom might delay but not prevent a memory leak from eventually crashing the pod again) while also increasing cluster cost for no real benefit, and it burns time that a two-minute log check would have saved.

Step 5 — Engineering lesson

CrashLoopBackOff is Kubernetes accurately describing a symptom — the container keeps dying — not diagnosing a cause. kubectl describe and --previous logs exist specifically to turn that symptom into an actual reason, almost always in under a minute. Reaching for more resources before checking those two things is treating a guess as a diagnosis.