B站云原生混部技術(shù)實(shí)踐

　　01 背景

　　中大型互聯(lián)網(wǎng)公司的服務(wù)器數(shù)量可達(dá)萬級(jí)別，在降本增效的大背景下，機(jī)器資源利用率的重要性日益凸顯。如何在確保服務(wù)SLO影響最小的情況下提高機(jī)器資源利用率，從而降低服務(wù)器的采購(gòu)成本，是一項(xiàng)非常值得研究的課題。

　　對(duì)于k8s云平臺(tái)來說，造成機(jī)器平均資源利用率低的原因可以概括為以下幾點(diǎn)：

　　業(yè)務(wù)申請(qǐng)的資源配額超過實(shí)際使用量。即用戶在申請(qǐng)資源時(shí)可能會(huì)對(duì)服務(wù)的真實(shí)資源使用情況估計(jì)不足，一般傾向于申請(qǐng)過量的資源。這就導(dǎo)致機(jī)器配額被占滿，無法繼續(xù)調(diào)度容器，而實(shí)際資源利用率卻很低。

　　服務(wù)的資源使用量存在波峰波谷。大部分服務(wù)的負(fù)載都會(huì)存在高低峰，當(dāng)服務(wù)處于波谷的時(shí)候就會(huì)存在很大的資源浪費(fèi)。

　　針對(duì)上述問題1)，我們可以通過服務(wù)畫像給業(yè)務(wù)推薦一個(gè)合理的資源配置值，并結(jié)合彈性伸縮的手段來解決。

　　針對(duì)上述問題2)，關(guān)鍵點(diǎn)在于如何將業(yè)務(wù)波谷時(shí)空閑出來的那部分資源利用起來，比如凌晨在線業(yè)務(wù)處于波谷的時(shí)候，往在線集群調(diào)度適量的離線任務(wù)。

　　目前B站私有云平臺(tái)已經(jīng)達(dá)到較大的機(jī)器規(guī)模，我們從上述兩個(gè)思路出發(fā)來給整體云平臺(tái)降本：一方面提供了hpa和vpa的彈性伸縮能力，使得業(yè)務(wù)資源配額使用更為合理;另一方面，我們實(shí)施了較大規(guī)模的業(yè)務(wù)混部來解決算力的閑置問題。本文將主要分享B站云平臺(tái)的混部實(shí)踐，而彈性伸縮方面的實(shí)踐我們會(huì)擇機(jī)在后續(xù)文章中介紹。

　　02 混部的概念

　　我們把業(yè)務(wù)劃分為在線業(yè)務(wù)和離線業(yè)務(wù)。在線業(yè)務(wù)一般是各類微服務(wù)，特點(diǎn)是延時(shí)敏感、有很高的可用性要求，如推薦、廣告、搜索等服務(wù);離線業(yè)務(wù)一般是批處理任務(wù)，特點(diǎn)是延時(shí)不敏感、允許出錯(cuò)重跑，如大數(shù)據(jù)場(chǎng)景中的MapReduce任務(wù)、視頻處理中的轉(zhuǎn)碼任務(wù)等。所謂混部技術(shù)，就是通過調(diào)度、資源隔離等手段，將不同類型、不同優(yōu)先級(jí)的在離線業(yè)務(wù)部署在相同的物理機(jī)器上，并且保證業(yè)務(wù)的SLO，最終達(dá)到提高資源利用率、降低成本的目的。需要注意的是，混部不是簡(jiǎn)單地將容器部署到同一臺(tái)宿主機(jī)上，而是需要通過調(diào)度算法將混部任務(wù)調(diào)度到具有空閑資源的機(jī)器，同時(shí)需要有隔離機(jī)制來保證高優(yōu)任務(wù)不會(huì)受到混部任務(wù)的干擾。

　　03 B站混部的場(chǎng)景

