本文整理自騰訊云云原生產品團隊的專家產品經理韓沛在 Techo 開發者大會雲原生專題的分享內容——Kubernetes 混部與彈性容器。本次分享主要分爲三部分：基於 K8s 的應用混部、提高應用混部效果的關鍵、彈性容器對混部集羣的價值。服務器
討論 K8s 的混部這個話題，是由於咱們發現，在業務 K8s 化後，混部和資源利用率對運維團隊是一個繞不過去的話題，這個話題也一直是咱們騰訊雲原生團隊一直關注的重點。網絡
首先，毋庸置疑，Kubernetes 的系統能力和它做爲引擎推進的雲原生生態影響力都很是強大，助力了不少先進理念在生產環境的大規模實用化，包括微服務、自動擴縮容、CICD、服務網格、應用混部等。架構
這其中有些部分在現有 K8s 的系統中便可以獲得很好的支持，好比微服務、自動擴縮容。有些則依賴 K8s 與生態能力的集成，好比 CICD、服務網格，就依賴 K8s 和一些社區 DevOps 、servicemesh 系統的打通，不過它們中的大部分在生態系統中已經獲得了很好的集成支持，一般不須要咱們再作太多的工做。less
但咱們今天的話題——K8s 架構下的應用混部，則是一個較特殊的領域，一方面大部分的企業基礎設施升級爲雲原生架構後，一般會自然支持一些混部能力，從而帶來一些顯而易見的收益，好比資源利用率的提高。能夠說容器化和 K8s 爲整個行業進入應用的大規模混部打開了一扇窗。而另外一方面，但當咱們真正進這個領域時，即便站在 K8s 的肩膀上，混部依然是對企業架構能力的一個巨大挑戰。運維
在容器化以前，在物理或虛擬服務器上部署應用，資源利用率一般很低，一是不少應用自己具備潮汐現象，二是服務器大部分狀況只能部署一個應用，而非 K8s 那樣在一個節點上部署多個。但容器化託管到 K8s 集羣后，不少時候，咱們會發現資源利用率仍是不高。微服務
上圖，是一個 K8s 集羣線上業務的典型資源曲線，最上面的藍線是容器資源 request 申請值，紅色線是容器真實運行的曲線值，咱們看到 request 和 usage 之間有很大 gap，這是由於對容器資源的評估不可能徹底精準，另外，波峯和波谷也有差異，最終致使平均利用率不高。優化
那是否是 K8s 不行呢？固然不是，K8s 在助力咱們進行應用混部上雖然尚未解決全部的問題，但絕對是最佳的可選平臺之一。3d
優秀的系統能力使 K8s 自然適合進行混部，包括在線服務的混部和如今業內火熱的在離線混部。騰訊內部也經過 K8s 化，在不少場景顯著提高了資源利用率。server
像騰訊這種規模的計算體量，除了你們熟知明星應用，還有海量的算力在進行服務支撐、離線計算等。經過把這部分應用以及一些潮汐現象明顯的產品服務進行混部，資源利用率的提高很是顯著。blog
在業內，Google 基於 K8s 的前身 Borg 系統，從 2015 年至今已發佈了多篇與混部相關的論文。於去年發佈一篇論文中，能夠看到 Borg 支持的混部能力已經逼近 60% 的 CPU 資源利用率。對比其 2011 年和 2019 年的混部效果，能夠看到，除了利用率的提高，最顯著的變化，一是應用分級粒度更細了，二是各級別的應用運行更加平穩了。尤爲是第二點，明顯感受到 Borg 在混部的支撐層面，如調度加強、資源預測回收、任務避讓等機制上的進步。
提高混部效果的關鍵是什麼？首先，咱們須要明確兩個問題。
**第一個問題，混部的目的是什麼？**混部的目的是在保證在線業務服務質量的前提下，實現閒置資源複用，提升總體資源利用率。保證在線業務服務質量是前提，使之不受影響，沒有這個前提，利用率提高再高也毫無心義。
**第二個問題，什麼樣的應用適合混部？**適合混部的應用有兩類：一類是算力要求很高的週期性應用，一般是一些離線計算任務。一類是容易形成資源浪費的應用，一般是一些長時間運行的、具有潮汐現象的在線服務。但要注意，有些在線服務會對某些資源有較高的敏感性，這類服務是對混部系統的最大挑戰，由於稍有不慎就會偏離混部的目的，影響了在線服務質量，得不償失。
在肯定了這兩個問題以後，咱們來看下混部系統須要有哪些機制。一般分爲三層：
一是對混部應用進行特徵畫像、定級以及分配資源配額的應用管理層。這一層定義應用的級別，混部的時機，以及經過配額保證資源分配不失控。
二是對混部集羣進行調度、隔離、資源複用和避讓的核心繫統。這一層是混部的核心，基本決定了咱們的集羣能達到什麼樣的混部效果。
最後，還須要一整套適配的自動化運營系統。
混部的基本原理是對閒置資源的再分配。一般，閒置資源有兩個來源。集羣內會有碎片資源，這是資源分配顆粒度問題致使的，這些碎片資源能夠分配給顆粒度更小的應用使用。另外，在線服務申請的資源一般會大於實際使用的資源，配合應用畫像，預測出這部分服務的波峯波谷，能夠將這部分閒置資源分配給其餘應用。
基於這個背景，引伸出混部最核心的兩個子模塊：資源複用和任務避讓。顧名思義，資源複用就是把上述兩種閒置資源經過預測、回收的機制，實時再分配給混部應用使用。而任務避讓，就是檢測核心在線服務是否收到了混部的影響。一旦發生干擾，立刻觸發衝突處理機制，進行壓制和再調度等操做。
能夠這麼說，這兩個模塊決定了混部的效果和可混部的應用範圍。除了理論上的問題，還有一些重要的點必須考慮：爲了保證混部效果，頻繁對集羣實時狀況進行預測和資源回收，對集羣自己帶來了額外的負擔，如何在儘量資源複用和儘可能下降資源預測回收頻率之間找到平衡？還有，爲了保證在線服務的質量，任務迴避一般不可避免，這就下降了次優先級應用的執行效率，高負載時可能致使任務的頻繁重試和堆積，進而可能拖累整個集羣。
爲了解決這些問題，騰訊云云原生團隊作了一直在思考和嘗試，目前較先進的一種方式是經過 serverless 容器即彈性容器，來拓展整個混部集羣的資源池。
彈性容器是騰訊雲推出的無服務器容器產品。它支持一種能力，相似開源virtual kubelet 的方式，但又相比開源方案能力更強、更適合生產。它支持在一個既有 K8s 集羣中經過部署虛擬節點的方式把 pod 調度爲彈性容器。調度爲彈性容器的 pod 與原集羣中的其餘 pod 網絡互通，若是關聯了service ，service間也可互通。
因此不管是已有 workload 的擴容、仍是新的 workload，均可以以一種平滑的方式進行調度。且該能力對集羣不會產生額外的維護成本。
這個能力對混部的核心價值在於：它無成本的擴展了集羣資源池，下降了資源衝突的風險，提高了混部集羣的冗餘度和適用性。另外，在檢測到資源不足之類的衝突時，在不少場景能夠不停止次優先級任務，而是視狀況擴容或再調度，在彈性容器上繼續運行任務，秉持儘可能不打斷已啓動任務的原則，提高整個系統的效率。
這類混部集羣的幾個典型場景：
一、低負載時進行任務填充，運行更多任務，提高集羣資源利用率。
二、萬一發生了在線服務干擾，封鎖相關節點，驅逐次優先級任務到虛擬節點，讓其繼續運行。
三、發生集羣資源緊張時，封鎖相關節點，視狀況，若是是可壓縮資源緊張，好比 CPU、IO 等，則壓制次優先級任務；若是是不可壓縮資源緊張，如內存、存儲等，則驅逐次優先級任務到虛擬節點；在此狀況下全部新增 Pod 均調度到虛擬節點，再也不對集羣固定資源增長任何壓力，避免發生雪崩。
這3個例子還不能覆蓋全部的混部場景，但已經提高了原生 K8s 集羣混部的適用範圍。咱們也在持續探索其餘的路徑來作到更好。也歡迎有想法的朋友下來一塊兒探討和分享。
最後，混部是一個持續優化的過程。各家大廠都對混部投入了至關長的時間研究，纔開始放量鋪開。隨着技術的發展，K8s 混部的效果會愈來愈好，適用的場景也會愈來愈多。謝謝你們！
Kubernetes 混部與彈性容器（本文） PPT 下載方式，請在公衆號騰訊雲原生後臺回覆關鍵字「EKS」獲取。
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公衆號，及時獲取更多幹貨！！