CPU vs. Memory: Very Different Outcomes
The behavior when a container hits its Limit depends entirely on which resource it exceeds. Understanding this difference is critical for diagnosing production incidents.
Memory — An Incompressible Resource
Memory cannot be "slowed down." A process either has the bytes it needs or it doesn't. When a container's memory usage reaches its Limit, the Linux kernel's Out-Of-Memory (OOM) Killer immediately terminates the process with a SIGKILL signal. Kubernetes records this as an OOMKilled exit reason and, depending on the Pod's restartPolicy, will attempt to restart it.
If the underlying memory leak is not fixed, the Pod enters a CrashLoopBackOff — restarting repeatedly, each time consuming more memory until it's killed again. The restart interval grows exponentially (10s, 20s, 40s, 80s...) to prevent thrashing.
Diagnosing an OOMKill means checking the Pod's status for a terminated container state with reason OOMKilled and exit code 137. Exit code 137 = 128 + 9 (SIGKILL). This is the fingerprint of an OOM kill.
CPU — A Compressible Resource
CPU is compressible: the kernel can throttle a process without killing it. When a container tries to use more CPU than its Limit allows, the Linux kernel pauses its execution for the remainder of the current scheduling period. The process stays alive but runs slower.
From the application's perspective, it feels like the machine suddenly got much slower. Requests take longer to process. Latency spikes. But no crash occurs, no alert fires, and no log entry is written — making CPU throttling one of the hardest performance problems to diagnose without the right metrics.