　　1. 在離線混部。B站是一個(gè)視頻類網(wǎng)站，存在大量的點(diǎn)播視頻轉(zhuǎn)碼任務(wù)，這類任務(wù)屬于計(jì)算密集型，具有運(yùn)行時(shí)間短、允許失敗重試等特點(diǎn)。另外，在凌晨時(shí)段會(huì)觸發(fā)大量的轉(zhuǎn)碼定時(shí)任務(wù)，剛好和在線業(yè)務(wù)形成錯(cuò)峰。我們通過在離線混部技術(shù)將轉(zhuǎn)碼任務(wù)調(diào)度到在線集群，既提高了在線集群的資源使用率，又補(bǔ)充了轉(zhuǎn)碼任務(wù)高峰期時(shí)的算力缺口，極大地降低了服務(wù)器成本。這類混部場(chǎng)景的難點(diǎn)在于：

　　調(diào)度層。(1) 混部任務(wù)不能影響在線任務(wù)的整體配額容量，例如機(jī)器一共64核，如果混部任務(wù)直接申請(qǐng)32核的cpu request資源，那就會(huì)造成該機(jī)器只能調(diào)度32c的在線業(yè)務(wù)容器。(2) 調(diào)度器需要?jiǎng)討B(tài)感知到各個(gè)節(jié)點(diǎn)可混部資源量的變化，資源空閑越多的節(jié)點(diǎn)調(diào)度越多的混部任務(wù)。

　　節(jié)點(diǎn)層�；觳咳蝿�(wù)一旦調(diào)度到某個(gè)k8s節(jié)點(diǎn)后，在cpu、內(nèi)存、磁盤、網(wǎng)絡(luò)等各個(gè)資源層面都有可能對(duì)在線任務(wù)產(chǎn)生“競(jìng)爭(zhēng)”，因此需要隨時(shí)感知在線任務(wù)的負(fù)載情況并做相應(yīng)的隔離管控，盡量做到對(duì)在線任務(wù)零干擾。

　　2. 離線間混部。離線集群整體的cpu使用率較高，但部分時(shí)段也存在一定的資源閑置，例如訓(xùn)練平臺(tái)在訓(xùn)練任務(wù)較少時(shí)整體利用率會(huì)偏低。由于都是離線任務(wù)，延時(shí)敏感性沒有在線那么高，因此這類場(chǎng)景除了混部轉(zhuǎn)碼任務(wù)外，還可以混部一些更“重”的大數(shù)據(jù)任務(wù)。但是大數(shù)據(jù)任務(wù)通常用yarn調(diào)度，如何將k8s調(diào)度和yarn調(diào)度進(jìn)行協(xié)調(diào)是我們需要解決的關(guān)鍵問題。實(shí)現(xiàn)了大數(shù)據(jù)混部后，我們就可以做到各個(gè)離線業(yè)務(wù)互相出讓資源。例如將hdfs datanode機(jī)器接入k8s用于混部轉(zhuǎn)碼任務(wù);反過來，轉(zhuǎn)碼的機(jī)器上也可以運(yùn)行hadoop/spark等大數(shù)據(jù)任務(wù)。

　　3. 閑置機(jī)器混部。IDC通常會(huì)存在一定量的備機(jī)，用于各業(yè)務(wù)應(yīng)急場(chǎng)景使用，但是日常是閑置的。這部分機(jī)器我們也會(huì)自動(dòng)化接入k8s跑混部任務(wù)，當(dāng)業(yè)務(wù)需要借調(diào)備機(jī)時(shí)再自動(dòng)下線混部。

　　下面，我們結(jié)合在離線混部和離線間混部這兩個(gè)場(chǎng)景，具體介紹一下混部的關(guān)鍵技術(shù)點(diǎn)。

　　04 在離線混部

　　4.1 總體架構(gòu)

　　任務(wù)提交模塊。caster是我們的在線業(yè)務(wù)發(fā)布平臺(tái)，crm則是離線批處理任務(wù)提交平臺(tái)。crm可以支持多集群調(diào)度、混部資源余量統(tǒng)計(jì)、混部資源quota管控等。

