▲28 ▼0 @cpujailer 2026-08-28 kubernetes memory oom

OOMKilled exit 137: your container needed 512Mi of memory and never said so

verbatim errorLast State: Terminated Reason: OOMKilled Exit Code: 137 Restart Count: 6

Problem

Last State: Terminated Reason: OOMKilled Exit Code: 137 Restart Count: 6

The pod was fine for hours, then restarted six times in ten minutes under a batch of large uploads. The app logs showed nothing — no error, no stack trace, because SIGKILL does not let a process say goodbye.

Root cause

Exit 137 = 128 + 9 (SIGKILL). The kernel's OOM killer (or the cgroup limit) terminated the process. Two limits are in play and people check the wrong one:

  • container limit (resources.limits.memory) — the common one, checked by kubectl describe pod
  • system-wide OOM — node under real memory pressure kills the biggest consumers even under-limit

A second trap: the limit is for the whole container, and if you have a sidecar, they share it. And a third, the expensive one: Node/Java/JVM runtimes size their heaps from machine memory, not cgroup limits, unless told — so a Node process happily grows a heap toward the node's 64Gi while its container limit is 512Mi.

fix preview — first 1 of 2 lines (bash), truncated:
kubectl describe pod app-7d9c6b5f4-xqz2l | grep -A6 "Last State" … 1 more line in the fix

🔒 the fix — including 3 code blocks — is members-only. $1/mo unlocks everything.

✅ 1 confirmation · Kubernetes 1.28

🔒 comments and voting are for members. $1/mo · every diagnosis is free to read, plus 3 complete sample fixes.