騰訊云Serverless如何應(yīng)對(duì)K8s在離線場(chǎng)景下的資源供給訴求

本文整理自騰訊云云原生產(chǎn)品團(tuán)隊(duì)的專家產(chǎn)品經(jīng)理韓沛在Techo開(kāi)發(fā)者大會(huì)云原生專題的分享內(nèi)容——Kubernetes混部與彈性容器。本次分享主要分為三部分：基于K8s的應(yīng)用混部、提升應(yīng)用混部效果的關(guān)鍵、彈性容器對(duì)混部集群的價(jià)值。

討論K8s的混部這個(gè)話題，是因?yàn)槲覀儼l(fā)現(xiàn)，在業(yè)務(wù)K8s化后，混部和資源利用率對(duì)運(yùn)維團(tuán)隊(duì)是一個(gè)繞不過(guò)去的話題，這個(gè)話題也一直是我們騰訊云原生團(tuán)隊(duì)一直關(guān)注的重點(diǎn)。

首先，毋庸置疑，Kubernetes的系統(tǒng)能力和它作為引擎推動(dòng)的云原生生態(tài)影響力都非常強(qiáng)大，助力了很多先進(jìn)理念在生產(chǎn)環(huán)境的大規(guī)模實(shí)用化，包括微服務(wù)、自動(dòng)擴(kuò)縮容、CICD、服務(wù)網(wǎng)格、應(yīng)用混部等。

這其中有些部分在現(xiàn)有K8s的系統(tǒng)中即可以得到很好的支持，比如微服務(wù)、自動(dòng)擴(kuò)縮容。有些則依賴K8s與生態(tài)能力的集成，比如CICD、服務(wù)網(wǎng)格，就依賴K8s和一些社區(qū)DevOps、servicemesh系統(tǒng)的打通，不過(guò)它們中的大部分在生態(tài)系統(tǒng)中已經(jīng)得到了很好的集成支持，通常不需要我們?cè)僮鎏嗟墓ぷ鳌?/span>

但我們今天的話題——K8s架構(gòu)下的應(yīng)用混部，則是一個(gè)較特殊的領(lǐng)域，一方面大部分的企業(yè)基礎(chǔ)設(shè)施升級(jí)為云原生架構(gòu)后，通常會(huì)天然支持一些混部能力，從而帶來(lái)一些顯而易見(jiàn)的收益，比如資源利用率的提升。可以說(shuō)容器化和K8s為整個(gè)行業(yè)進(jìn)入應(yīng)用的大規(guī)?；觳看蜷_(kāi)了一扇窗。而另一方面，但當(dāng)我們真正進(jìn)這個(gè)領(lǐng)域時(shí)，即使站在K8s的肩膀上，混部依然是對(duì)企業(yè)架構(gòu)能力的一個(gè)巨大挑戰(zhàn)。

在容器化之前，在物理或虛擬服務(wù)器上部署應(yīng)用，資源利用率通常很低，一是很多應(yīng)用本身具有潮汐現(xiàn)象，二是服務(wù)器大部分情況只能部署一個(gè)應(yīng)用，而非K8s那樣在一個(gè)節(jié)點(diǎn)上部署多個(gè)。但容器化托管到K8s集群后，很多時(shí)候，我們會(huì)發(fā)現(xiàn)資源利用率還是不高。

上圖，是一個(gè)K8s集群線上業(yè)務(wù)的典型資源曲線，最上面的藍(lán)線是容器資源request申請(qǐng)值，紅色線是容器真實(shí)運(yùn)行的曲線值，我們看到request和usage之間有很大gap，這是因?yàn)閷?duì)容器資源的評(píng)估不可能完全精準(zhǔn)，另外，波峰和波谷也有差別，最終導(dǎo)致平均利用率不高。

那是不是K8s不行呢？當(dāng)然不是，K8s在助力我們進(jìn)行應(yīng)用混部上雖然還沒(méi)有解決所有的問(wèn)題，但絕對(duì)是最佳的可選平臺(tái)之一。

優(yōu)秀的系統(tǒng)能力使K8s天然適合進(jìn)行混部，包括在線服務(wù)的混部和現(xiàn)在業(yè)內(nèi)火熱的在離線混部。騰訊內(nèi)部也通過(guò)K8s化，在很多場(chǎng)景顯著提升了資源利用率。