　　k8s調(diào)度模塊。kube-scheduler為原生的在線任務(wù)調(diào)度器，而job-scheduler是我們自研的離線任務(wù)調(diào)度器，能支持轉(zhuǎn)碼任務(wù)的高并發(fā)調(diào)度。另外webhook負(fù)責(zé)對(duì)離線任務(wù)的資源配額進(jìn)行動(dòng)態(tài)轉(zhuǎn)換，轉(zhuǎn)換為自定義的k8s擴(kuò)展資源。

　　colocation-agent。每個(gè)k8s節(jié)點(diǎn)上都會(huì)部署混部agent，負(fù)責(zé)混部算力動(dòng)態(tài)計(jì)算和上報(bào)、資源隔離、監(jiān)控?cái)?shù)據(jù)上報(bào)等。

　　colocation config manager。在大規(guī)模k8s集群中，各類節(jié)點(diǎn)的混部配置存在一定的差異性，同時(shí)也存在動(dòng)態(tài)更新的需求。該模塊負(fù)責(zé)對(duì)混部配置進(jìn)行集中管控，支持策略下發(fā)、開關(guān)混部等功能。

　　混部的可觀測(cè)性。每個(gè)節(jié)點(diǎn)的agent負(fù)責(zé)采集節(jié)點(diǎn)中的一些混部指標(biāo)，例如：可混部資源量、實(shí)際的混部資源用量等，最終上報(bào)給prometheus進(jìn)行看板展示。可觀測(cè)性對(duì)于排查單機(jī)的混部問題非常有用，我們可以很方便地通過監(jiān)控曲線來查看某個(gè)時(shí)刻的混部資源使用情況。同時(shí)，我們也可以隨時(shí)查看整體集群的混部算力使用趨勢(shì)。

　　下面，我們從混部任務(wù)調(diào)度、在線QoS保障兩方面來介紹在離線混部的關(guān)鍵技術(shù)點(diǎn)。

　　4.2 混部任務(wù)調(diào)度

　　k8s原生調(diào)度器的基本原理和問題

　　k8s的每個(gè)節(jié)點(diǎn)都會(huì)上報(bào)節(jié)點(diǎn)資源總量(例如allocatable cpu)。對(duì)于一個(gè)待調(diào)度的pod，k8s調(diào)度器會(huì)查看pod的資源請(qǐng)求配額(例如cpu reqeust)以及相關(guān)調(diào)度約束，然后經(jīng)過預(yù)選和優(yōu)選階段，最終挑選出一個(gè)最佳的node用于部署該pod。如果混部任務(wù)直接使用這套原生的調(diào)度機(jī)制會(huì)存在幾個(gè)問題：

　　混部pod會(huì)占用原生的資源配額(例如cpu request)，這會(huì)導(dǎo)致在線任務(wù)發(fā)布的時(shí)候沒有可用資源;

　　原生調(diào)度本質(zhì)是靜態(tài)調(diào)度，沒有考慮機(jī)器實(shí)際負(fù)載，因此沒法有效地將混部任務(wù)調(diào)度到實(shí)際負(fù)載有空閑的機(jī)器上。

　　基于擴(kuò)展資源的混部調(diào)度

　　為了解決上述問題，我們基于k8s的擴(kuò)展資源進(jìn)行混部任務(wù)調(diào)度，整體分為3個(gè)步驟：

　　1. colocation agent模塊中，策略組件會(huì)實(shí)時(shí)加載當(dāng)前接收到的混部配置，并調(diào)用autopilot組件進(jìn)行混部算力的計(jì)算，然后通過device-plugin組件上報(bào)混部擴(kuò)展資源，例如caster.io/colocation-cpu

　　2. 混部任務(wù)在申請(qǐng)資源配額時(shí)，仍然申請(qǐng)?jiān)�生cpu資源，但是會(huì)增加pod標(biāo)簽“caster.io/resource-type: colocation”。k8s webhook模塊根據(jù)標(biāo)簽識(shí)別到混部pod，然后將pod申請(qǐng)的資源修改為混部擴(kuò)展資源。這種方式對(duì)業(yè)務(wù)層屏蔽了底層擴(kuò)展資源，通過標(biāo)注pod標(biāo)簽即可指定是否使用混部資源。

