混部是指將不同的業務服務根據其相關特征，部署到相同的物理機/虛擬機上，以達到盡可能在保證重點業務服務質量的前提下，提升整個集群資源利用率，進而降低總成本。根據混部的類型，可以分為在線服務的混部和在離線服務混部兩種。其中在線混部又可以分為公共集群在線業務之間的混部和隔離集群在線業務和存儲服務的混部，在離線混部主要是在線業務與離線業務進行混部。

混部作為一種業界通用的降本的手段，充滿著非常多的技術挑戰，總結如下：

• 如何對業務進行合理的分級，不同級別的服務QoS如何定義
• 如何對業務進行精細化的畫像，指導集群進行更合理的調度裝箱，降低資源爭搶的概率
• 單機如何進行內核層面的資源隔離策略，包括CPU、內存、IO、LLC cache、網絡等資源，來保障高優業務的服務質量
• 單機如何進行性能干擾檢測，指導單機驅逐和調度優化

彈性云混部詳細介紹

總體架構 

彈性云混部落地過程

階段一：公共集群在線混部

時間追溯到2017年初，當時云計算、容器、Borg、Kubernetes、Mesos 各種新技術和產品風起云涌，一時風頭無兩。滴滴順應業界潮流，加入了云計算大軍，在公司內部推動業務上云的方向，助力業務降本增效。既然要推動業務上云，那么首先要回答什么是“云”，滴滴內部有沒有“云”，當時業務都是運行在自己的物理機資源上，“云”對于滴滴來說就像它的名字一樣虛無縹緲，所以作為公司的技術底座-基礎平臺部就責無旁貸的承擔起了建立滴滴“云底座”的責任。

對于云來說，最底層的承載實體是一個一個的容器，當時容器技術，包括docker、container、cgroup 等技術相對成熟，各大公司都在使用，但對這些大規模容器集群調度和編排策略當時有多路線，比如 kubernetes，Mesos 等。滴滴內部也是選擇兩個技術路線同時演進，隨著時間的推進，越來越多的公司加入了 kubernetes 陣營，kubernetes 成為容器調度和編排的事實標準，滴滴最終選擇投入到 kubernetes 的懷抱！

隨著順風車、網約車、引擎、地圖、中臺、城運服、國際化等越來越多的業務接入彈性云，構成了彈性云混部的第一個雛形——在線業務混部。在越來越多業務接入到彈性云過程中，彈性云的部署密度越來越高，調度需求越來越多樣化，這給整個彈性云帶來了非常大的穩定性挑戰，下面分別從容器運行時環境和集群調度兩個方面進行展開介紹。

上彈性云之后，多個業務的容器同時部署在一臺物理機，大家都處于一個“混部”的環境中，為了提高資源利用率，會通過超賣等技術提升容器的部署密度，意味著同一臺物理機上會部署更多的容器，伴隨而來的是越來越嚴重的資源爭搶，業務延遲增加，以及更頻繁的毛刺出現。所以面臨的第一個重要的問題就是解決資源爭搶的問題，客觀來講，在總資源一定的情況下，提升容器部署密度，帶來資源的爭搶是必然的，也是不可避免的，所以我們要解決的問題不是消除資源爭搶，而且合理分配資源爭搶，盡量保障重點服務的運行質量，下面來看一下具體怎么解決這些問題。

彈性云分級保障體系

彈性云分級保障體系

由于當前彈性云在線公共集群整體資源超賣非常嚴重，遠超業務平均水平，建立完備的分級保障體系是進行良好混部的前提，當前分級體系的核心思路是從集群和單機兩個維度提供資源的確定性，對不同優先級的服務提供不同的資源保障程度，簡單總結如下：

• 根據服務的重要性和敏感性，對服務進行合理的分級，并制定相應的資源超賣規則。
• 單機層面資源（CPU、內存、磁盤IO、網絡、Cache 等）分配優先保障高優服務的需求。
• 集群層面對不同級別服務提供資源保障：quota 管理和管控，k8s 分級調度能力。

k8s 調度能力支撐

