本文整理自騰訊云云原生產品團隊的專家產品經理韓沛在 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”獲取。
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！