　　3. 混部調(diào)度器job-scheduler根據(jù)pod申請(qǐng)的擴(kuò)展資源量以及各個(gè)節(jié)點(diǎn)上報(bào)的混部擴(kuò)展資源量進(jìn)行調(diào)度。我們利用轉(zhuǎn)碼pod存在同質(zhì)化(資源規(guī)格和調(diào)度約束相同)的特點(diǎn)對(duì)調(diào)度器進(jìn)行了優(yōu)化，基本思路是：

　　將pod與調(diào)度相關(guān)的字段進(jìn)行hash值計(jì)算，并在調(diào)度隊(duì)列中按hash值排序pod

　　pod預(yù)選的結(jié)果同樣也滿足其他同質(zhì)化pod的要求，因此將預(yù)選node進(jìn)行緩存

　　當(dāng)前處理的pod若是同質(zhì)化pod，則從緩存中直接選取一個(gè)節(jié)點(diǎn)進(jìn)行調(diào)度

　　混部資源量計(jì)算

　　k8s node是怎么確定當(dāng)前節(jié)點(diǎn)應(yīng)該上報(bào)多少混部擴(kuò)展資源量的呢?我們針對(duì)不同的應(yīng)用場(chǎng)景設(shè)計(jì)了不同的混部策略算法：

　　1. 動(dòng)態(tài)計(jì)算。針對(duì)各類物理資源，例如cpu、memory等，我們會(huì)分別設(shè)置機(jī)器的安全水位值n%。agent會(huì)實(shí)時(shí)探測(cè)在線進(jìn)程的資源使用量online_usage，然后根據(jù)安全水位和在線負(fù)載動(dòng)態(tài)計(jì)算出可混部資源量。在線使用量和可混部資源量是此消彼長(zhǎng)的，隨著在線使用量上升，我們上報(bào)的可混部量就會(huì)下降，反之，當(dāng)在線使用量下降，可混部量就會(huì)上升。

　　2. 靜態(tài)計(jì)算。例如備機(jī)池閑置機(jī)器沒有在線業(yè)務(wù)，不需要?jiǎng)討B(tài)資源計(jì)算，因此我們可以配置靜態(tài)上報(bào)策略，上報(bào)固定的可混部資源量即可。

　　3. 分時(shí)計(jì)算。如果部分在線業(yè)務(wù)在某些時(shí)間段不希望部署混部任務(wù)，我們就需要用到分時(shí)策略，即在某些時(shí)間段關(guān)閉混部或者減少上報(bào)混部資源量。另外，我們還支持設(shè)置grace period，在分時(shí)混部結(jié)束前，會(huì)提前停止調(diào)度混部任務(wù)到該k8s node，并等待存量任務(wù)結(jié)束，做到優(yōu)雅退出。

　　4.3 在線QoS保障

　　資源隔離是混部架構(gòu)的關(guān)鍵難點(diǎn)。我們希望在提高單機(jī)混部資源量的同時(shí)，盡可能地降低混部任務(wù)對(duì)在線業(yè)務(wù)的性能影響。主要從三個(gè)層次來保障在線業(yè)務(wù)的QoS：

　　任務(wù)調(diào)度。根據(jù)前文所述的混部任務(wù)調(diào)度機(jī)制，混部調(diào)度器可以實(shí)時(shí)感知各節(jié)點(diǎn)的可混部資源量，因此可以從全局視角將混部任務(wù)調(diào)度到資源充足的節(jié)點(diǎn)上。

　　資源隔離。節(jié)點(diǎn)混部agent可以秒級(jí)檢測(cè)在線負(fù)載變化，根據(jù)安全水位值計(jì)算當(dāng)前可混部資源量，然后通過cgroup及時(shí)進(jìn)行資源限制。

　　任務(wù)驅(qū)逐。離線的混部任務(wù)一般都是可重試的，因此驅(qū)逐可以作為一種兜底手段。