上圖是 k8s 調度的流程圖，調度的核心工作是為一個新創建的 pod 選擇一個最合適的 node 進行運行，整個調度流程分為兩個階段：預選策略（Predicates）和優選策略（Priorities），過程中進行各種算法策略的選擇調優，且能夠加入自己定制化的各種調度策略，下面介紹調度層面如何支撐上述混部場景。

1、調度預選策略增強

• 資源限制增強
• 大規格容器單機調度限制
• IO敏感性容器調度適配
• 真實使用率調度限制
• 宿主資源爭搶調度限制
• 集群拓撲打散增強
• 相同sts下tor打散策略
• 相同sts下node打散策略
• 機房內node平鋪打散策略
• 定向調度策略

2、調度優選策略

• ActualBalancedResourceAllocation 策略：盡可能調度到實際資源使用均衡的宿主上
• BalancedResourceAllocation 策略：盡可能調度到資源使用均衡的宿主上
• ActualLeastResourceAllocation 策略：盡可能調度到實際資源使用最少的宿主上
• LeastResourceAllocation 策略：盡可能調度到資源使用最少的宿主上
• InterPodAffinityPriority 策略：盡可能調度到帶有指定拓撲key的宿主上
• NodeAffinityPriority 策略：盡可能調度到滿足指定node affinity的宿主上
• TaintTolerationPriority 策略：盡可能調度到設置了Pod可以容器的污點的宿主上

 優選策略權重分配

3、重調度

由于 k8s 集群資源是動態變化的，比如集群擴縮容，機器置換；業務流量或部署模型變化也會導致其對資源使用情況隨之變化，比如容器利用率創新高，并且調度時無法預知后續資源需求，所以 scheduler 在進行調度時，只能根據調度當時的集群資源及運行狀態做出調度決策。除此之外，調度策略本身也可能會發生變化，如何將調度策略的變化應用于已完成的調度決策也是需要考慮的問題。因此，我們提供了重調度服務通過對集群定期巡檢發現上述場景中不再合理的調度決策，觸發調度器重新進行調度，從而使得集群整體的系統資源分配更合理。

重調度服務整體工作流程如下圖所示，重調度服務通過定期巡檢宿主/業務集群狀態，根據各個重調度策略篩選出當前需重調度的宿主，再依據一定的策略篩選出待漂移容器，向調度器發起容器變更IP漂移請求。

圖片

通過彈性云分級保障體系，調度和重調度能力支撐，目前公共集群在線業務之間的混部已經比較成熟，集群高峰期CPU使用率保持在50%左右的安全水平，具體CPU使用率的情況如下圖所示：    

A機房CPU使用率圖

階段二：公共集群在離線混部

在線集群峰值CPU使用率已經做到了50%，如果想進一步降低成本，是否還能從提升在線服務的部署密度的角度來提升CPU使用率呢？從技術方案、業界實踐、以及收益效果等多方面看，這個思路不可行，具體表現在：

• 進一步提升在線部署密度意味著更大的資源爭搶，在高峰期CPU使用率可能突破50%，到60%，甚至70%，這有非常大的穩定性隱患。大家知道，目前我們使用的物理機都是開啟了超線程（HT），同一個 core 里面的兩個超線程邏輯核其實是共享底層硬件資源的，所以理論上50%已是極限，如果進一步提升，資源爭搶帶來的各種問題就會增加，會明顯影響業務的服務質量。
• 為了降本，滴滴當前在線服務的部署密度和超賣都較高，業界在線服務超賣率基本上會控制在一個相對較低的水平，這意味著在線服務本身CPU使用率不太高。
• 即使進一步提高部署密度，更多的也是提升CPU峰值利用率，仍然有長時間的低峰期CPU沒有充分利用，這樣得到的降本收益有限。

基于上面的分析，業界更通用的做法是將在線服務和離線服務進行混部，讓離線任務充分利用在線低峰期的CPU算力，達到提升CPU平均利用率的效果，整體降本。如下圖所示，如何能把其中陰影部分算力利用起來，就成了在離線混部要解決的核心問題。

