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

今天就跟大家聊聊有關(guān)Serverless如何應(yīng)對 K8s 在離線場景下的資源供給訴求，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

討論 K8s 的混部這個(gè)話題，是因?yàn)槲覀儼l(fā)現(xiàn)，在業(yè)務(wù) K8s 化后，混部和資源利用率對運(yùn)維團(tuán)隊(duì)是一個(gè)繞不過去的話題。

首先，毋庸置疑，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è)施升級為云原生架構(gòu)后，通常會(huì)天然支持一些混部能力，從而帶來一些顯而易見的收益，比如資源利用率的提升?？梢哉f容器化和 K8s 為整個(gè)行業(yè)進(jìn)入應(yīng)用的大規(guī)模混部打開了一扇窗。而另一方面，但當(dāng)我們真正進(jìn)這個(gè)領(lǐng)域時(shí)，即使站在 K8s 的肩膀上，混部依然是對企業(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 申請值，紅色線是容器真實(shí)運(yùn)行的曲線值，我們看到 request 和 usage 之間有很大 gap，這是因?yàn)閷θ萜髻Y源的評估不可能完全精準(zhǔn)，另外，波峰和波谷也有差別，最終導(dǎo)致平均利用率不高。

那是不是 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)行混部，資源利用率的提升非常顯著。

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

提升混部效果的關(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ì)量，得不償失。

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

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

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

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

混部的基本原理是對閑置資源的再分配。通常，閑置資源有兩個(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)度等操作。

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

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

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

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

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

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

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

看完上述內(nèi)容，你們對Serverless如何應(yīng)對 K8s 在離線場景下的資源供給訴求有進(jìn)一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。