Kubernetes v1.37 moves Memory QoS to beta, giving administrators a supported way to apply Linux cgroup v2 memory controls according to a Pod’s Kubernetes QoS class. The change matters most for teams running Linux nodes with cgroup v2 that need more deliberate control over memory throttling and protection.
There is an important configuration distinction, however. The Memory QoS feature is enabled by default in v1.37, but memory throttling and memory protection are not enabled by the default kubelet configuration. Administrators must configure those behaviors explicitly.
What changed in Kubernetes v1.37
The Kubernetes Pod QoS documentation identifies Memory QoS as beta since Kubernetes v1.37 and enabled by default. The feature uses the Linux cgroup v2 memory controller to manage memory throttling and protection without changing how Kubernetes classifies a Pod.
That means a Pod remains Guaranteed, Burstable, or BestEffort according to the normal Kubernetes QoS rules. Memory QoS uses that existing classification to determine which cgroup settings apply.
The beta status makes the feature available for operational use, but it does not automatically impose new memory policies on every workload. The kubelet settings that control throttling and protection remain separate from feature availability.
Throttling and protection are separate controls
Memory throttling is controlled by the kubelet’s memoryThrottlingFactor setting. A value greater than 0 and no greater than 1 enables use of the cgroup v2 memory.high control. For Burstable Pods, the threshold is calculated from the container’s memory request, memory limit, and configured factor.
Guaranteed containers do not receive a memory.high setting through this mechanism because their memory requests equal their limits. The documented example uses a throttling factor of 0.9, but administrators should evaluate the setting against their workloads rather than treating that value as universal guidance.
Memory protection is controlled separately through memoryReservationPolicy. Its default is None, which means the default kubelet configuration does not enable memory protection. Setting the policy to TieredReservation applies:
- Guaranteed Pods: protection through
memory.min. - Burstable Pods: protection through
memory.low. - BestEffort Pods: no memory protection.
The settings are hierarchical. The kubelet configures cgroups for containers and Pods as well as ancestor cgroups, including the kubepods root and the Burstable QoS cgroup. As a result, this is not simply a policy that applies only at an undifferentiated node-wide level; the hierarchy is part of how the protection settings work.
Example kubelet configuration
The Kubernetes documentation provides an example that enables both behaviors:
memoryThrottlingFactor: 0.9
memoryReservationPolicy: TieredReservationThis configuration should be treated as an operational starting point, not a drop-in policy for every cluster. Memory requests and limits influence the resulting thresholds and reservations, so workload definitions need to be reviewed alongside the kubelet configuration.
Tiered reservation also has a significant caveat for Guaranteed workloads. A Guaranteed Pod using the policy may receive a memory.min value equal to memory.max. If the workload does not leave enough room for page cache, that configuration can increase the risk of an OOM kill. Memory protection should therefore be tested with realistic application and cache behavior.
Platform requirements and availability
Memory QoS requires Linux nodes with cgroup v2. The Kubernetes cgroup documentation lists Linux kernel 5.8 or later, a cgroup-v2-capable container runtime, and the systemd cgroup driver among the general cgroup v2 requirements.
For Memory QoS specifically, Kubernetes recommends kernel 5.9 or later because older kernels can encounter a known livelock problem involving memory.high. The kubelet logs a warning at startup if Memory QoS is enabled on an older kernel.
These kernel statements describe different thresholds: kernel 5.8 or later is listed for general cgroup v2 support, while 5.9 or later is the recommendation for Memory QoS behavior involving memory.high. The supplied documentation does not establish Memory QoS availability on non-Linux or cgroup v1 nodes.
Operators should also account for software that reads cgroup files directly. Monitoring agents and other node-level tools may need versions that understand the cgroup v2 interface.
What happens when the feature is disabled
Disabling Memory QoS requires turning off its feature gate, leaving memoryReservationPolicy unset or setting it to None, and restarting the kubelet. The documentation describes startup cleanup for selected ancestor protections.
Disabling the feature does not necessarily clear every memory.high value immediately on already-running containers. Existing containers may retain that setting until they are restarted or undergo an in-place resize. The Memory QoS KEP also describes rollback cleanup for memory.min, memory.low, and memory.high when the feature is disabled or configurations are reapplied.
Exact upgrade behavior for every workload, resize path, and container-runtime combination is not established by the supplied documentation. Administrators should validate those paths in the specific Kubernetes environment before relying on an automated rollback or upgrade assumption.
What you should do
- Confirm node compatibility. Verify that target nodes use Linux with cgroup v2, a compatible container runtime, and the expected cgroup driver. Check kernel versions, with 5.9 or later recommended for Memory QoS memory-high behavior.
- Inspect workload requests and limits. Memory QoS derives thresholds and reservation levels from workload configuration and QoS class. Incorrect or overly aggressive values can produce unexpected throttling or protection behavior.
- Choose policies explicitly. Do not assume that beta feature availability enables throttling or protection. Configure
memoryThrottlingFactorandmemoryReservationPolicyonly after deciding which behavior the cluster requires. - Test pressure-sensitive workloads. Pay particular attention to applications sensitive to throttling, page-cache usage, memory pressure, or OOM behavior. Validate both normal operation and recovery scenarios.
- Test rollback and resizing. Confirm how restarts, in-place resize operations, monitoring, and container-runtime behavior affect cgroup values in the target environment.
- Update cgroup tooling. Review agents or operational software that directly inspect cgroup files and verify that they support cgroup v2.
Memory QoS does not change Pod QoS classification or node-pressure eviction ordering. Its value is in applying more specific cgroup memory controls when the underlying Linux and kubelet configuration support them. Kubernetes v1.37 makes that capability beta, but administrators still need to opt into the policies and validate their effects.
