作者：韓柔剛（申信）

背景

云原生場景中，應(yīng)用程序通常以容器的形式部署和分配物理資源。以 Kubernetes 集群為例，應(yīng)用工作負(fù)載以 Pod 聲明了資源的 Request/Limit，Kubernetes 則依據(jù)聲明進(jìn)行應(yīng)用的資源調(diào)度和服務(wù)質(zhì)量保障。

當(dāng)容器或宿主機(jī)的內(nèi)存資源緊張時，應(yīng)用性能會受到影響，比如出現(xiàn)服務(wù)延時過高或者 OOM 現(xiàn)象。一般而言，容器內(nèi)應(yīng)用的內(nèi)存性能受兩方面的影響：

自身內(nèi)存限制：當(dāng)容器自身的內(nèi)存（含 page cache）接近容器上限時，會觸發(fā)內(nèi)核的內(nèi)存子系統(tǒng)運轉(zhuǎn)，此時容器內(nèi)應(yīng)用的內(nèi)存申請和釋放的性能受到影響。

宿主機(jī)內(nèi)存限制：當(dāng)容器內(nèi)存超賣（Memory Limit > Request）導(dǎo)致整機(jī)內(nèi)存出現(xiàn)緊張時，會觸發(fā)內(nèi)核的全局內(nèi)存回收，這個過程的性能影響更甚，極端情況能導(dǎo)致整機(jī)夯死。

前文《阿里云容器服務(wù)差異化 SLO 混部技術(shù)實踐》和《如何合理使用 CPU 管理策略，提升容器性能》分別闡述了阿里云在云原生混部、容器 CPU 資源管理方面的實踐經(jīng)驗和優(yōu)化方法，本文同大家探討容器使用內(nèi)存資源時的困擾問題和保障策略。

容器內(nèi)存資源的困擾

Kubernetes 的內(nèi)存資源管理

部署在 Kubernetes 集群中的應(yīng)用，在資源使用層面遵循標(biāo)準(zhǔn)的 Kubernetes Request/Limit 模型。在內(nèi)存維度，調(diào)度器參考 Pod 聲明的 Memory Request 進(jìn)行決策，節(jié)點側(cè)由 Kubelet 和容器運行時將聲明的 Memory Limit 設(shè)置到 Linux 內(nèi)核的 cgroups 接口，如下圖所示：

CGroups（Control Groups，簡稱 cgroups）是 Linux 上管理容器資源使用的機(jī)制，系統(tǒng)可以通過 cgroups 對容器內(nèi)進(jìn)程的 CPU 和內(nèi)存資源用量作出精細(xì)化限制。而 Kubelet 正是通過將容器的 Request/Limit 設(shè)置到 cgroup 接口，實現(xiàn)對 Pod 和 Container 在節(jié)點側(cè)的可用資源約束，大致如下：

Kubelet 依據(jù) Pod/Container 的 Memory Limit 設(shè)置 cgroups 接口 memory.limit_in_bytes，約束了容器的內(nèi)存用量上限，CPU 資源維度也有類似限制，比如 CPU 時間片或綁定核數(shù)的約束。對于 Request 層面，Kubelet 依據(jù) CPU Request 設(shè)置 cgroups 接口 cpu.shares，作為容器間競爭 CPU 資源的相對權(quán)重，當(dāng)節(jié)點的 CPU 資源緊張時，容器間共享 CPU 時間的比例將參考 Request 比值進(jìn)行劃分，滿足公平性；而 Memory Request 則默認(rèn)未設(shè)置 cgroups 接口，主要用于調(diào)度和驅(qū)逐參考。

Kubernetes 1.22 以上版本基于 cgroups v2 支持了 Memory Request 的資源映射（內(nèi)核版本不低于 4.15，不兼容cgroups v1，且開啟會影響到節(jié)點上所有容器）。

