## TL;DR
Exit code 137 is 128 plus SIGKILL. Check the container's last termination reason: OOMKilled means your container crossed its memory limit (fix the limit or the leak), while a pod-level Evicted status means the node ran out of memory (fix node capacity or pod priority).

## Verbatim error
```text
State:          Terminated
  Reason:       OOMKilled
  Exit Code:    137
```

## Steps
1. Read the termination state of the dead container.
```bash
kubectl get pod [POD] -n [NAMESPACE] -o yaml
```
Expected: in lastState.terminated you see either Reason OOMKilled with Exit Code 137 (container killed for exceeding its limit) or the pod itself in phase Failed with reason Evicted (node-pressure eviction). This one field decides the whole fix.

2. If the reason is OOMKilled, compare the limit against actual usage.
```bash
kubectl top pod [POD] -n [NAMESPACE]
kubectl describe pod [POD] -n [NAMESPACE]
```
Expected: describe shows the memory limit; top shows usage near or above it just before death. If there is no limit set, the container used enough to trigger the node's OOM killer anyway.

3. Fix an OOMKilled container: raise the memory limit if the usage is legitimate, or fix the leak if usage grows without bound.
```bash
kubectl -n [NAMESPACE] edit deployment [WORKLOAD]
```
Expected: after raising limits under resources, the new pods survive the same workload. For a leak, take a heap dump or profile before raising limits blindly; bigger limits just delay the next kill.

4. If the pod was Evicted instead, check node memory pressure at the time.
```bash
kubectl describe node [NODE]
kubectl get events -A --field-selector reason=Evicted
```
Expected: the node shows MemoryPressure in its conditions around the eviction time, and the event names the pod. Eviction picks pods by priority and by how far usage exceeds requests.

5. Fix eviction risk: set realistic memory requests so the scheduler places pods honestly, add a priorityClassName to workloads that must survive, and make sure the node pool has headroom.
```bash
kubectl get priorityclass
```
Expected: your critical workloads carry a PriorityClass above best-effort. Without priority, any burstable pod is eviction fodder when the node fills up.

## When to use
- A container terminates with exit code 137
- You need to know whether to raise a limit or add node capacity
- The 137s started after a deploy changed memory limits or traffic grew

## When not to use
- Exit code 143 (that is SIGTERM, usually a graceful shutdown or liveness probe kill)
- The pod is in CrashLoopBackOff with exit code 1; that is an app error, not memory
- kubectl logs shows nothing because the pod was evicted; check events, not logs

## Why it happens
The kernel OOM killer sends SIGKILL when memory accounting says something must die: either the container's cgroup exceeded its limit (OOMKilled), or the whole node ran out and the kubelet evicted pods to relieve pressure (Evicted). Both surface as 137 because SIGKILL cannot be caught; only the termination reason tells them apart.

## Edge cases
- No memory limit plus a memory leak: the container grows until the node OOM killer picks it; it looks like a node problem but the fix is in the app.
- Init containers share the pod's fate but have their own limits; check their lastState too.
- JVM and similar runtimes need heap settings below the container limit; the runtime happily allocates past the heap into native memory and gets OOMKilled.
- Swap enabled on the node delays eviction but slows pods first; check node swap settings if eviction timing looks off.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_CrGfnxyIFjpaLBNPbnqicw