圖片

在離線混部其實是在一個存在多條件約束的場景下尋找全局最優解，它要達到以下幾個目標：

• 盡量提升在線集群的平均 CPU 使用率
• 盡量保障在線服務運行質量不受離線影響
• 兼顧一些離線運行質量的要求，不能無條件壓制離線任務

為了實現上面這些目標，在離線混部核心要解決下面幾個問題：

• 單機能力：

容器 QoS 保障：提供單機層面的資源隔離，保障在線服務的運行質量

干擾檢查能力：通過干擾指標建設，實時感知離線任務對在線業務的影響，進行必要的動作，例如資源壓制，驅逐等操作。

• 容器畫像能力：基于宿主真實利用率，構建全混部場景下的調度畫像能力，用于指導宿主機在不同時刻擁有的多種維度的混部資源。
• k8s 混部調度能力：包括靜態潮汐調度和動態調度。潮汐調度基于時間段，動態調度基于混部畫像，將混部任務調度到符合條件的宿主上，在保障穩定性的情況下提升宿主利用率。

單機 QoS 和干擾檢查能力

單機 QoS 保障主要是對 CPU、內存、磁盤 IO、網絡、Cache 等共享資源在內核層面進行隔離，減少離線任務對在線任務的影響，但既然在離線都一起運行在一個共享的環境中，資源爭搶只能減弱，不可能完全避免，所以需要建立各種資源層面的指標體系，感知干擾的發生，進而從單機和集群調度層面做一些處理。下圖展示了單機層面在資源隔離方案，爭搶指標建設，資源動調策略等方面所做的事情：

圖片

我們主要關注上圖運行時的部分，這里分成機制和策略。機制是從內核層面提供的通用能，策略是在用戶態利用這些能力根據不同的場景進行不用運用，這種設計也符合機制和策略分離的原則。資源隔離和干擾指標這塊涉及到不同的資源和內核子系統，內容較多，我重點從 CPU 隔離策略的角度展開介紹。

總體來說，CPU 隔離策略有兩種：cpuset（我們常說的大框綁核）和 cpushare（在離線共享 CPU 資源，通過精細化調度保障在線），下面談一下我對這兩種隔離策略的思考以及具體適合在什么場景上使用。

cpuset 的優點是該策略能實現兩個實體之間在 CPU 層面的強隔離（LLC cache 還是共享的，這個需要通過其他手段進行隔離），能較好的保障在線服務的運行質量。但不足是配置不太靈活，且某些場合對在線服務不友好。所以該策略主要用于在離線混部場景，還有一些對延遲特別敏感的場景，例如 redis 混部等，目前我們大數據混部和某離線任務都是采用這個方案。

cpushare 的優點是該策略從內核 CPU 調度層面保障高優先級服務的資源，不需要用戶態 agent 對資源進行調節，內核調度層面能保障毫秒級的 CPU 搶占，同時在線服務能使用所有 CPU，這樣也能避免上面介紹的段時間產生大量線程的并發問題。cpushare 方案能更好的進行資源利用，進一步提升 CPU 使用率。但不足是需要內核進行開發，邏輯比較復雜，且涉及到內核核心代碼，穩定性風險偏大，整個線上的落地周期比較長。

k8s混部調度能力

靜態潮汐調度

彈性云混部當前基于在線業務的整體潮汐現象，通過潮汐時間段對外限制混部提供的離線算力。彈性云混部通過對離線集群設置潮汐高峰期，進而通過彈性API反饋給業務從而告知業務離線容器是否可以運行。例如，以hxy機房某離線業務混部為例，混部時間段如下：

• 低峰期（可運行2個離線容器）：00:00-07:00   10:00-15:00  23:00:00-24:00:00
• 中峰期（可運行1個離線容器）：15:00-17:00    20:00-23:00
• 高峰期（可運行0個離線容器）：07:00-10:00   17:00-20:00

下圖展示不同時間段可混部的離線容器情況：

綠線2023-07-02(周日) / 藍線2023-07-03(周一)

