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

混部作為一種業(yè)界通用的降本的手段，充滿著非常多的技術(shù)挑戰(zhàn)，總結(jié)如下：

• 如何對業(yè)務(wù)進(jìn)行合理的分級，不同級別的服務(wù)QoS如何定義
• 如何對業(yè)務(wù)進(jìn)行精細(xì)化的畫像，指導(dǎo)集群進(jìn)行更合理的調(diào)度裝箱，降低資源爭搶的概率
• 單機(jī)如何進(jìn)行內(nèi)核層面的資源隔離策略，包括CPU、內(nèi)存、IO、LLC cache、網(wǎng)絡(luò)等資源，來保障高優(yōu)業(yè)務(wù)的服務(wù)質(zhì)量
• 單機(jī)如何進(jìn)行性能干擾檢測，指導(dǎo)單機(jī)驅(qū)逐和調(diào)度優(yōu)化

彈性云混部詳細(xì)介紹

總體架構(gòu) 

彈性云混部落地過程

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

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

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

隨著順風(fēng)車、網(wǎng)約車、引擎、地圖、中臺、城運(yùn)服、國際化等越來越多的業(yè)務(wù)接入彈性云，構(gòu)成了彈性云混部的第一個(gè)雛形——在線業(yè)務(wù)混部。在越來越多業(yè)務(wù)接入到彈性云過程中，彈性云的部署密度越來越高，調(diào)度需求越來越多樣化，這給整個(gè)彈性云帶來了非常大的穩(wěn)定性挑戰(zhàn)，下面分別從容器運(yùn)行時(shí)環(huán)境和集群調(diào)度兩個(gè)方面進(jìn)行展開介紹。

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

彈性云分級保障體系

彈性云分級保障體系

由于當(dāng)前彈性云在線公共集群整體資源超賣非常嚴(yán)重，遠(yuǎn)超業(yè)務(wù)平均水平，建立完備的分級保障體系是進(jìn)行良好混部的前提，當(dāng)前分級體系的核心思路是從集群和單機(jī)兩個(gè)維度提供資源的確定性，對不同優(yōu)先級的服務(wù)提供不同的資源保障程度，簡單總結(jié)如下：

• 根據(jù)服務(wù)的重要性和敏感性，對服務(wù)進(jìn)行合理的分級，并制定相應(yīng)的資源超賣規(guī)則。
• 單機(jī)層面資源（CPU、內(nèi)存、磁盤IO、網(wǎng)絡(luò)、Cache 等）分配優(yōu)先保障高優(yōu)服務(wù)的需求。
• 集群層面對不同級別服務(wù)提供資源保障：quota 管理和管控，k8s 分級調(diào)度能力。

k8s 調(diào)度能力支撐

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

1、調(diào)度預(yù)選策略增強(qiáng)

• 資源限制增強(qiáng)
• 大規(guī)格容器單機(jī)調(diào)度限制
• IO敏感性容器調(diào)度適配
• 真實(shí)使用率調(diào)度限制
• 宿主資源爭搶調(diào)度限制
• 集群拓?fù)浯蛏⒃鰪?qiáng)
• 相同sts下tor打散策略
• 相同sts下node打散策略
• 機(jī)房內(nèi)node平鋪打散策略
• 定向調(diào)度策略

2、調(diào)度優(yōu)選策略

• ActualBalancedResourceAllocation 策略：盡可能調(diào)度到實(shí)際資源使用均衡的宿主上
• BalancedResourceAllocation 策略：盡可能調(diào)度到資源使用均衡的宿主上
• ActualLeastResourceAllocation 策略：盡可能調(diào)度到實(shí)際資源使用最少的宿主上
• LeastResourceAllocation 策略：盡可能調(diào)度到資源使用最少的宿主上
• InterPodAffinityPriority 策略：盡可能調(diào)度到帶有指定拓?fù)鋕ey的宿主上
• NodeAffinityPriority 策略：盡可能調(diào)度到滿足指定node affinity的宿主上
• TaintTolerationPriority 策略：盡可能調(diào)度到設(shè)置了Pod可以容器的污點(diǎn)的宿主上

 優(yōu)選策略權(quán)重分配