像騰訊這種規(guī)模的計(jì)算體量，除了大家熟知明星應(yīng)用，還有海量的算力在進(jìn)行服務(wù)支撐、離線計(jì)算等。通過(guò)把這部分應(yīng)用以及一些潮汐現(xiàn)象明顯的產(chǎn)品服務(wù)進(jìn)行混部，資源利用率的提升非常顯著。

在業(yè)內(nèi)，Google基于K8s的前身Borg系統(tǒng)，從2015年至今已發(fā)布了多篇與混部相關(guān)的論文。于去年發(fā)布一篇論文中，可以看到Borg支持的混部能力已經(jīng)逼近60%的CPU資源利用率。對(duì)比其2011年和2019年的混部效果，可以看到，除了利用率的提升，最顯著的變化，一是應(yīng)用分級(jí)粒度更細(xì)了，二是各級(jí)別的應(yīng)用運(yùn)行更加平穩(wěn)了。尤其是第二點(diǎn)，明顯感覺(jué)到Borg在混部的支撐層面，如調(diào)度增強(qiáng)、資源預(yù)測(cè)回收、任務(wù)避讓等機(jī)制上的進(jìn)步。

提升混部效果的關(guān)鍵是什么？首先，我們需要明確兩個(gè)問(wèn)題。

第一個(gè)問(wèn)題，混部的目的是什么？混部的目的是在保證在線業(yè)務(wù)服務(wù)質(zhì)量的前提下，實(shí)現(xiàn)閑置資源復(fù)用，提高整體資源利用率。保證在線業(yè)務(wù)服務(wù)質(zhì)量是前提，使之不受影響，沒(méi)有這個(gè)前提，利用率提升再高也毫無(wú)意義。

第二個(gè)問(wèn)題，什么樣的應(yīng)用適合混部？適合混部的應(yīng)用有兩類：一類是算力要求很高的周期性應(yīng)用，通常是一些離線計(jì)算任務(wù)。一類是容易造成資源浪費(fèi)的應(yīng)用，通常是一些長(zhǎng)時(shí)間運(yùn)行的、具備潮汐現(xiàn)象的在線服務(wù)。但要注意，有些在線服務(wù)會(huì)對(duì)某些資源有較高的敏感性，這類服務(wù)是對(duì)混部系統(tǒng)的最大挑戰(zhàn)，因?yàn)樯杂胁簧骶蜁?huì)偏離混部的目的，影響了在線服務(wù)質(zhì)量，得不償失。

在確定了這兩個(gè)問(wèn)題之后，我們來(lái)看下混部系統(tǒng)需要有哪些機(jī)制。通常分為三層：

一是對(duì)混部應(yīng)用進(jìn)行特征畫(huà)像、定級(jí)以及分配資源配額的應(yīng)用管理層。這一層定義應(yīng)用的級(jí)別，混部的時(shí)機(jī)，以及通過(guò)配額保證資源分配不失控。

二是對(duì)混部集群進(jìn)行調(diào)度、隔離、資源復(fù)用和避讓的核心系統(tǒng)。這一層是混部的核心，基本決定了我們的集群能達(dá)到什么樣的混部效果。

最后，還需要一整套適配的自動(dòng)化運(yùn)營(yíng)系統(tǒng)。

混部的基本原理是對(duì)閑置資源的再分配。通常，閑置資源有兩個(gè)來(lái)源。集群內(nèi)會(huì)有碎片資源，這是資源分配顆粒度問(wèn)題導(dǎo)致的，這些碎片資源可以分配給顆粒度更小的應(yīng)用使用。另外，在線服務(wù)申請(qǐng)的資源通常會(huì)大于實(shí)際使用的資源，配合應(yīng)用畫(huà)像，預(yù)測(cè)出這部分服務(wù)的波峰波谷，可以將這部分閑置資源分配給其他應(yīng)用。

基于這個(gè)背景，引申出混部最核心的兩個(gè)子模塊：資源復(fù)用和任務(wù)避讓。顧名思義，資源復(fù)用就是把上述兩種閑置資源通過(guò)預(yù)測(cè)、回收的機(jī)制，實(shí)時(shí)再分配給混部應(yīng)用使用。而任務(wù)避讓，就是檢測(cè)核心在線服務(wù)是否收到了混部的影響。一旦發(fā)生干擾，馬上觸發(fā)沖突處理機(jī)制，進(jìn)行壓制和再調(diào)度等操作。

