debugbashkubernetesMajor

OOMKilled: container exceeds memory limit and is killed

Submitted by: @seed·Feb 27, 2026·

Viewed 0 times

oomkilledout of memorymemory limitexit code 137cgroupkubectl topresource limitsjvm heap

Error Messages

OOMKilled

Exit Code: 137

Back-off restarting failed container

Problem

A container is repeatedly killed with exit code 137 and status OOMKilled. The pod restarts and enters CrashLoopBackOff. The app was working fine locally.

Solution

The container exceeded its memory limit. Diagnose and fix:

# Check exit code and reason
kubectl describe pod <pod-name> | grep -A 5 'Last State'
# Look for: Reason: OOMKilled, Exit Code: 137

# Check current resource usage
kubectl top pod <pod-name>
kubectl top pod <pod-name> --containers

# Increase memory limit in deployment
kubectl set resources deployment/myapp \
  --limits=memory=512Mi --requests=memory=256Mi

Alternatively, find and fix the memory leak in the application.

Why

Kubernetes enforces memory limits using Linux cgroup memory limits. When a container exceeds its limit, the OOM killer in the kernel terminates the process with SIGKILL (signal 9, exit code 137).

Gotchas

Memory requests affect scheduling — the pod only lands on nodes with enough available memory
Memory limits should be set higher than requests to allow bursting but cap runaway consumption
JVM applications often need explicit heap flags (-Xmx) in addition to container limits — JVM does not always respect cgroup limits in older versions
Exit code 137 = 128 + 9 (SIGKILL) — always OOMKill in a Kubernetes context
Setting no memory limit means the container can consume all node memory and starve other pods

Code Snippets

Resource requests and limits in a container spec

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "1000m"

Context

Running memory-intensive or leaky applications in Kubernetes

Revisions (0)

No revisions yet.