阿里云容器服務差異化 SLO 混部技術實踐
發(fā)布時間：2022-01-19 點擊數(shù)：856
作者：佑祎
01
背景介紹
Cloud Native
阿里巴巴在“差異化 SLO 混合部署”上已經有了多年的實踐經驗，目前已達到業(yè)界領先水平。所謂“差異化 SLO”，就是將不同類型的工作負載混合運行在同一節(jié)點，充分利用工作負載對資源 SLO 需求特征的不同，提升資源整體使用效率。本文將重點介紹相關技術細節(jié)和使用方法，讓用戶可以充分享受差異化 SLO 帶來的技術紅利。
02
資源模型
Cloud Native
作為通用的計算資源托管框架，Kubernetes 托管了多種類型的業(yè)務負載，包括在線服務、大數(shù)據(jù)、實時計算、AI 等等。從業(yè)務對資源質量需求來看，這些業(yè)務可以分為“延時敏感型”（Latency Sencitive，簡稱 LS）和“資源消耗型”（Best Effort，簡稱 BE）兩類。
對于 LS 類型，為了確保資源的穩(wěn)定性（能夠應對突發(fā)的業(yè)務流量，能夠應對機房容災后帶來的流量增長），一個可靠的服務通常會申請較大的資源 request 和 limit，這也是 Kubernetes 集群資源分配率很容易做到 80% 以上但利用率卻低于 20% 的主要原因，也是 Kubernetes 引入 BestEffort QoS 類型的原因。
為了充分利用這部分已分配但未使用的資源，我們將上圖中的紅線定義為 usage，藍色線到紅色先預留部分資源定義為 buffered，綠色覆蓋部分定義為 reclaimed，如下圖所示：
# Nodestatus: allocatable: # milli-core : 50000 # bytes : 50000 capacity: : 50000 : 100000
低優(yōu)的 BE 任務在使用 reclaimed 資源時，只需在 Pod 增加“qos”和“reclaimed-resource”的表述即可，其中 qos = LS 對應高優(yōu)先級，qos = BE 對應低優(yōu)先級；reclaimed-cpu/memory 為 BE Pod 的具體資源需求量。
# Podmetadata: label: : BE # {BE, LS}spec: containers: resources: limits: : 1000 : 2048 requests: : 1000 : 2048
Cloud Native
1 CPU 資源質量
CPU Burst
Kubernetes 為容器資源管理提供了 Limit（約束）的語義描述，對于 CPU 這類分時復用型的資源，當容器指定了 CPU Limit，操作系統(tǒng)會按照一定的時間周期約束資源使用。例如對于 CPU Limit = 2 的容器，操作系統(tǒng)內核會限制容器在每 100 ms 周期內最多使用 200 ms 的 CPU 時間片。
CPU 拓撲感知調度
隨著宿主機硬件性能的提升，單節(jié)點的容器部署密度進一步提升，進程間的 CPU 爭用，跨 NUMA 訪存等問題也逐漸加劇，嚴重影響了應用性能表現(xiàn)。在多核節(jié)點下，進程在運行過程中經常會被遷移到其不同的核心，考慮到有些應用的性能對 CPU 上下文切換比較敏感，kubelet 提供了 static 策略，允許 Guarantee 類型 Pod 獨占 CPU 核心。但該策略尚有以下不足之處：
- static policy 只支持 QoS 為 Guarantee 的 Pod，其他 QoS 類型的 Pod 無法使用。
- 策略對節(jié)點內所有 Pod 全部生效，而 CPU 綁核并不是”銀彈“，需要支持 Pod 粒度的精細化策略。
- 中心調度并不感知節(jié)點實際的 CPU 分配情況，無法在集群范圍內選擇到最優(yōu)組合。
彈性資源限制（reclaimed-resource）
如資源模型中的描述，節(jié)點 reclaimed-resource 的資源總量會跟隨高優(yōu)先級容器實際的資源用量動態(tài)變化，在節(jié)點側，為了保障 LS 容器的運行質量，BE 容器實際可用 CPU 數(shù)量同樣受 LS 容器負載的影響。
內核Group Identity
- 高優(yōu)先級任務的喚醒延遲最小化。
- 低優(yōu)先級任務不對高優(yōu)先級任務造成性能影響。主要體現(xiàn)在：
- 低優(yōu)先級任務的喚醒不會對高優(yōu)先級任務造成性能影響。
- 低優(yōu)先級任務不會通過 SMT 調度器共享硬件 unit（超線程場景）而對高優(yōu)先級任務造成性能影響。
系統(tǒng)內核在調度包含具有身份標識的任務時，會根據(jù)不同的優(yōu)先級做相應處理。具體說明如下表：
LLC 及 MBA 隔離
在神龍裸金屬節(jié)點環(huán)境，容器可用的 CPU 緩存（Last Level Cache，LLC）及 內存帶寬（Memory Bandwidth Allocation，MBA）可以被動態(tài)調整。通過對 BE 容器進程的細粒度資源限制，可以進一步避免對 LS 容器產生性能干擾。
2 內存資源質量
全局最低水位線分級
基于上述場景下的問題，Alibaba Cloud Linux 2 新增了 memcg 全局最低水位線分級功能。在 global wmark_min 的基礎上，將 BE 的 global wmark_min 上移，使其提前進入直接內存回收。將 LS 的 global wmark_min 下移，使其盡量避免直接內存回收。這樣當 BE 任務瞬間申請大量內存的時候，會通過上移的global wmark_min 將其短時間抑制，避免 LS 發(fā)生直接內存回收。等待全局 kswapd 回收一定量的內存后，再解除 BE 任務的短時間抑制。
后臺異步回收
在全局最低水位線分級后，LS 容器的內存資源不會被全局內存回收影響，但當容器內部緊張時會觸發(fā)直接內存回收，直接內存回收是發(fā)生在內存分配上下文的同步回收，因此會影響當前容器中運行進程的性能。
當容器內存使用超過 memory.wmark_ratio 時，內核將自動啟用異步內存回收機制，提前于直接內存回收，改善服務的運行質量。
更多關于容器內存后臺異步回收能力的描述，可參見官網(wǎng)文檔：https://help.aliyun.com/document_detail/169535.html
CPU 資源滿足度
前文介紹了多種針對低優(yōu)先級離線容器的 CPU 資源壓制能力，可以有效保障 LS 類型業(yè)務的資源使用。然而在 CPU 被持續(xù)壓制的情況下，BE 任務自身的性能也會受到影響，將其驅逐重調度到其他空閑節(jié)點反而可以使任務更快完成。此外，若 BE 任務在受壓制時持有了內核全局鎖這類資源，CPU 持續(xù)無法滿足可能會導致優(yōu)先級反轉，影響 LS 應用的性能。
因此，差異化 SLO 套件提供了基于 CPU 資源滿足度的驅逐能力，當 BE 類型容器的資源滿足度持續(xù)低于一定水位時，使用 reclaimed 資源的容器會按從低到高的優(yōu)先級被依次驅逐。
內存閾值水位
案例實踐
Cloud Native
1 使用 CPU Brust 提升應用性能
對比以上數(shù)據(jù)可得知：
- 在開啟 CPU Burst 能力后，應用的 RT 指標的 p99 分位值得到了明顯的優(yōu)化。
- 對比 CPU Throttled 及利用率指標，可以看到開啟 CPU Burst 能力后，CPU Throttled 情況得到了消除，同時 Pod 整體利用率基本保持不變。
我們以“Web服務+大數(shù)據(jù)”場景為例，選擇了 nginx 作為 Web 服務（LS），與 spark benchmark 應用（BE）混部在 ACK 集群的同一節(jié)點，介紹 ACK 差異化 SLO 套件在實際場景下的混部效果。
對比非混部場景下的基線，以及差異化 SLO 混部場景下的數(shù)據(jù)，可以看出 ACK 差異化 SLO 套件可以在保障在線應用服務質量的同時（性能干擾 < 5%），提升集群利用率（30%）
- 對比“nginx 獨立運行”與“差異化 SLO 混部”的 nginx 時延數(shù)據(jù)，RT-p99 只有4.4%左右的性能下降。
- 對比“spark 獨立運行”與“差異化 SLO 混部”的 BE 任務運行時長，即便在 BE 任務頻繁受到壓制的情況下，總運行時間只上升了 11.6%。
相較于延時敏感型的在線服務，大數(shù)據(jù)類型應用對資源質量的要求并不敏感，“差異化 SLO 混部”可以進一步提升大數(shù)據(jù)集群的容器部署密度，提高集群資源利用率，縮短作業(yè)平均運行時間。我們以 Spark TPC-DS 評測集為例，介紹 ACK 差異化 SLO 套件對集群資源利用率的提升效果。
- “差異化 SLO”功能開啟后，通過集群 reclaimed-resource 資源超賣模型，集群內可以運行更多的 Spark 容器。
- 集群 CPU 平均利用率由 49% 提升至 58%；資源的充分利用使得評測集作業(yè)的總運行時間下降了 8%。
05
總結
Cloud Native
阿里云容器服務 ACK 支持差異化 SLO 的相關功能將在官網(wǎng)陸續(xù)發(fā)布，各項功能可獨立用于保障應用的服務質量，也可在混部場景下共同使用。實踐表明，差異化 SLO 技術可以有效提升應用性能表現(xiàn)。特別是在混部場景下，ACK 差異化 SLO 混部技術可以將集群資源利用率提升至相當可觀的水平；同時，針對在線時延敏感型服務，該技術可以將混部引入的性能干擾控制在 5% 以內。