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

創(chuàng)新互聯(lián)專注于青云譜網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供青云譜營銷型網(wǎng)站建設(shè)，青云譜網(wǎng)站制作、青云譜網(wǎng)頁設(shè)計、青云譜網(wǎng)站官網(wǎng)定制、成都小程序開發(fā)服務(wù)，打造青云譜網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供青云譜網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。

討論 K8s 的混部這個話題，是因為我們發(fā)現(xiàn)，在業(yè)務(wù) K8s 化后，混部和資源利用率對運維團隊是一個繞不過去的話題。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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