本文介紹在離線混部的技術架構、混部資源模型和單機QoS保障，協助您快速瞭解和使用在離線混部。
背景資訊
從叢集維度來看，混部是將多種應用在一個叢集內部署，通過預測性分析應用特性，實現業務對叢集資源的充分利用；從節點維度來看，混部是將多個容器部署在同一個節點上，這些容器內的應用既包括線上類型，也包括離線類型。根據應用對資源品質需求的差異，線上應用可以歸納為延時敏感型LS（Latency Sensitive），通常對請求壓力（QPS）或訪問延遲（RT）等指標有明確的要求，對資源品質較為敏感；離線應用可以歸納為資源消耗型BE（Best Effort），通常是一些計算密集型的任務類應用，有較好的容錯重試能力，對資源品質的要求相對較為寬鬆。
在部署混部的過程中，不同角色的管理員的側重點不同：
叢集資源的管理員：期望可以簡化對叢集資源的管理，洞察各類應用的資源容量、分配量和使用量，提升叢集資源使用率，達到降低IT成本的目的。
線上類型應用的管理員：更關注容器在混合部署後的幹擾問題，因為混部會更容易產生資源競爭，應用的回應時間往往會出現長尾現象（即總有一部分請求的延遲顯著地高於平均值，通常表現為回應時間的90或99分位值大幅高於平均值），導致應用服務品質下降。
離線類型應用的管理員：更期望混部系統可以提供分級可靠的資源超賣，滿足不同作業類型的差異化資源品質需求。
針對以上問題，ACK在離線混部方案提供了以下機制，可以充分滿足不同角色對混部系統的技術需求：
面向混部情境的資源優先順序和服務品質模型。
穩定可靠的資源超賣機制。
細粒度的容器Resource Orchestration Service和隔離機制。
增強多種類型工作負載的調度能力。
技術架構
ack-koordinator是ACK支援差異化SLO混部能力的向外延展群組件，由中心側Controller和單機側Agent組成。Controller是標準的K8s擴充，以Deployment形式進行部署；Agent以DaemonSet形式進行部署，在標準kubelet的基礎上支援各類混部能力。
整體架構如上圖所示，ACK差異化SLO混部方案定義了一系列協議，例如使用CRD記錄各節點的指標資料以及各類QoS策略的配置和執行情況、使用標準的extended-resource記錄動態資源超賣容量等，各組件圍繞該協議的功能機制如下：
SLO Controller：負責感知各節點運行時負載，並根據資源畫像完成智能資源超賣與SLO保障。
Recommender：提供資源畫像功能，預估工作負載的峰值資源需求，簡化您的配置容器資源規格的複雜度。
Koordlet：負責節點閉環控制迴路，運行時負載感知與異常檢測，資源動態隔離與幹擾抑制。
ACK Scheduler：針對差異化SLO混部情境進行額外的最佳化，例如針對動態超賣資源調度時的打散。
Koordinator Descheduler：以Deployment的形式部署的中心組件，提供重調度功能。
混部資源模型
在K8s的資源管理機制中，應用程式容器都是按照Request和Limit的形式申請資源，為了確保資源的穩定性，管理員通常會為LS類型的應用申請較大的資源Request和Limit，因此會出現K8s叢集資源的分配率（Requested）較高，而實際利用率（Usage）較低的情況。
如下圖所示，將綠色部分的可動態超賣的資源量，分配給BE類型的業務，可以充分利用工作負載對資源運行品質需求不同的特徵，提升叢集整體資源使用率。
阿里雲Container ServiceACK差異化SLO擴充套件提供了將這部分超賣資源量化的能力，動態計算當前的Reclaimed資源量，並以標準擴充資源的形式即時更新到K8s的Node元資訊中。
Node YAML樣本如下：
status:
allocatable:
# milli-core
kubernetes.io/batch-cpu: 50000
# bytes
kubernetes.io/batch-memory: 50000
capacity:
kubernetes.io/batch-cpu: 50000
kubernetes.io/batch-memory: 100000低優先順序的BE任務在使用Reclaimed資源時，只需在Pod YAML中增加qos和batch的欄位即可，其中qos: LS表示高優先順序，qos: BE表示低優先順序；batch-cpu和batch-memory表示Pod的具體資源的需求量。更多資訊，請參見動態資源超賣。
BE Pod的YAML樣本如下：
metadata:
labels:
koordinator.sh/qosClass: "BE" # 可配置為BE或LS。
spec:
containers:
- resources:
limits:
kubernetes.io/batch-cpu: 1000
kubernetes.io/batch-memory: 2048
requests:
kubernetes.io/batch-cpu: 1000
kubernetes.io/batch-memory: 2048單機QoS保障
CPU QoS
為了提高LS應用使用CPU資源的穩定性，降低BE應用的幹擾，ack-koordinator基於Alibaba Cloud Linux，提供了容器CPU QoS功能。ack-koordinator通過Group Identity提供的Linux調度優先順序，差異化保障不同優先順序應用的CPU調度，將LS應用標識為高優先順序，BE應用標識為低優先順序，在混合部署情境中可以有效改善LS應用的服務品質。
通過啟用容器CPU QoS功能，您可以獲得以下功能特性：
LS應用的任務喚醒延遲最小化。
BE應用的任務喚醒不會對LS容器造成效能影響。
BE應用的任務不會通過同時多線程SMT（Simultaneous Multithreading）調度器共用物理核，對LS應用造成效能影響。
彈性資源限制（CPU Suppress）
在混部資源模型中，超賣的混部資源總量會根據高優先順序LS（Latency Sensitive）類型Pod的實際資源用量而動態變化，這部分資源可以供低優先順序BE（BestEffort）類型Pod使用。為了確保BE類型Pod的CPU資源使用在安全範圍內，避免LS類型應用的運行品質受到幹擾，ack-koordinator在節點側提供了彈性資源限制功能。彈性資源限制功能可以幫您在整機資源用量安全水位下，控制BE類型Pod可使用的CPU資源量，保障節點內容器穩定運行。
如下圖所示，在整機安全水位下（CPU Threshold），隨著LS類型Pod資源使用量的變化（Pod(LS).Usage），BE類型Pod可用的CPU資源被限制在合理的範圍內（CPU Restriction for BE）。通過這種方式可以使BE類型Pod充分使用空閑資源，提升離線任務的吞吐，並且當線上負載增加時，避免對BE類型Pod佔用過多的資源，影響線上應用的服務品質。
CPU Burst
K8s為容器資源管理提供了約束（Limit）的語義描述。對於CPU這類資源，當容器指定了CPU Limit，作業系統會按照一定的時間周期約束資源使用。例如對於CPU Limit=2的容器，作業系統核心會限制容器在每100ms周期內最多使用200ms的CPU時間片。
下圖展示了一台4核節點、CPU Limit=2的Web服務類容器，在收到請求（Req）後各線程（Thread）的CPU資源分派情況。可以看出，即使容器在最近1s內整體的CPU使用率較低，受CPU Throttled機制的影響，Thread 2仍需要等待下一個周期才能繼續將Req 2處理完成，進而導致請求的響應時延（RT）變大，這通常是造成容器RT長尾現象嚴重的原因之一。
CPU Burst機制可以有效解決延遲敏感性應用的RT長尾問題，允許容器在空閑時積累一些CPU時間片，用於滿足突發時的資源需求，提升容器效能。目前ACK已經完成了對CPU Burst機制的全面支援。對於尚未支援CPU Burst策略的核心版本，ACK也會通過類似的原理，監測容器CPU Throttle狀態，並動態調節容器的CPU Limit，實現與核心CPU Burst策略類似的效果。
Memory QoS
容器在使用記憶體時主要存在以下兩個方面的約束：
自身記憶體限制：當容器自身的記憶體（含Page Cache）接近容器上限時，會觸發核心的記憶體回收子系統，這個過程會影響容器內應用的記憶體申請和釋放的效能。
節點記憶體限制：當容器記憶體超賣（Memory Limit > Request）導致整機記憶體不足，會觸發核心的全域記憶體回收，這個過程對效能影響較大，特別是對於在離線混部情境，效能影響更大。
為了提高應用運行時效能和節點的穩定性，ack-koordinator結合Alibaba Cloud Linux提供了容器記憶體QoS保障的能力，根據Pod參數自動設定記憶體子系統（Memcg），為容器開啟Memcg QoS、記憶體後台回收和全域最低水位線分級特性，可以保障容器的記憶體資源QoS和公平性。
容器記憶體QoS提供以下功能特性：
Pod記憶體使用量接近Limit限制時，優先在後台非同步回收一部分記憶體，緩解直接記憶體回收帶來的效能影響。
Pod之間實施更公平的記憶體回收，整機記憶體資源不足時，優先從記憶體超用（Memory Usage > Request）的Pod中回收記憶體，避免個別Pod造成整機記憶體資源品質下降。
優先保障LS類型Pod的記憶體QoS，延緩LS Pod觸發整機記憶體回收的時機。如下圖所示：
memory.limit_in_bytes：記憶體使用量上限。
memory.high：記憶體限流閾值。
memory.wmark_high：記憶體後台回收閾值。
memory.min：記憶體使用量鎖定閾值。
L3 Cache及記憶體頻寬隔離
不同類型的應用程式容器在節點運行時會共用宿主機的三級緩衝L3 Cache（Last Level Cache）和記憶體頻寬MBA（Memory Bandwidth Allocation）。神龍裸金屬節點提供了動態調整容器可用的CPU緩衝LLC（Last Level Cache）和記憶體頻寬MBA（Memory Bandwidth Allocation）的能力，ack-koordinator通過對BE容器進程的細粒度資源限制，避免幹擾LS容器的效能。
後續操作
您可以參考快速入門，使用ack-koordinator快速搭建一套在離線混部環境。關於在離線混部功能的更多資訊，請參見：