3、重調(diào)度

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

重調(diào)度服務(wù)整體工作流程如下圖所示，重調(diào)度服務(wù)通過定期巡檢宿主/業(yè)務(wù)集群狀態(tài)，根據(jù)各個(gè)重調(diào)度策略篩選出當(dāng)前需重調(diào)度的宿主，再依據(jù)一定的策略篩選出待漂移容器，向調(diào)度器發(fā)起容器變更IP漂移請求。

圖片

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

A機(jī)房CPU使用率圖

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

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

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

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

圖片

在離線混部其實(shí)是在一個(gè)存在多條件約束的場景下尋找全局最優(yōu)解，它要達(dá)到以下幾個(gè)目標(biāo)：

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

為了實(shí)現(xiàn)上面這些目標(biāo)，在離線混部核心要解決下面幾個(gè)問題：

• 單機(jī)能力：

容器 QoS 保障：提供單機(jī)層面的資源隔離，保障在線服務(wù)的運(yùn)行質(zhì)量

干擾檢查能力：通過干擾指標(biāo)建設(shè)，實(shí)時(shí)感知離線任務(wù)對在線業(yè)務(wù)的影響，進(jìn)行必要的動(dòng)作，例如資源壓制，驅(qū)逐等操作。

• 容器畫像能力：基于宿主真實(shí)利用率，構(gòu)建全混部場景下的調(diào)度畫像能力，用于指導(dǎo)宿主機(jī)在不同時(shí)刻擁有的多種維度的混部資源。
• k8s 混部調(diào)度能力：包括靜態(tài)潮汐調(diào)度和動(dòng)態(tài)調(diào)度。潮汐調(diào)度基于時(shí)間段，動(dòng)態(tài)調(diào)度基于混部畫像，將混部任務(wù)調(diào)度到符合條件的宿主上，在保障穩(wěn)定性的情況下提升宿主利用率。

單機(jī) QoS 和干擾檢查能力

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

圖片

我們主要關(guān)注上圖運(yùn)行時(shí)的部分，這里分成機(jī)制和策略。機(jī)制是從內(nèi)核層面提供的通用能，策略是在用戶態(tài)利用這些能力根據(jù)不同的場景進(jìn)行不用運(yùn)用，這種設(shè)計(jì)也符合機(jī)制和策略分離的原則。資源隔離和干擾指標(biāo)這塊涉及到不同的資源和內(nèi)核子系統(tǒng)，內(nèi)容較多，我重點(diǎn)從 CPU 隔離策略的角度展開介紹。

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

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

cpushare 的優(yōu)點(diǎn)是該策略從內(nèi)核 CPU 調(diào)度層面保障高優(yōu)先級服務(wù)的資源，不需要用戶態(tài) agent 對資源進(jìn)行調(diào)節(jié)，內(nèi)核調(diào)度層面能保障毫秒級的 CPU 搶占，同時(shí)在線服務(wù)能使用所有 CPU，這樣也能避免上面介紹的段時(shí)間產(chǎn)生大量線程的并發(fā)問題。cpushare 方案能更好的進(jìn)行資源利用，進(jìn)一步提升 CPU 使用率。但不足是需要內(nèi)核進(jìn)行開發(fā)，邏輯比較復(fù)雜，且涉及到內(nèi)核核心代碼，穩(wěn)定性風(fēng)險(xiǎn)偏大，整個(gè)線上的落地周期比較長。

k8s混部調(diào)度能力

靜態(tài)潮汐調(diào)度

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

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

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

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

潮汐調(diào)度策略簡單，但會(huì)存在一些問題：