潮汐調度策略簡單，但會存在一些問題：

• 由于每臺宿主每個時段的利用率情況并不相同，因此全局的潮汐策略使得我們一方面我們無法充分地利用宿主機的剩余資源，提供更多的算力給業務。
• 另一方面，靜態調度是固定離線容器個數，而不是根據可混部的空間來調整可運行的離線容器數量，這會導致離線容器CPU使用量超過實際可混部的空間，帶來一定的穩定性風險。

潮汐調度主要用在早期在離線混部的場景，現在線上都已轉向動態調度方案。

動態調度

動態調度是相較于靜態調度而言的，是指根據每臺宿主的資源利用率及變化動態的調整每個宿主上可以調度的離線資源。相較于現有的靜態調度限制，動態調度的優點包括：

• 可以充分利用每臺宿主的剩余資源，最大限度挖掘在離線混部的價值。
• 可以從方案的層面上避免宿主出現熱點等穩定性隱患。

動態調度的目標：

• 離線以宿主資源利用率為視角進行調度，不影響在線的quota和調度質量。
• 通過離線的動態調度將混部宿主利用率維持在穩定區間，提升資源利用率。

動態調度實現依賴下面將要介紹的容器畫像，畫像能預測出任何一個時間段某臺物理機上可以混部的算力空間，從實現方式上看，有離線水平伸縮和離線垂直伸縮兩種方式：

• 水平伸縮：根據宿主的在線利用率和畫像數據，周期性通過離線pod的動態彈性伸縮來進行調度（調度宿主上離線容器的個數）。
• 垂直伸縮：每個宿主部署一個離線pod，根據宿主的在線利用率和畫像數據，周期性通過調整離線pod的“規格”以將宿主的剩余資源充分利用。

圖片

從實現方式上來看，兩者相比：

• 水平伸縮的方式相比垂直伸縮的主要優點是可以維持離線規格的確定性，維持現有的使用體驗。但水平伸縮的主要問題為，因為當前離線pod與離線任務的生命周期不一致，頻繁的擴縮可能會導致較高的殺死率，影響業務的運行效率。
• 從資源的利用上來看，垂直伸縮的效率更高，因為其可以不受容器規格的限制，避免產生較多的碎片。同時，這種方式下，無需調整workload和離線容器因此不會產生殺死率。

當前水平伸縮方案主要用在某離線任務混部場景，垂直伸縮方案主要用在大數據混部場景，當然，后面也能根據離線業務的不同需求進行調整。

容器畫像能力

在動態調度方案中，離線可以使用的資源=混部目標利用率資源量-宿主在線服務已使用資源量。混部動態調度時，調度器會根據每個node上的離線可用資源來調度離線容器。由于宿主在線利用資源不斷變化，離線可用資源也在不斷變化，站在離線任務的角度，我們要保證離線任務執行期間離線可用資源都能滿足資源需求，所以，畫像需要給出未來一段時間內的離線可使用的資源。

通過預測算法來預測出未來1小時宿主在線服務利用資源最大值，這樣就能得到目標混部利用率前提下可混部的資源量，如下圖所示：

圖片

預測算法有7天同比算法和加權同比算法。

7天同比算法是指基于在線服務具有7天的周期性特征，使用7天前同比值作為預測值。由于誤差相對較大，目前線上已經不再使用。

加權同比算法是由于7天同比算法在利用率整體水位升高或降低時的誤差較大，在此基礎上設計的一種改進算法，該算法綜合考慮7天前歷史值，1天前歷史值和1小時前歷史值，能明顯提高預測的準確率。現在線上各機房都在使用加權同比算法，實際誤差相比7天同比算法有明顯降低。

線上混部現狀

上面提到的單機隔離、干擾檢測、容器畫像和動態調度等能力在線上的混部場景已大規模應用，目前大數據混部和某離線任務混部已穩定運行了幾年時間，下面是一些混部后的資源使用的情況，其中黃色線是通過離線混部后增加的CPU使用率，可以看到離線對CPU使用率的填谷效果非常有效。

