How Memory QoS Boosts Container Performance in Cloud‑Native Kubernetes

Background

In cloud‑native scenarios, applications run in containers that are scheduled on Kubernetes nodes using the standard Request/Limit model. When memory resources become scarce on a container or its host, performance degrades, causing high latency or OOM events. Two main factors affect container memory performance: the container's own memory limit and the host's overall memory pressure.

Kubernetes Memory Management

Kubernetes sets the pod's Memory Request and Memory Limit in the node's cgroups. The kubelet writes the limit to memory.limit_in_bytes and the CPU request to cpu.shares. Requests are used for scheduling and eviction, while limits constrain actual usage. Starting with Kubernetes 1.22 (kernel ≥ 4.15) and cgroups v2, Memory Request can also be mapped to memory.min, locking the requested memory from global reclamation.

Kubernetes 1.22+ with cgroups v2 supports mapping Memory Request to cgroups (requires kernel ≥ 4.15, not compatible with cgroups v1).

Because requests are not enforced at the cgroup level, containers may still compete for memory when the node is under pressure, leading to unfairness.

Challenges: Overcommit and Mixed Deployments

Operators often set Memory Limit higher than Memory Request to improve scheduling flexibility and reduce OOM risk. This creates memory overcommit, where the sum of limits exceeds physical capacity. In mixed workloads—latency‑sensitive services (LS) and batch jobs (BE)—the BE pods can quickly consume memory, triggering global reclamation that also harms LS pods.

Memory QoS in Alibaba Cloud Linux 2 / ACK

Alibaba Cloud Linux 2 enhances the container memory subsystem, enabling Memory QoS on both cgroups v1 and v2 without requiring a kernel upgrade. Key capabilities:

Set container Memory Request to memory.min, preventing global reclamation of the requested memory.

Set memory.high based on the limit (or a proportion of it) to throttle containers that exceed their request, protecting the node from severe overcommit.

Additional features:

Fair reclamation: when the node is tight, memory is reclaimed first from pods that exceed their request.

Background asynchronous reclaim: before direct reclamation, a portion of memory is reclaimed asynchronously to reduce latency spikes.

Priority protection: Guaranteed / Burstable pods receive preferential treatment under memory pressure.

Technical Details of Linux Memory Reclaim

Linux distinguishes anonymous pages, file pages, and shared memory. Kubernetes disables swapping, so only file pages (page cache) are directly reclaimable. When a container approaches its limit, the kernel performs direct reclaim in the allocation context, causing application stalls. If free memory falls below the Low water‑mark, the kernel thread kswapd runs asynchronous reclaim; below the Min water‑mark, global direct reclaim occurs, impacting all containers.

Memory QoS adds a global minimum water‑mark tier ( memory.wmark_min_adj) that raises the threshold for BE pods and lowers it for LS pods, allowing the system to preferentially reclaim memory from batch workloads.

Typical Scenarios

Memory overcommit, mixed LS/BE deployments, and workloads with bursty memory usage benefit from the above QoS settings. The memory.min lock prevents request‑level memory from being reclaimed, while memory.high throttles excess usage.

Evaluation

A Redis latency‑sensitive service was benchmarked under memory overcommit. Enabling Memory QoS reduced average latency and increased throughput compared with the default configuration.

Conclusion

Memory QoS in Alibaba Cloud Linux 2 provides a static, kernel‑level safeguard for container memory quality in Kubernetes clusters, improving fairness and reducing latency spikes. For more dynamic scenarios, additional strategies such as real‑time eviction policies or fine‑grained page‑level reclamation may be required. Further enhancements, including differentiated SLO support, are expected in future ACK releases.

References:

https://help.aliyun.com/document_detail/169536.html

https://help.aliyun.com/document_detail/169535.html

https://help.aliyun.com/document_detail/169537.html