• 由于每臺宿主每個(gè)時(shí)段的利用率情況并不相同，因此全局的潮汐策略使得我們一方面我們無法充分地利用宿主機(jī)的剩余資源，提供更多的算力給業(yè)務(wù)。
• 另一方面，靜態(tài)調(diào)度是固定離線容器個(gè)數(shù)，而不是根據(jù)可混部的空間來調(diào)整可運(yùn)行的離線容器數(shù)量，這會(huì)導(dǎo)致離線容器CPU使用量超過實(shí)際可混部的空間，帶來一定的穩(wěn)定性風(fēng)險(xiǎn)。

潮汐調(diào)度主要用在早期在離線混部的場景，現(xiàn)在線上都已轉(zhuǎn)向動(dòng)態(tài)調(diào)度方案。

動(dòng)態(tài)調(diào)度

動(dòng)態(tài)調(diào)度是相較于靜態(tài)調(diào)度而言的，是指根據(jù)每臺宿主的資源利用率及變化動(dòng)態(tài)的調(diào)整每個(gè)宿主上可以調(diào)度的離線資源。相較于現(xiàn)有的靜態(tài)調(diào)度限制，動(dòng)態(tài)調(diào)度的優(yōu)點(diǎn)包括：

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

動(dòng)態(tài)調(diào)度的目標(biāo)：

• 離線以宿主資源利用率為視角進(jìn)行調(diào)度，不影響在線的quota和調(diào)度質(zhì)量。
• 通過離線的動(dòng)態(tài)調(diào)度將混部宿主利用率維持在穩(wěn)定區(qū)間，提升資源利用率。

動(dòng)態(tài)調(diào)度實(shí)現(xiàn)依賴下面將要介紹的容器畫像，畫像能預(yù)測出任何一個(gè)時(shí)間段某臺物理機(jī)上可以混部的算力空間，從實(shí)現(xiàn)方式上看，有離線水平伸縮和離線垂直伸縮兩種方式：

• 水平伸縮：根據(jù)宿主的在線利用率和畫像數(shù)據(jù)，周期性通過離線pod的動(dòng)態(tài)彈性伸縮來進(jìn)行調(diào)度（調(diào)度宿主上離線容器的個(gè)數(shù)）。
• 垂直伸縮：每個(gè)宿主部署一個(gè)離線pod，根據(jù)宿主的在線利用率和畫像數(shù)據(jù)，周期性通過調(diào)整離線pod的“規(guī)格”以將宿主的剩余資源充分利用。

圖片

從實(shí)現(xiàn)方式上來看，兩者相比：

• 水平伸縮的方式相比垂直伸縮的主要優(yōu)點(diǎn)是可以維持離線規(guī)格的確定性，維持現(xiàn)有的使用體驗(yàn)。但水平伸縮的主要問題為，因?yàn)楫?dāng)前離線pod與離線任務(wù)的生命周期不一致，頻繁的擴(kuò)縮可能會(huì)導(dǎo)致較高的殺死率，影響業(yè)務(wù)的運(yùn)行效率。
• 從資源的利用上來看，垂直伸縮的效率更高，因?yàn)槠淇梢圆皇苋萜饕?guī)格的限制，避免產(chǎn)生較多的碎片。同時(shí)，這種方式下，無需調(diào)整workload和離線容器因此不會(huì)產(chǎn)生殺死率。

當(dāng)前水平伸縮方案主要用在某離線任務(wù)混部場景，垂直伸縮方案主要用在大數(shù)據(jù)混部場景，當(dāng)然，后面也能根據(jù)離線業(yè)務(wù)的不同需求進(jìn)行調(diào)整。

容器畫像能力

在動(dòng)態(tài)調(diào)度方案中，離線可以使用的資源=混部目標(biāo)利用率資源量-宿主在線服務(wù)已使用資源量?；觳縿?dòng)態(tài)調(diào)度時(shí)，調(diào)度器會(huì)根據(jù)每個(gè)node上的離線可用資源來調(diào)度離線容器。由于宿主在線利用資源不斷變化，離線可用資源也在不斷變化，站在離線任務(wù)的角度，我們要保證離線任務(wù)執(zhí)行期間離線可用資源都能滿足資源需求，所以，畫像需要給出未來一段時(shí)間內(nèi)的離線可使用的資源。

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