　　下面我們?cè)敿?xì)介紹一下資源隔離層的幾種策略。

　　混部大框

　　在前面的介紹中我們提到webhook會(huì)對(duì)混部任務(wù)申請(qǐng)的資源類型進(jìn)行修改，去除原生的資源類型request.cpu和request.memory，改成caster.io/colocation-cpu和caster.io/colocation-memory。由于沒有申請(qǐng)?jiān)�生資源類型，那么k8s會(huì)自動(dòng)將這類pod歸類為best effort類型，并且最終通過runc將該類pod的cgroup設(shè)置到/sys/fs/cgroup/cpu/kubepods/besteffort目錄，我們稱為“混部大框”。

　　cpu動(dòng)態(tài)隔離

　　在cgroup層面，我們給大框設(shè)置了最小的cpu share值，保證在資源爭(zhēng)搶時(shí)，混部任務(wù)獲得cpu時(shí)間片的權(quán)重最小。

　　colocation agent中的cgroup manager組件負(fù)責(zé)動(dòng)態(tài)地調(diào)整“混部大框”的cpu quota，從而對(duì)混部任務(wù)進(jìn)行整體的資源限制。當(dāng)colocation agent檢測(cè)到在線負(fù)載降低時(shí)，就會(huì)調(diào)大“混部大框”的cpu quota，讓混部任務(wù)充分利用空閑的算力。當(dāng)在線負(fù)載升高時(shí)，則是縮小“混部大框”的cpu quota，快速讓出資源給在線業(yè)務(wù)使用。

　　此外，我們通過cpuset cgroup對(duì)整體混部大框做了綁核處理，避免混部任務(wù)進(jìn)程頻繁切換干擾在線業(yè)務(wù)進(jìn)程。當(dāng)混部算力改變時(shí)，agent會(huì)給大框動(dòng)態(tài)選取相應(yīng)的cpu核心進(jìn)行綁定。另外，選取cpu核心的時(shí)候也考慮了cpu HT，即盡量將同一個(gè)物理核上的邏輯核同時(shí)綁定給混部任務(wù)使用。否則，如果在線任務(wù)和混部任務(wù)分別跑在一個(gè)物理核的兩個(gè)邏輯核上，在線任務(wù)還是有可能受到“noisy neighbor”干擾。

　　內(nèi)存動(dòng)態(tài)隔離

　　與cpu隔離方式類似，colocation agent會(huì)根據(jù)當(dāng)前在線業(yè)務(wù)內(nèi)存使用情況，動(dòng)態(tài)擴(kuò)縮混部大框的memory quota。另外，通過調(diào)節(jié)oom_score_adj，混部任務(wù)的oom_sore被設(shè)為最大值，保證oom時(shí)混部任務(wù)盡量?jī)?yōu)先被驅(qū)逐。

　　網(wǎng)絡(luò)帶寬限制

　　我們使用了cni-adaptor組件，使得k8s node可以支持多種網(wǎng)絡(luò)模式，對(duì)于轉(zhuǎn)碼混部任務(wù)，通常不需要被外部訪問，因此通過annotation可以指定bridge網(wǎng)絡(luò)模式，分配host-local的ip，避免占用全局網(wǎng)段中的ip資源。同時(shí)也利用了linux tc進(jìn)行混部pod的網(wǎng)絡(luò)帶寬限制。

　　驅(qū)逐機(jī)制

　　混部agent層支持內(nèi)存、磁盤、cpu load等維度的驅(qū)逐機(jī)制。當(dāng)任意資源負(fù)載達(dá)到設(shè)置的驅(qū)逐水位時(shí)，agent會(huì)立即驅(qū)逐機(jī)器上的混部任務(wù)。為了防止任務(wù)在同一臺(tái)機(jī)器上被頻繁驅(qū)逐，需要在驅(qū)逐后設(shè)置一定的冷卻時(shí)間，冷卻期內(nèi)禁止調(diào)度混部任務(wù)。

　　05 離線間混部

