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

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

討論 K8s 的混部這個話題，是因為我們發現，在業務 K8s 化后，混部和資源利用率對運維團隊是一個繞不過去的話題。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2、萬一發生了在線服務干擾，封鎖相關節點，驅逐次優先級任務到虛擬節點，讓其繼續運行。

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

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