OOMKilled and Exit Code 137: Limit, Leak or Spike?

What the kernel did

You give a container a memory limit. When it uses more, the kernel kills it immediately, with no chance to clean up, and Kubernetes records Reason: OOMKilled, normally with Exit Code: 137. On its own, 137 only says the process was killed by a signal; the reason is what confirms memory.

bash

kubectl describe pod POD | grep -A5 'Last State'

Three shapes, three answers

Sample usage several times over a few minutes:

bash

kubectl top pod POD --containers

Reading the memory curve

1. Flat, near the limit. The workload simply needs more than it was given.

1 / 6

For the first case, watch a normal cycle first, including startup. Then raise the limit above the peak you saw, using your own numbers in place of these:

bash

kubectl set resources deployment NAME --limits=memory=512Mi --requests=memory=256Mi

When it is not the container's fault

Occasionally the node itself runs short of memory, and the kernel picks a victim, starting with pods that set no requests (the memory a pod tells the scheduler it needs) or that use far more than they asked for. Look for a SystemOOM warning on the node:

bash

kubectl describe node NODE

The fix there is accurate requests, so the scheduler stops packing more onto the node than it can hold.

The full page is OOMKilled (exit code 137). If the kills show up as a restart loop, CrashLoopBackOff explains the loop, and the exit code explainer decodes 137 and the others.