本文整理自騰訊云云原生產(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混部的效果會越來越好,適用的場景也會越來越多。謝謝大家!