例如，節(jié)點上 Pod A 的 CPU Request 是 2 核，Pod B 的 CPU Request 是 4 核，那么當(dāng)節(jié)點的 CPU 資源緊張時，Pod A 和 Pod B 使用 CPU 資源的相對比例是 1:2。而在節(jié)點的內(nèi)存資源緊張時，由于 Memory Request 未映射到 cgroups 接口，容器間的可用內(nèi)存并不會像 CPU 一樣按 Request 比例劃分，因此缺少資源的公平性保障。

云原生場景的內(nèi)存資源使用

在云原生場景中，容器的內(nèi)存 Limit 設(shè)置影響著容器自身和整個宿主機(jī)的內(nèi)存資源質(zhì)量。
由于 Linux 內(nèi)核的原則是盡可能使用內(nèi)存而非不間斷回收，因此當(dāng)容器內(nèi)進(jìn)程申請內(nèi)存時，內(nèi)存用量往往會持續(xù)上升。當(dāng)容器的內(nèi)存用量接近 Limit 時，將觸發(fā)容器級別的同步內(nèi)存回收，產(chǎn)生額外延時；如果內(nèi)存的申請速率較高，還可能導(dǎo)致容器 OOM (Out of Memory) Killed，引發(fā)容器內(nèi)應(yīng)用的運行中斷和重啟。

容器間的內(nèi)存使用同時也受宿主機(jī)內(nèi)存 Limit 的影響，如果整機(jī)的內(nèi)存用量較高，將觸發(fā)全局的內(nèi)存回收，嚴(yán)重時會拖慢所有容器的內(nèi)存分配，造成整個節(jié)點的內(nèi)存資源質(zhì)量下降。

在 Kubernetes 集群中，Pod 之間可能有保障優(yōu)先級的需求。比如高優(yōu)先級的 Pod 需要更好的資源穩(wěn)定性，當(dāng)整機(jī)資源緊張時，需要盡可能地避免對高優(yōu)先級 Pod 的影響。然而在一些真實場景中，低優(yōu)先級的 Pod 往往運行著資源消耗型任務(wù)，意味著它們更容易導(dǎo)致大范圍的內(nèi)存資源緊張，干擾到高優(yōu)先級 Pod 的資源質(zhì)量，是真正的“麻煩制造者”。對此 Kubernetes 目前主要通過 Kubelet 驅(qū)逐使用低優(yōu)先級的 Pod，但響應(yīng)時機(jī)可能發(fā)生在全局內(nèi)存回收之后。

使用容器內(nèi)存服務(wù)質(zhì)量保障容器內(nèi)存資源

容器內(nèi)存服務(wù)質(zhì)量

Kubelet 在 Kubernetes 1.22 以上版本提供了 MemoryQoS 特性，通過 Linux cgroups v2 提供的 memcg QoS 能力來進(jìn)一步保障容器的內(nèi)存資源質(zhì)量，其中包括：

? 將容器的 Memory Request 設(shè)置到 cgroups v2 接口 memory.min，鎖定請求的內(nèi)存不被全局內(nèi)存回收。
? 基于容器的 Memory Limit 設(shè)置 cgroups v2 接口 memory.high，當(dāng) Pod 發(fā)生內(nèi)存超用時（Memory Usage > Request）優(yōu)先觸發(fā)限流，避免無限制超用內(nèi)存導(dǎo)致的 OOM。

上游方案能夠有效解決 Pod 間內(nèi)存資源的公平性問題，但從用戶使用資源的視角來看，依然存在一些不足：

? 當(dāng) Pod 的內(nèi)存聲明 Request = Limit 時，容器內(nèi)依然可能出現(xiàn)資源緊張，觸發(fā)的 memcg 級別的直接內(nèi)存回收可能影響到應(yīng)用服務(wù)的 RT（響應(yīng)時間）。
? 方案目前未考慮對 cgroups v1 的兼容，在 cgroups v1 上的內(nèi)存資源公平性問題仍未得到解決。