　　針對(duì)訓(xùn)練、轉(zhuǎn)碼等離線集群跑大數(shù)據(jù)混部任務(wù)的場(chǎng)景，我們基于在離線混部框架做了功能增強(qiáng)，其關(guān)鍵點(diǎn)在于yarn nodemanager on k8s。具體的調(diào)度步驟為：

　　yarn node manager以daemonset的形式部署在相應(yīng)的混部節(jié)點(diǎn)上

　　節(jié)點(diǎn)上的混部agent會(huì)動(dòng)態(tài)檢測(cè)在線容器負(fù)載變化，并根據(jù)設(shè)置的混部策略計(jì)算可混部值。這個(gè)值一方面會(huì)通過接口上報(bào)給yarn rm，另外一方面會(huì)設(shè)置到混部大框的cgroup中進(jìn)行動(dòng)態(tài)的資源限制

　　用戶把大數(shù)據(jù)任務(wù)提交到混部集群時(shí)，rm會(huì)找到集群中有充足資源的混部節(jié)點(diǎn)，并最終在nm中拉起task

　　為了降低大數(shù)據(jù)任務(wù)對(duì)非混部業(yè)務(wù)的影響，大數(shù)據(jù)團(tuán)隊(duì)也做了相關(guān)技術(shù)改造，例如支持remote shuffle、基于應(yīng)用畫像識(shí)別小規(guī)格任務(wù)進(jìn)行調(diào)度等。

　　06 混部管理平臺(tái)

　　我們開發(fā)了界面化的混部管理平臺(tái)來支撐日常的運(yùn)維需求。主要功能包括：

　　策略管理。支持批量查看和設(shè)置節(jié)點(diǎn)的混部策略，例如安全水位、硬限值等。同時(shí)也支持設(shè)置節(jié)點(diǎn)組，只要節(jié)點(diǎn)打上對(duì)應(yīng)的組標(biāo)簽，管控層可以秒級(jí)感知并立即下發(fā)相應(yīng)混部策略。

　　開關(guān)混部。如果臨時(shí)需要對(duì)特定機(jī)器關(guān)閉混部，可以在平臺(tái)進(jìn)行一鍵關(guān)閉，此時(shí)會(huì)立即驅(qū)逐機(jī)器上的混部任務(wù)并且停止上報(bào)混部資源。

　　監(jiān)控查看。單機(jī)粒度監(jiān)控主要滿足日常排障需求，可以精確查看某一時(shí)刻機(jī)器上的混部上報(bào)量、混部任務(wù)數(shù)、混部實(shí)際資源消耗等。節(jié)點(diǎn)組粒度的監(jiān)控則可以評(píng)估這批機(jī)器整體貢獻(xiàn)的混部量以及對(duì)應(yīng)的使用情況。

　　07 混部效果

　　目前B站云平臺(tái)大部分機(jī)器都參與了混部，混部機(jī)器的平均cpu使用率可以達(dá)到35%，峰值使用率則可以達(dá)到55%左右。這些混部算力支撐了B站大規(guī)模的視頻轉(zhuǎn)碼任務(wù)，以及ai機(jī)審、大數(shù)據(jù)MR等任務(wù)，節(jié)省了數(shù)千臺(tái)機(jī)器的采購(gòu)成本。

　　08 總結(jié)

　　本文介紹了B站基于k8s云平臺(tái)進(jìn)行的混部實(shí)踐，主要分為在離線混部、離線間混部等業(yè)務(wù)場(chǎng)景。我們采用了一套對(duì)k8s無侵入的混部框架，并且通過調(diào)度、資源隔離等手段來確保非混部業(yè)務(wù)的SLO，另外也開發(fā)了相關(guān)的監(jiān)控、策略管理平臺(tái)等來提高整體混部系統(tǒng)的可運(yùn)維性。后續(xù)我們會(huì)在內(nèi)核層隔離與可觀測(cè)、統(tǒng)一調(diào)度等方面優(yōu)化混部技術(shù)框架，持續(xù)助力云平臺(tái)降本。