Resource Requests, Limits and OOMKilled

Configuration and Security / Guide 26 of 44 / Intermediate

• Kubernetes1.36.4
• Cluster4 nodes
• Runtimecontainerd 2.2.6
• CNICalico v3.32.1
• TimeAbout 16 min

Exit code 137 is 128 + 9, meaning the process was killed by SIGKILL. The kernel's OOM killer sends it and the kubelet reports OOMKilled. A container with restartPolicy: Always would restart and eventually reach CrashLoopBackOff with OOMKilled as the last state - the reason people see the loop and miss the cause.

This guide includes

Use this when a container is being killed or throttled and you have to say which. This matters because requests are what the scheduler reserves and limits are what the kernel enforces - memory kills the process, CPU only slows it down.

• running three Pods and reading the three QoS classes Kubernetes derives from them
• confirming what the scheduler actually reserved against the node's own accounting
• hitting a memory limit and reading exit 137, which is 128 plus SIGKILL
• hitting a CPU limit and finding that it throttles rather than kills

Before you start

• A cluster and kubectl.
• The session creates namespace ckad-lim with three Pods of different QoS classes, one that deliberately exhausts a 32Mi memory limit, and one that spins against a CPU limit.

1. 1

   Three Pods, three QoS classes

2. 2

   What the scheduler actually reserved

3. 3

   The limit that kills

4. 4

   The limit that only slows you down

Official sources

• Resource Management for Pods and Containers
• Quality of Service for Pods
• Assign Memory Resources