阿里云容器服務(wù) ACK 基于 Alibaba Cloud Linux 2 的內(nèi)存子系統(tǒng)增強(qiáng)，用戶可以在 cgroups v1 上提前使用到更完整的容器 Memory QoS 功能，如下所示：

保障 Pod 間內(nèi)存回收的公平性，當(dāng)整機(jī)內(nèi)存資源緊張時，優(yōu)先從內(nèi)存超用（Usage > Request）的 Pod 中回收內(nèi)存，約束破壞者以避免整機(jī)資源質(zhì)量的下降。

當(dāng) Pod 的內(nèi)存用量接近 Limit 時，優(yōu)先在后臺異步回收一部分內(nèi)存，緩解直接內(nèi)存回收帶來的性能影響。

節(jié)點內(nèi)存資源緊張時，優(yōu)先保障 Guaranteed/Burstable Pod 的內(nèi)存運行質(zhì)量。

典型場景

內(nèi)存超賣

在云原生場景下，應(yīng)用管理員可能會為容器設(shè)置一個大于 Request 的 Memory Limit，以增加調(diào)度靈活性，降低 OOM 風(fēng)險，優(yōu)化內(nèi)存資源的可用性；對于內(nèi)存利用率較低的集群，資源管理員也可能使用這種方式來提高利用率，作為降本增效的手段。但是，這種方式可能造成節(jié)點上所有容器的 Memory Limit 之和超出物理容量，使整機(jī)處于內(nèi)存超賣（memory overcommit）狀態(tài)。當(dāng)節(jié)點發(fā)生內(nèi)存超賣時，即使所有容器的內(nèi)存用量明顯低于 Limit 值，整機(jī)內(nèi)存也可能觸及全局內(nèi)存回收水位線。因此，相比未超賣狀態(tài)，內(nèi)存超賣時更容易出現(xiàn)資源緊張現(xiàn)象，一旦某個容器大量申請內(nèi)存，可能引發(fā)節(jié)點上其他容器進(jìn)入直接內(nèi)存回收的慢速路徑，甚至觸發(fā)整機(jī) OOM，大范圍影響應(yīng)用服務(wù)質(zhì)量。

Memory QoS 功能通過啟用容器級別的內(nèi)存后臺異步回收，在發(fā)生直接回收前先異步回收一部分內(nèi)存，能改善觸發(fā)直接回收帶來的延時影響；對于聲明 Memory Request < Limit 的 Pod，Memory QoS 支持為其設(shè)置主動內(nèi)存回收的水位線，將內(nèi)存使用限制在水位線附近，避免嚴(yán)重干擾到節(jié)點上其他 Pod。

混合部署

Kubernetes 集群可能在同一節(jié)點部署了有著不同資源使用特征的 Pods。比如，Pod A 運行著在線服務(wù)的工作負(fù)載，內(nèi)存利用率相對穩(wěn)定，屬于延時敏感型業(yè)務(wù)（Latency Sensitive，簡稱 LS）；Pod B 運行著大數(shù)據(jù)應(yīng)用的批處理作業(yè)，啟動后往往瞬間申請大量內(nèi)存，屬于資源消耗型業(yè)務(wù)（Best Effort，簡稱 BE）。當(dāng)整機(jī)內(nèi)存資源緊張時，Pod A 和 Pod B 都會受到全局內(nèi)存回收機(jī)制的干擾。實際上，即使當(dāng)前 Pod A 的內(nèi)存使用量并未超出其 Request 值，其服務(wù)質(zhì)量也會受到較大影響；而 Pod B 可能本身設(shè)置了較大的 Limit，甚至是未配置 Limit 值，使用了遠(yuǎn)超出 Request 的內(nèi)存資源，是真正的“麻煩制造者”，但未受到完整的約束，從而破壞了整機(jī)的內(nèi)存資源質(zhì)量。

