A container shows Reason OOMKilled and Exit Code 137 — explain it and fix it.
A container keeps restarting; its last state is OOMKilled with exit code 137. Explain exactly what happened, then give the fix — and contrast it with what a too-low CPU limit would do instead.
$ kubectl describe pod cache-2
Last State: Terminated
Reason: OOMKilled
Exit Code: 137
Limits:
memory: 128Mi
Restart Count: 7Diagnose and fix.
Exit 137 is 128 + 9 (SIGKILL), and Reason OOMKilled means the cgroup killed the container for exceeding its memory limit (128Mi). Raise the limit to the real working set, or fix the leak. A too-low CPU limit only throttles — it never kills, so no exit 137.
- ✗Reading exit 137 as anything other than a SIGKILL (128 + 9)
- ✗Confusing a memory-limit OOM kill with CPU throttling
- ✗Raising the limit blindly instead of also checking for a leak
- →How do
requestsandlimitsfor memory drive a Pod's QoS class and eviction order? - →Why does a memory limit hard-kill while a CPU limit only throttles?
Solution
1. What happened
Reason: OOMKilled Exit Code: 137 Limits: memory 128Mi137 = 128 + signal 9 (SIGKILL). OOMKilled means the kernel memory cgroup killed the process when its RSS crossed the 128Mi limit. This is not a graceful stop — it is a SIGKILL, with no chance to shut down cleanly.
2. Fix
with metrics / kubectl top) and set requests.memory to match;
- if 128Mi is simply too small → raise
limits.memoryto the real working set (measure - if it grows without bound → it is a leak/over-allocation; fix the application.
3. Contrast with CPU
A too-low CPU limit does not kill: the cgroup merely throttles the process (it gets less CPU time and runs slower). No OOMKilled, no exit 137 — if you see 137, it is memory, not CPU.
