What's the difference in behavior between a container hitting its own memory limit versus the underlying node running out of memory overall?

A container exceeding its own limits.memory is a contained, predictable event — the kernel's cgroup memory controller kills just that one container's process(es) the instant it crosses its own limit, leaving every other container on the node completely unaffected. A node running out of memory overall (total memory demand across all containers exceeding the node's actual physical/allocatable memory) is a much less contained, less predictable event — the kernel's system-wide OOM killer decides which process to kill based on its own scoring heuristic, potentially affecting a container that wasn't even the one consuming excessive memory, and can degrade the whole node's performance before any kill even happens.

Container-limit OOM: Kubernetes implements limits.memory via a Linux cgroup memory limit specific to that container. When the container's actual memory usage crosses that cgroup's limit, the kernel's cgroup OOM killer acts immediately and precisely — it kills a process within that specific cgroup (the container), and only that container is affected. Other containers on the same node, even ones under memory pressure themselves, are completely unaffected by this event, since the cgroup boundary contains the consequence entirely to the offending container. This is a predictable, well-scoped failure mode — precisely the protection limits.memory is meant to provide, containing one container's excess to itself.

Node-level OOM: this happens when the sum of actual memory usage across everything running on the node (all containers' actual usage, which can exceed their individual requests if they're using more than requested but still under their own limits, plus system-level processes) exceeds the node's actual available memory — a fundamentally different, less contained scenario. The Linux kernel's system-wide OOM killer then has to choose some process to kill, using a scoring heuristic (oom_score_adj, influenced by Kubernetes' own QoS-class-based adjustments) that doesn't necessarily target the container actually responsible for the excess usage — it's entirely possible for a well-behaved, low-memory container to be killed by the node-level OOM killer because of its calculated score, even though a different container was the one that pushed the node over the edge. Before any kill even happens, a node under severe memory pressure can also experience broader performance degradation (heavy swapping if enabled, or general system slowness) affecting everything running on it, not just whatever eventually gets killed.

Kubernetes' QoS classes (Guaranteed, Burstable, BestEffort, derived from how requests and limits are set) directly influence the node-level OOM killer's scoring — BestEffort pods (no requests/limits set at all) are the most likely to be killed first in a node-level OOM event, Guaranteed pods (requests equal to limits) are the least likely — but this is a preference the scoring encodes, not an absolute guarantee, unlike the precise, contained certainty of a container hitting its own cgroup limit.

• A container exceeding its own limits.memory triggers a precise, contained cgroup-level kill affecting only that container — other containers are unaffected.
• Node-level OOM is a shared-resource event where the kernel's OOM killer chooses among all processes on the node using a scoring heuristic, potentially killing a container that wasn't the actual cause.
• Node-level OOM pressure can degrade overall node performance before any kill even occurs, unlike a container hitting its own limit.
• Kubernetes' QoS classes influence node-level OOM killer scoring (BestEffort most likely to be killed, Guaranteed least likely), but this is a preference, not a guarantee, unlike a container-limit OOM's precision.

• Kubernetes Docs: Resource Management for Pods and Containers
• Kubernetes Docs: Pod Quality of Service Classes
• Linux man-pages: proc(5) — oom_score_adj