Memory QoS 功能通過啟用全局最低水位線分級和內(nèi)核 memcg QoS，當(dāng)整機(jī)內(nèi)存資源緊張時，優(yōu)先從 BE 容器中回收內(nèi)存，降低全局內(nèi)存回收對 LS 容器的影響；也支持優(yōu)先回收超用的的內(nèi)存資源，保障內(nèi)存資源的公平性。

技術(shù)內(nèi)幕

Linux 的內(nèi)存回收機(jī)制

如果容器聲明的內(nèi)存 Limit 偏低，容器內(nèi)進(jìn)程申請內(nèi)存較多時，可能產(chǎn)生額外延時甚至 OOM；如果容器的內(nèi)存 Limit 設(shè)置得過大，導(dǎo)致進(jìn)程大量消耗整機(jī)內(nèi)存資源，干擾到節(jié)點上其他應(yīng)用，引起大范圍的業(yè)務(wù)時延抖動。這些由內(nèi)存申請行為觸發(fā)的延時和 OOM 都跟 Linux 內(nèi)核的內(nèi)存回收機(jī)制密切相關(guān)。

容器內(nèi)進(jìn)程使用的內(nèi)存頁面（page）主要包括：
? 匿名頁：來自堆、棧、數(shù)據(jù)段，需要通過換出到交換區(qū)（swap-out）來回收（reclaim）。
? 文件頁：來自代碼段、文件映射，需要通過頁面換出（page-out）來回收，其中臟頁要先寫回磁盤。
? 共享內(nèi)存：來自匿名 mmap 映射、shmem 共享內(nèi)存，需要通過交換區(qū)來回收。

Kubernetes 默認(rèn)不支持 swapping，因此容器中可直接回收的頁面主要來自文件頁，這部分也被稱為 page cache（對應(yīng)內(nèi)核接口統(tǒng)計的 Cached 部分，該部分還會包括少量共享內(nèi)存）。由于訪問內(nèi)存的速度要比訪問磁盤快很多，Linux 內(nèi)核的原則是盡可能使用內(nèi)存，內(nèi)存回收（如 page cache）主要在內(nèi)存水位比較高時才觸發(fā)。

具體而言，當(dāng)容器自身的內(nèi)存用量（包含 page cache）接近 Limit 時，會觸發(fā) cgroup（此處指 memory cgroup，簡稱 memcg）級別的直接內(nèi)存回收（direct reclaim），回收干凈的文件頁，這個過程發(fā)生在進(jìn)程申請內(nèi)存的上下文，因此會造成容器內(nèi)應(yīng)用的卡頓。如果此時的內(nèi)存申請速率超出回收速率，內(nèi)核的 OOM Killer 將結(jié)合容器內(nèi)進(jìn)程運行和使用內(nèi)存的情況，終止一些進(jìn)程以進(jìn)一步釋放內(nèi)存。

當(dāng)整機(jī)內(nèi)存資源緊張時，內(nèi)核將根據(jù)空閑內(nèi)存（內(nèi)核接口統(tǒng)計的 Free 部分）的水位觸發(fā)回收：當(dāng)水位達(dá)到 Low 水位線時，觸發(fā)后臺內(nèi)存回收，回收過程由內(nèi)核線程 kswapd 完成，不會阻塞應(yīng)用進(jìn)程運行，且支持對臟頁的回收；而當(dāng)空閑水位達(dá)到 Min 水位線時（Min < Low），會觸發(fā)全局的直接內(nèi)存回收，該過程發(fā)生在進(jìn)程分配內(nèi)存的上下文，且期間需要掃描更多頁面，因此十分影響性能，節(jié)點上所有容器都可能被干擾。當(dāng)整機(jī)的內(nèi)存分配速率超出且回收速率時，則會觸發(fā)更大范圍的 OOM，導(dǎo)致資源可用性下降。

Cgroups-v1 Memcg QoS

