What is OOMKilled Errors?

When memory cannot be allocated, the Linux kernel may terminate a process with SIGKILL. If the container's main process is killed, the container commonly exits with code 137, although exit code 137 by itself is not proof of an OOM kill. Kubernetes memory limits are enforced reactively: a container may temporarily exceed its configured limit and may be killed when the kernel detects memory pressure.

Kubernetes then restarts the container according to its restart policy. If memory pressure recurs quickly the container can enter CrashLoopBackOff, with restarts spaced by an increasing delay. The Pod status shows OOMKilled as the last termination reason, which is where diagnosis normally starts.

OOM kills tend to come from a small number of recurring situations.

• Limits set too low: the limit was estimated rather than derived from observed usage.
• Memory leaks: usage grows steadily until the limit is reached, then repeats after restart.
• Load-dependent allocation: per-request memory scales with traffic or payload size beyond what was provisioned.
• Runtime heap misconfiguration: a JVM or similar runtime configured with a heap that leaves too little room for the rest of the process footprint.
• Node memory exhaustion: the node runs out-of-memory and the kernel selects a process regardless of that container's own limit.

Memory-usage patterns provide clues, not definitive diagnoses. Steady growth across comparable load can suggest a leak; sharp increases correlated with traffic can suggest load-dependent allocation; and repeated kills near a configured limit can suggest insufficient headroom. Confirm the cause with runtime metrics, allocation or heap profiles, workload data, cgroup limits, and node-memory conditions.

Raising the limit can be appropriate when measured peak usage and expected workload justify more memory. It is not a substitute for investigating leaks, unbounded allocation, node overcommitment, or workload behavior.

An OOM kill and a Kubernetes eviction are different mechanisms. A container can be OOM-killed after exceeding its own cgroup limit, or when the node itself reaches OOM before the kubelet can reclaim enough memory. In a node-level OOM, the kernel selects a process using its OOM scoring.

A node-pressure eviction is initiated proactively by the kubelet to reclaim resources. The kubelet ranks Pods using factors including usage relative to requests and Pod priority. Do not infer "container limit problem" from OOMKilled or "well-behaved but unlucky Pod" from eviction without checking node pressure, requests, limits, QoS, priority, and actual usage.