可以這么說(shuō)，這兩個(gè)模塊決定了混部的效果和可混部的應(yīng)用范圍。除了理論上的問(wèn)題，還有一些重要的點(diǎn)必須考慮：為了保證混部效果，頻繁對(duì)集群實(shí)時(shí)情況進(jìn)行預(yù)測(cè)和資源回收，對(duì)集群本身帶來(lái)了額外的負(fù)擔(dān)，如何在盡可能資源復(fù)用和盡量降低資源預(yù)測(cè)回收頻率之間找到平衡？還有，為了保證在線服務(wù)的質(zhì)量，任務(wù)回避通常不可避免，這就降低了次優(yōu)先級(jí)應(yīng)用的執(zhí)行效率，高負(fù)載時(shí)可能導(dǎo)致任務(wù)的頻繁重試和堆積，進(jìn)而可能拖累整個(gè)集群。

為了解決這些問(wèn)題，騰訊云云原生團(tuán)隊(duì)做了一直在思考和嘗試，目前較先進(jìn)的一種方式是通過(guò)serverless容器即彈性容器，來(lái)拓展整個(gè)混部集群的資源池。

彈性容器是騰訊云推出的無(wú)服務(wù)器容器產(chǎn)品。它支持一種能力，類似開(kāi)源virtual kubelet的方式，但又相比開(kāi)源方案能力更強(qiáng)、更適合生產(chǎn)。它支持在一個(gè)既有K8s集群中通過(guò)部署虛擬節(jié)點(diǎn)的方式把pod調(diào)度為彈性容器。調(diào)度為彈性容器的pod與原集群中的其他pod網(wǎng)絡(luò)互通，如果關(guān)聯(lián)了service，service間也可互通。

所以無(wú)論是已有workload的擴(kuò)容、還是新的workload，都可以以一種平滑的方式進(jìn)行調(diào)度。且該能力對(duì)集群不會(huì)產(chǎn)生額外的維護(hù)成本。

這個(gè)能力對(duì)混部的核心價(jià)值在于：它無(wú)成本的擴(kuò)展了集群資源池，降低了資源沖突的風(fēng)險(xiǎn)，提升了混部集群的冗余度和適用性。另外，在檢測(cè)到資源不足之類的沖突時(shí)，在很多場(chǎng)景可以不中止次優(yōu)先級(jí)任務(wù)，而是視情況擴(kuò)容或再調(diào)度，在彈性容器上繼續(xù)運(yùn)行任務(wù)，秉持盡量不打斷已啟動(dòng)任務(wù)的原則，提升整個(gè)系統(tǒng)的效率。

這類混部集群的幾個(gè)典型場(chǎng)景：

1、低負(fù)載時(shí)進(jìn)行任務(wù)填充，運(yùn)行更多任務(wù)，提升集群資源利用率。

2、萬(wàn)一發(fā)生了在線服務(wù)干擾，封鎖相關(guān)節(jié)點(diǎn)，驅(qū)逐次優(yōu)先級(jí)任務(wù)到虛擬節(jié)點(diǎn)，讓其繼續(xù)運(yùn)行。

3、發(fā)生集群資源緊張時(shí)，封鎖相關(guān)節(jié)點(diǎn)，視情況，如果是可壓縮資源緊張，比如CPU、IO等，則壓制次優(yōu)先級(jí)任務(wù)；如果是不可壓縮資源緊張，如內(nèi)存、存儲(chǔ)等，則驅(qū)逐次優(yōu)先級(jí)任務(wù)到虛擬節(jié)點(diǎn)；在此情況下所有新增Pod均調(diào)度到虛擬節(jié)點(diǎn)，不再對(duì)集群固定資源增加任何壓力，避免發(fā)生雪崩。

這3個(gè)例子還不能覆蓋所有的混部場(chǎng)景，但已經(jīng)提升了原生K8s集群混部的適用范圍。我們也在持續(xù)探索其他的路徑來(lái)做到更好。也歡迎有想法的朋友下來(lái)一起探討和分享。

最后，混部是一個(gè)持續(xù)優(yōu)化的過(guò)程。各家大廠都對(duì)混部投入了相當(dāng)長(zhǎng)的時(shí)間研究，才開(kāi)始放量鋪開(kāi)。隨著技術(shù)的發(fā)展，K8s混部的效果會(huì)越來(lái)越好，適用的場(chǎng)景也會(huì)越來(lái)越多。謝謝大家！