Kubernetes 集群中 Pod Memory Request 部分未得到充分保障，因而當(dāng)節(jié)點內(nèi)存資源緊張時，觸發(fā)的全局內(nèi)存回收能破壞 Pod 間內(nèi)存資源的公平性，資源超用（Usage > Request）的容器可能和未超用的容器競爭內(nèi)存資源。

對于容器內(nèi)存子系統(tǒng)的服務(wù)質(zhì)量（memcg QoS），Linux 社區(qū)在 cgroups v1 上提供了限制內(nèi)存使用上限的能力，其也被 Kubelet 設(shè)置為容器的 Limit 值，但缺少對內(nèi)存回收時的內(nèi)存使用量的保證（鎖定）能力，僅在cgroups v2 接口上支持該功能。

Alibaba Cloud Linux 2 內(nèi)核在 cgroups v1 接口中默認(rèn)開啟 memcg QoS 功能，阿里云容器服務(wù) ACK 通過Memory QoS 功能為 Pod 自動設(shè)置合適的 memcg QoS 配置，節(jié)點無需升級 cgroups v2 即可支持容器 Memory Request 的資源鎖定和 Limit 限流能力，如上圖所示：

? memory.min：設(shè)置為容器的 Memory Request。基于該接口的內(nèi)存鎖定的能力，Pod 可以鎖定 Request 部分的內(nèi)存不被全局回收，當(dāng)節(jié)點內(nèi)存資源緊張時，僅從發(fā)生內(nèi)存超用的容器中回收內(nèi)存。
? memory.high：當(dāng)容器 Memory Request < Limit 或未設(shè)置 Limit 時，設(shè)置為 Limit 的一個比例。基于該接口的內(nèi)存限流能力，Pod 超用內(nèi)存資源后將進(jìn)入限流過程，BestEffort Pod 不能嚴(yán)重超用整機(jī)內(nèi)存資源，從而降低了內(nèi)存超賣時觸發(fā)全局內(nèi)存回收或整機(jī) OOM 的風(fēng)險。

更多關(guān)于 Alibaba Cloud Linux 2 memcg QoS 能力的描述，可參見官網(wǎng)文檔：
https://help.aliyun.com/document_detail/169536.html

內(nèi)存后臺異步回收

前面提到，系統(tǒng)的內(nèi)存回收過程除了發(fā)生在整機(jī)維度，也會在容器內(nèi)部（即 memcg 級別）觸發(fā)。當(dāng)容器內(nèi)的內(nèi)存使用接近 Limit 時，將在進(jìn)程上下文觸發(fā)直接內(nèi)存回收邏輯，從而阻塞容器內(nèi)應(yīng)用的性能。

針對該問題，Alibaba Cloud Linux 2 增加了容器的后臺異步回收功能。不同于全局內(nèi)存回收中 kswapd 內(nèi)核線程的異步回收，本功能沒有創(chuàng)建 memcg 粒度的 kswapd 線程，而是采用了 workqueue 機(jī)制來實現(xiàn)，同時支持 cgroups v1 和 cgroups v2 接口。

如上圖所示，阿里云容器服務(wù) ACK 通過 Memory QoS 功能為 Pod 自動設(shè)置合適的后臺回收水位線 memory.wmark_high。當(dāng)容器的內(nèi)存水位達(dá)到該閾值時，內(nèi)核將自動啟用后臺回收機(jī)制，提前于直接內(nèi)存回收，規(guī)避直接內(nèi)存回收帶來的時延影響，改善容器內(nèi)應(yīng)用的運行質(zhì)量。

更多關(guān)于 Alibaba Cloud Linux 2 內(nèi)存后臺異步回收能力的描述，可參見官網(wǎng)文檔：
https://help.aliyun.com/document_detail/169535.html

全局最低水位線分級