某混部集群CPU使用率圖

階段三：隔離集群混部

前面介紹了彈性云公共集群的在混部和在離混部的情況，通過這兩種場景的混部能極大的提高公共集群的 CPU 利用率，降低成本。但公共集群資源只占彈性云整體資源池的一部分，還有大量的隔離集群，且隔離集群的利用率普遍非常低，所以這一塊就成了混部和降低的重點方向。

先介紹下隔離集群，公共集群是各種不同業務混在一起運行的公共資源池，但有些服務，比如存儲的 redis、mq，還有接入層等服務對延遲非常敏感，公共集群環境無法滿足它們對服務質量的要求，于是就專門隔離出一塊資源池給某個服務單獨使用，這樣就能保障該服務的服務質量。但由于這些服務單獨部署，資源使用率非常低，造成了資源和成本的浪費，下面是一些典型的隔離集群 CPU 使用率情況：

圖片

圖片

圖片

可以看出，隔離集群 CPU 使用率處于非常低的水平，存在大量的可混部空間。看到這里，可能有同學會問，既然有這么多混部空間，為啥不早點干呢？這里需要從隔離集群運行業務的特點說起，一般情況下隔離集群業務都是非常敏感，而且穩定性要求較高，比如 redis 服務，它對延遲非常敏感，對干擾幾乎是零容忍，而且 redis 這種業界一般都是不進行混部，通過犧牲一部分成本來保運行質量和穩定性。Redis 資源占隔離集群資源的大頭，對這塊的混部我們一直在驗證嘗試，但始終保持比較謹慎的態度。

今年降本增效進入深水區，我們也開始將之前的各種技術積累和驗證真正在隔離集群混部上落地。由于隔離集群業務的特性，我們將隔離集群混部拆解成多個階段：

• 在線業務與存儲業務混部：調度公共集群一些相對低優的在線服務到隔離集群和存儲物理機集群，是峰值CPU使用率達到公共集群的水平。
• 全混部：進一步調度離線任務到已經進行混部的的隔離集群，進一步提升平均CPU使用率，最終達到無差別全混部。

當前我們正處在前一個階段，這個階段的核心目標是提升隔離集群的 CPU 峰值利用率，如下圖，使用通過混部的在線業務將紅框這部分資源利用起來。

圖片

從技術層面來說，隔離集群混部也會涉及到 k8s 調度，單機保障，還有穩定性兜底方案等方面，下面分別介紹。

k8s 調度支撐

在隔離集群混部場景下，k8s 調度的主要目標如下：

• 將混部的在線服務調度到隔離集群，整體根據利用率調度，保證利用率不超過設定的混部目標。
• 混部調度不能影響隔離集群原始業務的調度容量和質量，例如裝箱率和原始打散策略等。

核心調度策略

• 真實利用率調度
• 混部側根據混部目標利用率和畫像計算每臺 node 上“常駐混部”資源，并寫入自定義資源 mix-mid-cpu
• 根據歷史7天最大利用率在 pod 上注入此 pod 可能占用的資源
• 通過 mix-mid-cpu 等自定義資源進行調度限制

圖片

• 單機容器數量限制卡點解決方案
• 一些隔離集群，例如 redis 都會設置單機容器數量上線，由于混部容器的加入，這些限制可能會打破。調度側可以根據不同的情況對混部服務繞過單機容器數量限制，或根據預測的混部容器數量今天單機容器數量限制的調整。
• 調度規則引擎策略注入
• 由于調度規則是通用的，正常情況下公共集群的服務無法調度到隔離集群，而且即使強行調度，也會存在非常多的通用卡點，這些卡點在隔離集群并不適用，需要進行一些適配，典型場景包括：容忍隔離集群的污點，對這些服務打通公共集群與隔離集群的通道；跳過一些公共集群默認卡點；不占用物理機真實使用率畫像；設置混部相關的標簽等。

重調度

由于隔離集群服務一般屬于高優服務，混部在線服務后需要重調度進行基本的兜底。重調度需要對混部的隔離集群增加基本的熱點處理能力，此處對重調度的需求：