圖片

預(yù)測算法有7天同比算法和加權(quán)同比算法。

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

加權(quán)同比算法是由于7天同比算法在利用率整體水位升高或降低時(shí)的誤差較大，在此基礎(chǔ)上設(shè)計(jì)的一種改進(jìn)算法，該算法綜合考慮7天前歷史值，1天前歷史值和1小時(shí)前歷史值，能明顯提高預(yù)測的準(zhǔn)確率?，F(xiàn)在線上各機(jī)房都在使用加權(quán)同比算法，實(shí)際誤差相比7天同比算法有明顯降低。

線上混部現(xiàn)狀

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

某混部集群CPU使用率圖

階段三：隔離集群混部

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

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

圖片

圖片

圖片

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

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

• 在線業(yè)務(wù)與存儲業(yè)務(wù)混部：調(diào)度公共集群一些相對低優(yōu)的在線服務(wù)到隔離集群和存儲物理機(jī)集群，是峰值CPU使用率達(dá)到公共集群的水平。
• 全混部：進(jìn)一步調(diào)度離線任務(wù)到已經(jīng)進(jìn)行混部的的隔離集群，進(jìn)一步提升平均CPU使用率，最終達(dá)到無差別全混部。

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

圖片

從技術(shù)層面來說，隔離集群混部也會(huì)涉及到 k8s 調(diào)度，單機(jī)保障，還有穩(wěn)定性兜底方案等方面，下面分別介紹。

k8s 調(diào)度支撐

在隔離集群混部場景下，k8s 調(diào)度的主要目標(biāo)如下：

• 將混部的在線服務(wù)調(diào)度到隔離集群，整體根據(jù)利用率調(diào)度，保證利用率不超過設(shè)定的混部目標(biāo)。
• 混部調(diào)度不能影響隔離集群原始業(yè)務(wù)的調(diào)度容量和質(zhì)量，例如裝箱率和原始打散策略等。

核心調(diào)度策略

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

圖片

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

重調(diào)度

由于隔離集群服務(wù)一般屬于高優(yōu)服務(wù)，混部在線服務(wù)后需要重調(diào)度進(jìn)行基本的兜底。重調(diào)度需要對混部的隔離集群增加基本的熱點(diǎn)處理能力，此處對重調(diào)度的需求：

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

單機(jī)服務(wù)質(zhì)量保障

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

同時(shí)為了避免混部容器利用率突增導(dǎo)致整機(jī) CPU 使用率突破混部目標(biāo)，進(jìn)而影響隔離集群原始服務(wù)的運(yùn)行質(zhì)量，在單機(jī)層面也引入了單機(jī)壓制的能力，當(dāng)檢測到因混部容器導(dǎo)致物理機(jī) CPU 使用率異常的時(shí)候，就會(huì)對混部容器進(jìn)行壓制，甚至驅(qū)逐，保障整體可控。

穩(wěn)定性兜底保障

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

圖片

主要包括以下幾部分：

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

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

彈性云混部未來展望

隨著未來穩(wěn)態(tài)上云計(jì)劃的推動(dòng)，公共集群規(guī)模可能保持現(xiàn)狀或適當(dāng)?shù)臏p少，未來各種隔離集群會(huì)是混部的重點(diǎn)算力來源，這里還是使用上面一張圖來說明彈性云混部的未來展望。

圖片

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

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

這就是我們未來的全混部思路，由于更多種類的服務(wù)運(yùn)行在一起，對技術(shù)能力提出了更大的挑戰(zhàn)，未來會(huì)進(jìn)一步增強(qiáng)集群調(diào)度、服務(wù)畫像、單機(jī)隔離、干擾檢測、異常感知等方面。