本文整理自騰訊云云原生產品團隊的專家產品經理韓沛在 Techo 開發者大會云原生專題的分享內容——Kubernetes 混部與彈性容器，本次分享主要分為三部分：基于 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 在混部的支撐層面，如調度增強、資源預測回收、任務避讓等機制上的進步，
提升混部效果的關鍵是什么？首先，我們需要明確兩個問題，
第一個問題，混部的目的是什么？混部的目的是在保證在線業務服務質量的前提下，實作閑置資源復用，提高整體資源利用率，保證在線業務服務質量是前提，使之不受影響，沒有這個前提，利用率提升再高也毫無意義，
第二個問題，什么樣的應用適合混部？適合混部的應用有兩類：一類是算力要求很高的周期性應用，通常是一些離線計算任務，一類是容易造成資源浪費的應用，通常是一些長時間運行的、具備潮汐現象的在線服務，但要注意，有些在線服務會對某些資源有較高的敏感性，這類服務是對混部系統的最大挑戰，因為稍有不慎就會偏離混部的目的，影響了在線服務質量，得不償失，
在確定了這兩個問題之后，我們來看下混部系統需要有哪些機制，通常分為三層：
一是對混部應用進行特征畫像、定級以及分配資源配額的應用管理層，這一層定義應用的級別，混部的時機，以及通過配額保證資源分配不失控，
二是對混部集群進行調度、隔離、資源復用和避讓的核心系統，這一層是混部的核心，基本決定了我們的集群能達到什么樣的混部效果，
最后，還需要一整套適配的自動化運營系統，
混部的基本原理是對閑置資源的再分配，通常，閑置資源有兩個來源，集群內會有碎片資源，這是資源分配顆粒度問題導致的，這些碎片資源可以分配給顆粒度更小的應用使用，另外，在線服務申請的資源通常會大于實際使用的資源，配合應用畫像，預測出這部分服務的波峰波谷，可以將這部分閑置資源分配給其他應用，
基于這個背景，引申出混部最核心的兩個子模塊：資源復用和任務避讓，顧名思義，資源復用就是把上述兩種閑置資源通過預測、回收的機制，實時再分配給混部應用使用，而任務避讓，就是檢測核心在線服務是否收到了混部的影響，一旦發生干擾，馬上觸發沖突處理機制，進行壓制和再調度等操作，
可以這么說，這兩個模塊決定了混部的效果和可混部的應用范圍，除了理論上的問題，還有一些重要的點必須考慮：為了保證混部效果，頻繁對集群實時情況進行預測和資源回收，對集群本身帶來了額外的負擔，如何在盡可能資源復用和盡量降低資源預測回收頻率之間找到平衡？還有，為了保證在線服務的質量，任務回避通常不可避免，這就降低了次優先級應用的執行效率，高負載時可能導致任務的頻繁重試和堆積，進而可能拖累整個集群，
為了解決這些問題，騰訊云云原生團隊做了一直在思考和嘗試，目前較先進的一種方式是通過 serverless 容器即彈性容器，來拓展整個混部集群的資源池，
彈性容器是騰訊云推出的無服務器容器產品，它支持一種能力，類似開源virtual kubelet 的方式，但又相比開源方案能力更強、更適合生產，它支持在一個既有 K8s 集群中通過部署虛擬節點的方式把 pod 調度為彈性容器，調度為彈性容器的 pod 與原集群中的其他 pod 網路互通，如果關聯了service ，service間也可互通，
所以無論是已有 workload 的擴容、還是新的 workload，都可以以一種平滑的方式進行調度，且該能力對集群不會產生額外的維護成本，
這個能力對混部的核心價值在于：它無成本的擴展了集群資源池，降低了資源沖突的風險，提升了混部集群的冗余度和適用性，另外，在檢測到資源不足之類的沖突時，在很多場景可以不中止次優先級任務，而是視情況擴容或再調度，在彈性容器上繼續運行任務，秉持盡量不打斷已啟動任務的原則，提升整個系統的效率，
這類混部集群的幾個典型場景：
1、低負載時進行任務填充，運行更多任務，提升集群資源利用率，
2、萬一發生了在線服務干擾，封鎖相關節點，驅逐次優先級任務到虛擬節點，讓其繼續運行，
3、發生集群資源緊張時，封鎖相關節點，視情況，如果是可壓縮資源緊張，比如 CPU、IO 等，則壓制次優先級任務；如果是不可壓縮資源緊張，如記憶體、存盤等，則驅逐次優先級任務到虛擬節點；在此情況下所有新增 Pod 均調度到虛擬節點，不再對集群固定資源增加任何壓力，避免發生雪崩，
這3個例子還不能覆寫所有的混部場景，但已經提升了原生 K8s 集群混部的適用范圍，我們也在持續探索其他的路徑來做到更好，也歡迎有想法的朋友下來一起探討和分享，
最后，混部是一個持續優化的程序，各家大廠都對混部投入了相當長的時間研究，才開始放量鋪開，隨著技術的發展，K8s 混部的效果會越來越好，適用的場景也會越來越多，謝謝大家！
Kubernetes 混部與彈性容器（本文） PPT 下載方式，請在公眾號騰訊云原生后臺回復關鍵字“EKS”獲取，
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/248908.html
標籤：其他