• 對隔離集群服務維持原生重調度策略，做到混部對隔離集群透明。
• 對混部上來的服務需要基于根據CPU／內存／磁盤等利用率閾值（可配）進行重調度保障，進行必要的熱點漂移。

單機服務質量保障

單機服務質量保障主要還是從內核資源隔離曾經進行的，總體來說，單機隔離基本還是在混部和在離混部那一套體系，由于當前隔離集群混部是混部在線服務，在 CPU 這塊默認會使用 cpusare 機制，通過分級保障體系來保障服務質量，但對于 redis 這種特別敏感的服務，我們也采用了更為保守的 CPU 大框方案，并會保障 redis 實例不超賣的總體原則。

同時為了避免混部容器利用率突增導致整機 CPU 使用率突破混部目標，進而影響隔離集群原始服務的運行質量，在單機層面也引入了單機壓制的能力，當檢測到因混部容器導致物理機 CPU 使用率異常的時候，就會對混部容器進行壓制，甚至驅逐，保障整體可控。

穩定性兜底保障

由于隔離集群敏感業務混部在滴滴是第一次嘗試，很多方案都是在一步一步演進過程中，所以穩定性兜底方案就顯得尤為重要。這里我重點介紹穩定性兜底方案-混部容器驅逐邏輯，整體驅逐流程如下圖所示：

圖片

主要包括以下幾部分：

• 驅逐觸發條件
• 業務指標：如果隔離集群原生業務的業務指標出現異常，是一個重要的信號，當然并不是業務指標已出現問題就是混部導致的，這里我們也會有很多資源層面的指標來輔助判斷。
• 混部水位：如果資源利用率已經超過了預設的混部水位，也需要進行容器的驅逐。
• 干擾檢測：如果通過自定義的一些干擾指標發現存在明顯混部容器產生的干擾，就需要將相應的容器進行驅逐。
• 人工強制觸發：某些場景下需要進行強制驅逐，也需要提供對這種場景的支持。
• 驅逐核心邏輯管理
• 局部驅逐：這種情況下，不需要驅逐node上所有pod，需要準確找到最合適的驅逐對象，一般會考慮到下面這些因素，pod的優先級，pod利用率，pod的干擾指標等。
• node驅逐：物理機上出現嚴重問題，需要盡快將某個node上的所有混部容器庫快速驅逐。
• 服務驅逐：比如某個混部服務本身出現了問題，需要將這個服務的所有實例都驅逐到IDC或公有云。
• 驅逐目的地
• 混部集群：這種情況下混部容器被驅逐后還是會調度到混部集群的其他node上。
• 自建IDC公共集群：這種情況下混部容器被驅逐后會調度到IDC公共集群。
• 公有云：這種情況下混部容器被驅逐后會調度公有云上。

由于未來自建IDC公共集群的容量有限，并且公有云需要額外購買資源，存在成本增加，所以總體來說驅逐目的優先級是：混部集群>自建IDC公共集群>公有云，如果不是全局性問題，還是盡快在混部集群內部進行驅逐。

彈性云混部未來展望

隨著未來穩態上云計劃的推動，公共集群規模可能保持現狀或適當的減少，未來各種隔離集群會是混部的重點算力來源，這里還是使用上面一張圖來說明彈性云混部的未來展望。

圖片

在這張圖中，每種混部實體都能找到自己的位置：

• total：表示物理機總資源量
• limit：表示可以提供給混部使用的資源量，limit與total之間是預留的穩定性buffer
• mid：這部分就是給混部的在線服務使用，他們主要是用來提升峰值CPU使用率
• Batch：這部分是給離線服務使用，他們主要用來提升均值CPU使用率
• Prod：這條紅線是隔離集群服務本身的CPU使用率，由于服務特點，他們的使用率整體不高

這就是我們未來的全混部思路，由于更多種類的服務運行在一起，對技術能力提出了更大的挑戰，未來會進一步增強集群調度、服務畫像、單機隔離、干擾檢測、異常感知等方面。