01 背景

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

　　對于k8s云平臺來說，造成機器平均資源利用率低的原因可以概括為以下幾點：

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

　　服務(wù)的資源使用量存在波峰波谷。大部分服務(wù)的負載都會存在高低峰，當服務(wù)處于波谷的時候就會存在很大的資源浪費。

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

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

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

　　02 混部的概念

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

　　03 B站混部的場景

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

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

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

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

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

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

　　04 在離線混部

　　4.1 總體架構(gòu)

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

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

　　colocation-agent。每個k8s節(jié)點上都會部署混部agent，負責混部算力動態(tài)計算和上報、資源隔離、監(jiān)控數(shù)據(jù)上報等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　混部資源量計算

　　k8s node是怎么確定當前節(jié)點應(yīng)該上報多少混部擴展資源量的呢?我們針對不同的應(yīng)用場景設(shè)計了不同的混部策略算法：

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

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

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

　　4.3 在線QoS保障

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

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

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

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

　　下面我們詳細介紹一下資源隔離層的幾種策略。

　　混部大框

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

　　cpu動態(tài)隔離

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

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

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

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

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

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

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

　　驅(qū)逐機制

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

　　05 離線間混部

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

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

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

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

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

　　06 混部管理平臺

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

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

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

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

　　07 混部效果

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

　　08 總結(jié)

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