K8s v1.37 Memory QoS: Tiered Protection or Just More Knobs?
Sources
Memory management in Kubernetes has always been the "wild west" compared to CPU. While CPU has CFS quotas and shares, memory is essentially "use it until you hit the limit and the OOM killer strikes." K8s v1.37's Memory QoS (Beta) attempts to bring more nuance to this via tiered protection.
The Technicals
The goal is to differentiate between "critical" memory (that should never be reclaimed) and "cache" memory (that can be squeezed when the node is under pressure). By integrating more tightly with cgroup v2, Kubelet can now provide better signals to the kernel about which memory pages are truly essential for the application's survival versus those that are just opportunistic.
The Catch: The OOM Mystery
The problem with "tiered" memory is that it shifts the failure mode. Instead of a clean "Pod exceeded limit -> OOMKilled," you might enter a state of "invisible" performance degradation where the kernel is aggressively reclaiming pages from your "lower tier" memory, causing your app to swap or thrash without ever actually hitting the limit.
Debugging this requires knowing exactly how the Linux OOM killer interacts with the specific cgroup hierarchy K8s is using. For most platform engineers, this just means more time spent in dmesg trying to figure out why a Pod is slow but not crashing.
Verdict
Useful for very large-memory workloads where you can't afford a full Pod restart for a minor memory spike. For the average microservice, the standard requests/limits are sufficient. Don't add this complexity unless you're seeing systemic OOM issues that you can't solve with better limits.