騰訊云Serverless如何應對K8s在離線場景下的資源供給訴求

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

討論K8s的混部這個話題，是因為我們發(fā)現(xiàn)，在業(yè)務K8s化后，混部和資源利用率對運維團隊是一個繞不過去的話題，這個話題也一直是我們騰訊云原生團隊一直關注的重點。

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

這其中有些部分在現(xiàn)有K8s的系統(tǒng)中即可以得到很好的支持，比如微服務、自動擴縮容。有些則依賴K8s與生態(tài)能力的集成，比如CICD、服務網(wǎng)格，就依賴K8s和一些社區(qū)DevOps、servicemesh系統(tǒng)的打通，不過它們中的大部分在生態(tài)系統(tǒng)中已經(jīng)得到了很好的集成支持，通常不需要我們再做太多的工作。

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

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

上圖，是一個K8s集群線上業(yè)務的典型資源曲線，最上面的藍線是容器資源request申請值，紅色線是容器真實運行的曲線值，我們看到request和usage之間有很大gap，這是因為對容器資源的評估不可能完全精準，另外，波峰和波谷也有差別，最終導致平均利用率不高。

那是不是K8s不行呢？當然不是，K8s在助力我們進行應用混部上雖然還沒有解決所有的問題，但絕對是最佳的可選平臺之一。

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

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

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

提升混部效果的關鍵是什么？首先，我們需要明確兩個問題。

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

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

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

一是對混部應用進行特征畫像、定級以及分配資源配額的應用管理層。這一層定義應用的級別，混部的時機，以及通過配額保證資源分配不失控。

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

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

混部的基本原理是對閑置資源的再分配。通常，閑置資源有兩個來源。集群內(nèi)會有碎片資源，這是資源分配顆粒度問題導致的，這些碎片資源可以分配給顆粒度更小的應用使用。另外，在線服務申請的資源通常會大于實際使用的資源，配合應用畫像，預測出這部分服務的波峰波谷，可以將這部分閑置資源分配給其他應用。

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

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

為了解決這些問題，騰訊云云原生團隊做了一直在思考和嘗試，目前較先進的一種方式是通過serverless容器即彈性容器，來拓展整個混部集群的資源池。

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

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

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

這類混部集群的幾個典型場景：

1、低負載時進行任務填充，運行更多任務，提升集群資源利用率。

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

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

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

最后，混部是一個持續(xù)優(yōu)化的過程。各家大廠都對混部投入了相當長的時間研究，才開始放量鋪開。隨著技術的發(fā)展，K8s混部的效果會越來越好，適用的場景也會越來越多。謝謝大家！