Kubernetes v1.36 Introduces Tiered Memory Protection with Enhanced Memory QoS

Introduction

Kubernetes v1.36, on behalf of SIG Node, brings significant enhancements to the Memory QoS feature (still in alpha). Originally introduced in v1.22 and updated in v1.27, this feature leverages the cgroup v2 memory controller to provide the kernel with smarter guidance on how to handle container memory under pressure. The latest version adds opt-in memory reservation, tiered protection by QoS class, new observability metrics, and a kernel-version warning for memory.high.

What’s New in v1.36

This release refines the Memory QoS mechanism to separate throttling from memory reservation, giving cluster operators finer control and reducing the risk of over‑reservation that could lead to out‑of‑memory (OOM) kills.

Opt‑in Memory Reservation with memoryReservationPolicy

Previously, enabling the MemoryQoS feature gate automatically applied memory.min to every container with a memory request. That approach could lock up too much memory on nodes with many Burstable pods, leaving little headroom for system daemons or BestEffort workloads.

In v1.36, throttling via memory.high (controlled by the memoryThrottlingFactor, default 0.9) is still activated by the feature gate, but memory reservation is now governed by a separate kubelet configuration field: memoryReservationPolicy. Two settings are available:

• None (default): No memory.min or memory.low are written to cgroups. Throttling via memory.high still works, providing a safety net without any hard or soft reservation.
• TieredReservation: The kubelet applies tiered memory protection depending on the Pod’s QoS class, as described below.

This separation lets operators first enable throttling alone, observe workload behavior, and then opt into reservation when there is enough headroom on the node.

Tiered Protection by QoS Class

With TieredReservation, each QoS class receives a different kind of memory protection:

• Guaranteed Pods – Hard protection via memory.min. For a Guaranteed Pod requesting 512 MiB of memory, the kernel sets memory.min to that value (e.g., 536870912 bytes). This memory is never reclaimed by the kernel; if the kernel cannot honor the guarantee, it invokes the OOM killer on other processes to free pages.
• Burstable Pods – Soft protection via memory.low. For the same 512 MiB request on a Burstable Pod, the kernel sets memory.low to that value. Under normal memory pressure, the kernel avoids reclaiming this memory, but under extreme pressure it may reclaim some to prevent a system‑wide OOM.
• BestEffort Pods – No memory.min or memory.low is set. Their memory remains fully reclaimable at all times.

This tiered approach prevents the kind of over‑reservation seen in earlier versions. Consider a node with 8 GiB of RAM where Burstable Pod requests total 7 GiB. In v1.27, those 7 GiB would be locked as memory.min, leaving only 1 GiB for the kernel, system daemons, and BestEffort workloads – a recipe for OOM kills. With v1.36’s tiered reservation, those requests map to memory.low instead, allowing the kernel to reclaim some memory under extreme pressure while still protecting it under normal conditions. Only Guaranteed Pods use memory.min, keeping hard reservations lower and safer.

For a hands‑on comparison, you can inspect the cgroup files directly. For example, a Guaranteed Pod with 512 MiB request:

$ cat /sys/fs/cgroup/kubepods.slice/kubepods-pod6a4f2e3b_1c9d_4a5e_8f7b_2d3e4f5a6b7c.slice/memory.min
536870912

And a Burstable Pod with the same request:

$ cat /sys/fs/cgroup/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod8b3c7d2e_4f5a_6b7c_9d1e_3f4a5b6c7d8e.slice/memory.low
536870912

Observability Metrics

To help operators monitor and tune the new memory protection, two alpha‑stability metrics are now exposed on the kubelet’s /metrics endpoint:

These metrics give cluster administrators visibility into how much memory is being reserved and whether adjustments are needed.

Kernel Version Warning for memory.high

Another addition in v1.36 is a warning when the host kernel does not support the memory.high cgroup file (e.g., due to an older kernel or missing cgroup v2 configuration). This helps operators quickly diagnose why Memory QoS throttling might not be working as expected.

Conclusion

Kubernetes v1.36’s Memory QoS enhancements offer a more granular and safe approach to memory reservation. By decoupling throttling from reservation and introducing tiered protection based on QoS classes, the feature reduces the risk of OOM kills while still providing hard guarantees for critical workloads. The new observability metrics and kernel‑version warnings further aid cluster administrators in deploying and tuning this alpha feature. As always, test in non‑production environments first and provide feedback to the SIG Node community.