全局的直接內(nèi)存回收對系統(tǒng)性能有很大影響，特別是混合部署了時延敏感型業(yè)務(wù)（LS）和資源消耗型任務(wù)（BE）的內(nèi)存超賣場景中，資源消耗型任務(wù)會時常瞬間申請大量的內(nèi)存，使得系統(tǒng)的空閑內(nèi)存觸及全局最低水位線（global wmark_min），引發(fā)系統(tǒng)所有任務(wù)進(jìn)入直接內(nèi)存回收的慢速路徑，進(jìn)而導(dǎo)致延敏感型業(yè)務(wù)的性能抖動。在此場景下，無論是全局 kswapd 后臺回收還是 memcg 后臺回收，都將無法有效避免該問題。

針對上述場景，Alibaba Cloud Linux 2 增加了 memcg 全局最低水位線分級功能，允許在全局最低水位線（global wmark_min）的基礎(chǔ)上，通過 memory.wmark_min_adj 調(diào)整 memcg 級別生效的水位線。阿里云容器服務(wù) ACK 通過 Memory QoS 功能為容器設(shè)置分級水位線，在整機(jī) global wmark_min 的基礎(chǔ)上，上移 BE 容器的 global wmark_min，使其提前進(jìn)入直接內(nèi)存回收；下移 LS 容器的 global wmark_min，使其盡量避免直接內(nèi)存回收，如下圖所示：

這樣，當(dāng) BE 任務(wù)瞬間大量申請內(nèi)存的時候，系統(tǒng)能通過上移的 global wmark_min 將其短時間抑制，避免促使 LS 發(fā)生直接內(nèi)存回收。等待全局 kswapd 回收一定量的內(nèi)存后，再解決對 BE 任務(wù)的短時間抑制。

更多關(guān)于 Alibaba Cloud Linux 2 memcg 全局最低水位線分級能力的描述，可參見官網(wǎng)文檔：
https://help.aliyun.com/document_detail/169537.html

小結(jié)

綜上，容器內(nèi)存服務(wù)質(zhì)量（Memory QoS）基于 Alibaba Cloud Linux 2 內(nèi)核保障容器的內(nèi)存資源質(zhì)量，各能力的推薦使用場景如下：

我們使用 Redis Server 作為時延敏感型在線應(yīng)用，通過模擬內(nèi)存超賣和壓測請求，驗證開啟 Memory QoS 對應(yīng)用延時和吞吐的改善效果：

對比以上數(shù)據(jù)可得知，開啟容器內(nèi)存服務(wù)質(zhì)量后，Redis 應(yīng)用的平均時延和平均吞吐都得到了一定改善。

總結(jié)

針對云原生場景下容器使用內(nèi)存的困擾，阿里云容器服務(wù) ACK 基于 Alibaba Cloud Linux 2 內(nèi)核提供了容器內(nèi)存服務(wù)質(zhì)量（Memory QoS）功能，通過調(diào)配容器的內(nèi)存回收和限流機(jī)制，保障內(nèi)存資源公平性，改善應(yīng)用的運行時內(nèi)存性能。Memory QoS 屬于相對靜態(tài)的資源質(zhì)量方案，適合作為保障 Kubernetes 集群內(nèi)存使用的兜底機(jī)制，而對于復(fù)雜的資源超賣和混合部署場景，更加動態(tài)和精細(xì)化的內(nèi)存保障策略顯得不可或缺。例如，對于內(nèi)存水位的頻繁波動，基于實時資源壓力指標(biāo)的驅(qū)逐策略，能夠敏捷地在用戶態(tài)進(jìn)行減載（load schedding）；另一方面，可以通過更細(xì)粒度地發(fā)掘內(nèi)存資源，比如基于冷熱頁面標(biāo)記的內(nèi)存回收，或 Runtime (e.g. JVM) GC，來達(dá)到高效的內(nèi)存超賣。敬請期待阿里云容器服務(wù) ACK 支持差異化 SLO 功能的后續(xù)發(fā)布。

總結(jié)

以上是生活随笔為你收集整理的如何使用阿里云容器服务保障容器的内存资源质量的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。