Kubernetes 1.37 Memory QoS: Throttling and Reservations Explained

Kubernetes 1.37 promotes Memory QoS to beta and enables the feature gate by default. That sentence sounds like every upgraded node will immediately start throttling memory. It will not.

The feature is available by default, but the Kubernetes 1.37 kubelet does not write memory.high, memory.min, or memory.low unless you explicitly configure throttling or reservation.

The Default Is Deliberately Conservative

Memory QoS works on Linux nodes using cgroup v2. Kubernetes 1.37 changes the default memoryThrottlingFactor to null. With that value, kubelet does not configure memory.high.

The default memoryReservationPolicy is None, so it also does not configure tiered memory.min and memory.low protection.

This matters during upgrades. Enabling a beta feature gate should not silently change application latency for workloads that previously ran without memory throttling.

Enable Memory Throttling

To ask the kernel to throttle Burstable and BestEffort containers before they reach their hard limit, set a factor between 0 and 1:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9

Kubelet uses the factor when calculating memory.high. Crossing memory.high causes reclaim pressure and can slow allocation; it is not the same as the hard OOM boundary.

Start with a canary node pool. Watch application latency, memory pressure stalls, container working set, reclaim activity, and OOM events. A configuration that protects node stability can still hurt a latency-sensitive service if its memory request is unrealistic.

Enable Tiered Memory Reservation

Kubernetes can protect memory according to Pod QoS class:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9
memoryReservationPolicy: TieredReservation

With tiered reservation, Guaranteed workloads receive stronger protection through memory.min, while Burstable workloads receive protection through memory.low.

This policy is node-wide. You cannot opt individual Pods in or out. That is the most important design constraint: a mixed node pool must use one policy for every workload on the node.

Check Prerequisites Before Rollout

Confirm that nodes use cgroup v2 and that your operating system, kernel, container runtime, and kubelet configuration are consistent.

stat -fc %T /sys/fs/cgroup
kubectl get nodes -o wide
kubectl describe node <node-name>

On the node, inspect the relevant cgroup files only as a diagnostic. Manage the desired state through kubelet configuration rather than editing cgroup files by hand.

Requests Still Matter

Memory QoS is not a replacement for accurate requests and limits. Requests influence QoS classification and reservation calculations. Limits still define the hard boundary that can lead to an OOM kill.

Before enabling the policy, compare recent peak usage with requests and limits. Fix obvious under-requesting, then canary the kubelet change. Otherwise you may mistake poor resource sizing for a Memory QoS problem.

Safe Rollout Checklist

1. Verify cgroup v2 on the target node pool.
2. Capture baseline latency, reclaim, PSI, and OOM metrics.
3. Apply the configuration to a small pool.
4. Schedule representative workloads there.
5. Test memory pressure rather than only normal traffic.
6. Compare application and node behavior.
7. Expand gradually and keep a rollback configuration ready.

Bottom Line

Kubernetes 1.37 makes Memory QoS easier to adopt without forcing a behavior change. The feature gate is on; the policy remains your decision. Treat throttling and tiered reservation as node-level performance controls that require accurate requests, cgroup v2, observability, and a canary rollout.

Review the broader Kubernetes 1.37 upgrade guide before changing production nodes.

Sources

• Kubernetes Blog: Memory QoS graduates to beta
• Kubernetes Docs: Pod quality of service classes