1. 什么是在離線混部
混部概念中將應用類型分為在線業務和離線業務兩種。
在線和離線業務如何劃分？在百度內部，我們認為在線業務特點包括但不限于：運行時間長，延時敏感，對穩定向要求較高，服務不穩定業務會立馬感知并且帶來損失，有明顯的波峰波谷，白天高，深夜低，比如廣告搜索業務；而離線業務的特點包括但不限于非延時敏感，可重試，運行時間一般較短在幾十分鐘左右，內部一般為大數據計算，機器學習等服務。
在線業務以搜索為例，白天用戶工作學習時查詢量會非常大，但是當大部分用戶夜間休息時，查詢量相對白天就會變得非常小，此時我們就可以引入離線業務。離線業務沒有嚴格的時間要求，隨時都能跑，用戶關心的是任務能不能跑完，對于什么時候跑完并沒有太大的需求，同時如果單機上資源有沖突，此時我們會壓制離線業務，甚至會驅逐離線業務，這對用戶是無感的，計算平臺重新拉起任務，繼續計算。
因此，在線型業務和離線業務具備資源互補的特點，從時間上和對資源的容忍度上可以完美的結合到一起。一方面，在線業務的優先級更高，單機和調度層面會優先保障在線的資源，可能會對離線進行壓制和驅逐，另一方面，對于離線任務來說，壓制和驅逐對用戶是無感的，只需要保證任務順利完成，有很高的容忍度。
簡單來說，將在線業務和離線任務混合混部到相同物理資源上，通過資源隔離、調度等控制手段 , 充分使用資源，同時保證服務的穩定性，我們稱這樣的技術為“混部”。
2. 資源利用率為何不高？
純在線業務集群的平均利用率普遍不高，百度應用混部技術之前，在線業務集群CPU利用率普遍在20%左右，造成這種現象主要由一下幾種原因：2.1 潮汐現象和冗余在線業務在申請資源的時候，一般是按照最高峰值評估資源去申請資源，同時還會上調一些，這就導致了業務對資源預估不準，申請的資源遠大于實際使用資源。甚至可能會部署多個副本作為災備。此時的低峰時利用率就會非常低，導致整體利用率不高。2.2 在離線分池一般來說機房規劃的時候有一個非常大的特點，就是離線機房與在線機房分離做規劃。舉個例子，假如我們在寧夏做一個機房，這個時候肯定會考慮做一個離線機房，因為在線機房需要考慮網民請求地域分布的問題，要獲得最好的訪問優化體驗以及訪問速度，勢必需要在一些訪問熱點上去做自己的在線機房規劃，比如北京、上海、廣州等。而對于離線機房來說不用關心這些，它最在乎的是如何提升計算和儲存的資源和基礎設施的規模，所以在線業務和離線業務本身的資源需求和特點不一樣，資源利用率非常不均衡。常態表現就是在線利用率低，離線利用率高，且常態資源不足。針對以上場景，我們通過在離線混部技術將在離線資源統一資源池，把離線作業部署在在線資源池節點上，充分利用機器資源，達到了提升資源利用率的目的。
3.百度云原生混部詳解
隨著 Kubernetes（以下簡稱「K8s」） 生態的蓬勃發展，百度很多業務已經搭建并且運維了自己的諸多 K8s 集群，同時也遇到了一些問題，比如上面所說的資源利用率不高。我們根據內部積累混部經驗對 K8s 進行在離線混部原生化改造，做到了零入侵K8s，可移植，可支持大規模集群。
混部系統架構圖
3.1 如何做到資源復用？
原生 K8s 基于靜態視圖分配
上圖顯示了一個節點的 CPU 使用率和分配率，分配率為89%， 使用率在0-16點之間都在20%以下，17點開始是用量高峰，在30-40%之間?？梢钥闯?request 和 used 之間有大量的資源處于閑置狀態，如果想讓這部分資源可以重復利用起來，就需要調度更多的 Pod 上去，但是從 K8s 調度器視角來看，已經沒有更多的 CPU 分給 Pod了。
如果部署 request 和 limit 都不填寫的 Pod，此時它可以被調度，但是 K8s 針對這種 BestEffort 的 Pod 不會根據用量調度，可能會被調度到一個實際很繁忙的節點上，非但無法起到提升使用率的效果，可能還會加劇節點上服務的延遲。
動態資源視圖
針對 K8s 無法根據資源使用量分配資源，我們引入了動態資源視圖。
在混部調度中，在線和離線使用相同的物理資源，在線看到的資源視圖和離線看到的資源視圖相互獨立。在線業務看到的可用資源依舊為整機資源進行靜態分配，離線看到的可用資源為整機資源減去在線作業已經使用的資源。
從圖中可以看出，在線申請用量和在線usage之間存在很大的差異，主要是由于研發同學部署業務選擇容器資源規格時，帶有一定的盲目性，申請量高于實際使用資源量或者按照超出峰值用量申請。混部離線可以復用這部分可回收資源，通過快速填充離線作業，把這部分資源利用起來。
高中優(在線)為靜態分配 ∑High request + ∑Medium request <= Host Quota
動態計算低優(離線)可用量 Low Quota = Host Quota - ∑High used - ∑Medium used
注：以上是理想情況下的公式，實際應用中需要對離線使用量設置一個上限，此處排除了上限造成的影響。下面會有單機資源管理的說明。
由于 K8s 是靜態分配，在 K8s 的 QOS 模型中 BestEffort 是不占用 request 的，即使一個 node 上即使資源已經分配完，但是 BestEffort 類型的資源依然可以調度上去，所以我們復用了 BestEffort 模型給離線任務使用，如上文架構圖所示，這樣有以下的優點：
- 解決了在離線視圖沖突問題，離線使用的 BestEffort 模型，對在線不可見
- 兼容社區組件，比如 cadvisor 可以直接使用
- 無需修改已有組件，包括 kubelet containerd runc，侵入性小，可以直接安裝混部系統，享受混部帶來的資源效能提升。
3.2 優先級
由于在離線業務同時部署在相同節點上可能會產生干擾，我們從調度和單機兩個方面對在線離線做了優先級區分。
大的優先級分為(高，中，低)三種，其中高優中優為在線業務，低優為離線業務。每個優先級優化分若干小優先級。
首先看一下 K8s 的 QOS 模型
- Guaranteed : 當 Pod 中所有 Container 的 request == limit 時
- Burstable : 當 Pod 中存在 Container 的 request != limit 時
- BestEffort : 當 Pod 中所有 Container 均未設置 request, limit 時
對比 K8s 模型，百度混部調度器做了如下擴展：
3.3 資源隔離
由于在離線混部是將在線業務和離線任務混合混部到相同物理資源上，所以在離線業務由于流量激增，出現資源爭搶時，如何保證在線的SLA不受影響，并且在保證在線服務的SLA時，也要保證離線任務的整體質量，保證離線作業的成功率和耗時。
CPU
cpuset 編排
針對于需要綁核的在線業務，單機上可以感知到 CPU 拓撲，不需要 kubelet 開啟綁核機制，可以直接進行綁核，會將在線業務盡量綁在同一 NUMA node 上，避免跨 node 通信延遲。
NUMA 調度
NUMA 是一種內存管理技術，在 NUMA 架構下 CPU 被劃分為多個 node，每個 node 都有各自的 CPU core 和 local memory，node core 中的進程訪問 local memory 和 remote memory 的代價是不一樣的。節點的所有內存對于本節點所有的 CPU 都是等同的，對于其他節點中的所有 CPU 都不同。因此每個 CPU 可以訪問整個系統內存，但是訪問本地節點的內存速度最快(不經過互聯模塊)，訪問非本地節點的內存速度較慢(需要經過互聯模塊)，即CPU 訪問內存的速度與節點的距離有關。
針對開啟了 NUMA 的節點，我們感知 NUMA 架構，將在線業務綁在同一 NUMA 上，提升在線業務的性能，并且感知 NUMA 節點的負載，當 node 之間出現明顯的不平衡時，進行重調度。
離線調度器
在線業務要求實時性高，延遲低；為了保證低延遲，CPU 負載不會打的特別高，當 CPU 負載升高時，在線間干擾會導致延時增大。而離線業務一般 CPU 利用率高，但是重吞吐不重延時。所以如果能滿足在線的延時保障，在線和離線跑在一個核上不會對在線造成干擾，那么可以極大的提升資源利用率。
按照現在通用的 linux 內核調度器調度算法，無法給在線服務做 CPU 的強保障，無法區分在離線業務，會導致在線無法搶占離線 CPU，并且在負載均衡時，因為無法區分在離線業務，可能在線業務會分配到相同的核上，無法打散。導致性能下降。
離線調度器是一種離線任務專用的CPU調度算法，從調度器上分開，在線調度器看不到離線任務。在線調度器先于離線調度器進行任務調度，存在在線任務時，離線得不到調度。所以對于在線任務來說，可以達到混部前相近的CPU 質量。
內存
Linux 系統會經常執行一些寫日志、生成備份文件的工作，當這些文件比較大時相應的 cache 就會占用大量的系統內存，而且這些類型的 cache 并不會被經常訪問，所以系統會定期將這些 cache flush 到磁盤中。Linux 會通過cache 回收算法進行回收。這會造成兩個問題：
1.容器的 page cache 得不到回收，它依賴于容器管理 page cache 的機制是需要才去回收的方式，即沒有后臺回收，每次都是分配時候發現到達 limit 了，在 alloc 的時候出發回收，如果業務壓力較大，分配的速度大于回收的速度，就可能出現 OOM 的問題
2.cache 回收時并不會區分在線離線業務，會導致在線業務的 cache 可能會被先于離線 cache 回收掉，如果在線有大量的讀 cache 行為，會造成 cache 命中降低，直接進行讀盤操作，會導致在線業務的性能下降，甚至會導致IO 夯住。
為了解決以上的問題，我們新增了背景回收機制，背景回收指的是異步回收 cache，根據在線離線的 QOS 不同，設置不同的背景回收水位，優先回收離線業務的 cache。
- 每個容器后臺周期自動回收自己產生的 page cache
- 每個容器都可以設置開關和自己的高低水位線
網絡層面我們也開發了容器級別的出入網帶寬限制和流量打標等 Cgroup 子系統，可以對離線進行流量限制。
更多的內核隔離見下圖：
基于 eBPF 的動態策略
現有的內核隔離策略都是基于 QOS，創建容器時進行 cgroup 配置，由內核進行統一的資源管理，但是某些高敏業務在最高優先級的 QOS 下也無法保證其特定資源，或者需要某一緯度的資源需要高優保證，此時通用隔離策略無法滿足。
另外由于隔離調度策略是全局統一的策略，業務如果想根據自身特點修改一些隔離能力，只能由業務反饋平臺，平臺對底層進行修改，周期較長，并且全局應用的隔離能力可能會對離線或者其他業務造成誤傷，所以把隔離提升到用戶態更符合業務需求。
針對這樣的場景，由于 eBPF 穩定，安全，高效，并有可熱加載/卸載 eBPF 程序，無需重啟 Linux 系統的特性，我們基于 eBPF 開發了定制策略，可以實時下發，實時生效，侵入性小，不需要對業務既有服務和平臺側進行修改?？梢栽谟脩魬B針對某些業務進行定制化隔離策略更新，達到服務可以無差別混部的目標。
單機資源管理
在混部時，離線可以占用多少資源一直是一個問題。機型不同，在線服務的敏感度不同，離線業務占用的資源多少對在線造成的影響也不盡相同，針對這種情況，我們對集群緯度，池(具有相同特性的一批機器)緯度，節點緯度對離線可用資源上限做了限制，其中粒度最小優先級最高。
以 CPU 為例，如下圖：
我們設置了整機的 CPU 閥值X，當整機 CPU 用量趨近或超過一定用量，比如X=50%時，會壓縮離線使用的CPU資源。
列舉一個簡單的公式：
Offline Quota = Host Quota * X - ∑NotOffline Used
Offline Free = Offline Quota - ∑Offline used
同樣，對于 Memory，IO和網絡我們也做了同樣的限制。這樣我們可以根據不同的機型和業務很方便的調整離線的用量，避免在線用量升高時性能受到影響。
3.4 高性能調度器
在線和離線業務的調度需求是不一樣的，在線一般為常駐服務，不會頻繁變更，對調度器要求較低。但是離線任務由于具有運行時間短(幾分鐘到幾小時)，任務多的特點，以 K8s 默認調度器的調度性能不足以支撐離線任務的調度。所以我們開發了高性能的離線調度器，計算可以達到5000 ops。
如上圖所示，我們調度了15W個 Pod，計算性能可以達到5k ops， 為了防止調度速度過快，對 ETCD 和整個集群造成壓力，我們限制了binding速度為1500 ops。
3.5 資源畫像
單機資源隔離是針對已經調度到節點上的任務進行隔離，如果檢測到離線任務對在線產生一定的影響后，會很快響應對離線任務進行壓制和驅逐的操作。這樣會影響離線任務的穩定性。針對這種場景，如果在調度時可以預測到節點上未來一段時間的在線使用量，可以針對性的調度離線任務。
對比實時計算的資源模型，假設離線作業的運行時間為1小時，如果資源模型使用實時的資源視圖，如果在線作業會在半個小時候用量升高，那么當離線作業運行半個小時之后，資源被在線壓制，運行質量受影響。
我們預測了未來1小時窗口內的在線資源用量，調度適當的離線任務上去，即可確保任意離線作業運行過程中資源不受任何壓制，從而達到提升運行質量的目的。
如何提供更穩定的超發資源，則取決于我們資源預測的準確度是什么樣的。
不僅離線調度需要資源畫像，在線調度也需要資源畫像，通過資源畫像可以有效的避免熱點產生。
- 對于在線調度來說，調度的主要目標是提升服務的可用性，在調度時使用資源畫像來預測未來一個周期內的用量，可以避免熱點問題(某一緯度的資源用量過高)，并且在重調度時也可以規避熱點問題。
- 對于離線調度來說，調度的主要目標是提升集群的吞吐，降低作業的排隊時間和執行時間，所以資源畫像可以提升離線作業的穩定性，避免驅逐重新調度和資源壓制導致執行時間過長。
4.未來展望
百度目前混部規模數十萬臺，它的混部集群 CPU 利用率比在線利用率提升 40%—80%，累計節省近10萬臺服務器。
未來百度混部的主要目標是繼續擴大混部的規模，更大規模地節約資源成本，可以支持更多的負載類型，不局限于在離線混部，要做到無差別混部。
- 在單機隔離方面，支持更多的業務進入混布，在檢測沖突和資源隔離方面做的更好。
- 調度方面做更有計劃的調度，資源畫像更加精細化，調度時可以更精準的預測熱點概率，優化調度能力，減少熱點率。
并在以下方向投入更多的力量：
- 內核可編程技術：
通過 eBPF 可觀測技術的創新，實現混部容器負載性能的近距離觀察，達到進一步無損高密度混
利用 eBPF 熱加載/卸載的特性，可以用戶態下發隔離策略，快速的解決高敏的資源質量問題
- 異構：更好的支持GPU等異構資源混部，提高異構資源效能與彈性，大幅降低GPU成本。
- 容器虛機融合：解決高密機型共享內核混部的瓶頸。
- 多云混部：結合公有云進行極致的彈性，例如結合彈性競價實例，基于用戶對價格的敏感度設置，自動納入或者摘除競價實例，用于離線業務運行或混部，實現多云彈性混部。
