Our engineering team is struggling to understand how a manages workloads under heavy consumption. If we set strict memory limits on our pods, what happens under the hood when a container attempts to breach that threshold? Does the node swap memory, or does it trigger an immediate termination?
3 answers
Kubernetes enforces memory limits at the container level using Linux control groups (cgroups). When you define a memory limit for a container inside a , the underlying container runtime configures the cgroup subsystem on the host node. Unlike CPU resources, which can be throttled or compressed when limits are exceeded, memory cannot be throttled. If a container's resident set size (RSS) memory usage attempts to exceed the defined cgroup limit, the Linux kernel terminates the primary process immediately to protect the host system, resulting in an OOMKilled status error.
That clear distinction between CPU throttling and memory termination makes complete sense, but how does the decide which pod to evict if the host node itself runs completely out of memory before an individual container even reaches its own declared limit?
Memory limits act as an absolute hard ceiling enforced by the host operating system, meaning any violation results in an instant process kill signal.
I completely agree with Diane. There is absolutely no flexibility or padding given when a process hits that boundary, making accurate memory profiling vital.
When the node itself runs out of RAM, Kubernetes relies on the Quality of Service (QoS) classes: Guaranteed, Burstable, and BestEffort. The kernel assigns an OOM score based on these classes, and containers in the BestEffort or Burstable tiers get terminated first to reclaim space.