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