本文介紹在離線混部的技術架構、混部資源模型和單機QoS保障，幫助您快速了解和使用在離線混部。
背景信息
從集群維度來看，混部是將多種應用在一個集群內部署，通過預測分析應用特性，實現業務對集群資源的充分利用；從節點維度來看，混部是將多個容器部署在同一個節點上，這些容器內的應用既包括在線類型，也包括離線類型。根據應用對資源質量需求的差異，在線應用可以歸納為延時敏感型LS（Latency Sensitive），通常對請求壓力（QPS）或訪問延遲（RT）等指標有明確的要求，對資源質量較為敏感；離線應用可以歸納為資源消耗型BE（Best Effort），通常是一些計算密集型的任務類應用，有較好的容錯重試能力，對資源質量的要求相對較為寬松。
在部署混部的過程中，不同角色的管理人員的側重點不同：
集群資源的管理員：期望可以簡化對集群資源的管理，洞察各類應用的資源容量、分配量和使用量，提升集群資源利用率，達到降低IT成本的目的。
在線類型應用的管理員：更關注容器在混合部署后的干擾問題，因為混部會更容易產生資源競爭，應用的響應時間往往會出現長尾現象（即總有一部分請求的延遲顯著地高于平均值，通常表現為響應時間的90或99分位值大幅高于平均值），導致應用服務質量下降。
離線類型應用的管理員：更期望混部系統可以提供分級可靠的資源超賣，滿足不同作業類型的差異化資源質量需求。
針對以上問題，ACK在離線混部方案提供了以下機制，可以充分滿足不同角色對混部系統的技術需求：
面向混部場景的資源優先級和服務質量模型。
穩定可靠的資源超賣機制。
細粒度的容器資源編排和隔離機制。
增強多種類型工作負載的調度能力。
技術架構
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類型的業務，可以充分利用工作負載對資源運行質量需求不同的特征，提升集群整體資源利用率。
阿里云容器服務ACK差異化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快速搭建一套在離線混部環境。關于在離線混部功能的更多信息，請參見：