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

來源: 騰訊云原生
作者:韓沛
時(shí)間:2021-01-09
17196
本文整理自騰訊云云原生產(chǎn)品團(tuán)隊(duì)的專家產(chǎn)品經(jīng)理韓沛在Techo開發(fā)者大會(huì)云原生專題的分享內(nèi)容——Kubernetes混部與彈性容器。

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

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1.jpg

討論K8s的混部這個(gè)話題,是因?yàn)槲覀儼l(fā)現(xiàn),在業(yè)務(wù)K8s化后,混部和資源利用率對運(yùn)維團(tuán)隊(duì)是一個(gè)繞不過去的話題,這個(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)的打通,不過它們中的大部分在生態(tài)系統(tǒng)中已經(jīng)得到了很好的集成支持,通常不需要我們再做太多的工作。

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

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(1).jpg

在容器化之前,在物理或虛擬服務(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申請值,紅色線是容器真實(shí)運(yùn)行的曲線值,我們看到request和usage之間有很大gap,這是因?yàn)閷θ萜髻Y源的評估不可能完全精準(zhǔn),另外,波峰和波谷也有差別,最終導(dǎo)致平均利用率不高。

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(2).jpg

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

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

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

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(3).jpg

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

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(4).jpg

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

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

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

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(5).jpg

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

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

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

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

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(6).jpg

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

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

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(7).jpg

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

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(8).jpg

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

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

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

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(9).jpg

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

wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1(10).jpg

這類混部集群的幾個(gè)典型場景:

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

2、萬一發(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),不再對集群固定資源增加任何壓力,避免發(fā)生雪崩。

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

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

立即登錄,閱讀全文
版權(quán)說明:
本文內(nèi)容來自于騰訊云原生,本站不擁有所有權(quán),不承擔(dān)相關(guān)法律責(zé)任。文章內(nèi)容系作者個(gè)人觀點(diǎn),不代表快出海對觀點(diǎn)贊同或支持。如有侵權(quán),請聯(lián)系管理員(zzx@kchuhai.com)刪除!
掃碼登錄
打開掃一掃, 關(guān)注公眾號(hào)后即可登錄/注冊
加載中
二維碼已失效 請重試
刷新
賬號(hào)登錄/注冊
個(gè)人VIP
小程序
快出海小程序
公眾號(hào)
快出海公眾號(hào)
商務(wù)合作
商務(wù)合作
投稿采訪
投稿采訪
出海管家
出海管家