TL;DR

Requests are what the scheduler spends; limits are what the kernel enforces. A pod is placed based on its requests, and killed or throttled based on its limits.

CPU and memory fail differently: exceed your CPU limit and you get throttled (slow); exceed your memory limit and you get killed (OOMKilled, exit code 137).

Two of the most common Kubernetes errors are born here: FailedScheduling (requests too big to place) and OOMKilled (memory limit set from hope). Both are manifest bugs, not cluster bugs.

Set values from measurement, not vibes: observe real usage over at least one full traffic cycle, set requests near typical peak, give memory a limit with honest headroom.

Every container needs both numbers, including sidecars and init containers — the one you skip is the one that gets evicted first.

Originally published on DevOps Enginer .

Two of the errors in my Kubernetes troubleshooting guide — pods stuck Pending with FailedScheduling , and containers dying with OOMKilled — look like cluster…