服務器資源利用率較低，IT 基礎設施的總擁有成本（TCO）逐年上漲，一直是困擾很多企業的難題。隨着雲原生技術的發展，Kubernetes 逐漸成爲數據中心的一項基礎設施，將在 / 離線業務統一使用 Kubernetes 調度編排日漸成熟。本議題結合網易輕舟在這一領域的工作實踐，介紹如何基於 Kubernetes 通過混合部署，在不影響在線業務的前提下將 CPU 利用率提高到 50% 以上，大幅降低企業數據中心成本。
數據分析顯示，數據中心成本中，服務器採購成本佔比超過 50% ，而全球服務器平均資源利用率不到 20%，並且服務器一般 3~5 年就會淘汰，需要購置新服務器，造成了巨大的成本浪費。
如果數據中心或者機房規模較小，服務器數量有限，很少有人會去關注資源利用率這個問題。因爲在小規模場景下，耗費人力、物力想辦法提高服務器資源利用率並不會獲得太高的收益。如果數據中心規模比較大，提升數據中心資源利用率則能夠顯著降低成本、帶來巨大收益，所以國內外的大型互聯網公司，很早就開始投入大量的人力物力進行較多的探索實踐。
近幾年，隨着網易雲音樂、嚴選、傳媒、有道等互聯網業務的快速發展，網易內部的服務器數量不斷攀升，而實際資源利用率又比較低，IT 基礎設施成本問題日益嚴峻。面對日益增長的業務，我們希望用最小的基礎設施資源成本來支撐更大的業務需求。提升服務器資源利用率成爲一個比較重要的解決手段。
網易輕舟團隊提出了一套基於 kubernetes 的業務混部方案，目前已經在網易內部得到廣泛應用，在不影響業務 SLO（service-level objective）的前提下，資源利用率得到顯著提升。
資源利用率現狀和原因分析
麥肯錫數據統計顯示，整個業界的服務器平均利用率大約爲 6%，而 Gartner 的估計要樂觀一些，大概在 12%。國內一些銀行的數據中心的利用率大概在 5% 左右 。
而造成利用率比較低的原因主要有以下三個方面：
不同類型的業務劃分了獨立的服務器資源池
絕大多數企業在構建數據中心或者機房的時候，對於在線服務（latency-sensitive service）和離線服務（batch job）是單獨採購機器並且分開管理部署的，各自採用獨立的資源調度管理系統（比如離線業務使用 Yarn 調度，在線業務 Mesos 調度），從服務器採購、規劃到業務調度層面都是完全隔離的。
圖 1(b) 是 Google 專門運行在線應用的 2 萬臺服務器 CPU 利用率分佈圖，大部分處於 30% 左右。圖 1© 是 Google 專門運行批處理作業的 2 萬臺服務器 CPU 利用率分佈圖，大部分在 75% 左右。
在線業務 SLO 要求較高，爲了保證服務的性能和可靠性，通常會申請大量的冗餘資源，因此，會導致資源利用率很低、浪費比較嚴重。而離線業務，通常關注吞吐量，SLO 要求不高，容忍一定的失敗，資源利用率很高。
假如將離線業務跑在在線業務的機器上，充分利用在線業務的空閒資源，那是不是就能節省下離線業務的服務器成本了呢？
服務的 reserved 資源和實際 used 資源存在較大 Gap，通常 overprovision
業務通常是有波峯和波谷的，用戶在部署服務時，爲了保證服務的性能和穩定性通常都會按照波峯申請資源，即 provision resource for the peek load，但是波峯的時間可能很短。另外，也有相當一部分用戶對於自己服務的資源使用情況不是很瞭解，在申請資源時具有較大盲目性，但是通常也是申請過量資源而不是申請的過少。
圖 2 是推特數據中心資源使用情況，可以看到 cpu 利用率大約在 20% 左右，但是用戶申請了 60% 左右的 cpu 資源；內存利用率在 40% 左右，但是用戶申請了 80% 左右的內存資源 。
服務 A 已申請的但是實際沒有使用的資源，即使是空閒的，其他服務也是不能夠使用的。Reserved - Used差值越大，資源浪費越多。所以我們應該如何去縮小Reserved - Used的差值，從而提高業務部署密度和資源利用率呢？
業務負載具有明顯的時間上的波峯波谷，處於波谷時，空閒資源其他服務無法使用
很多面向用戶的在線服務具有明顯的波峯波谷，比如白天用戶使用量較多，資源利用率相應較高，但是夜間用戶使用量較少，資源利用率相應較低。夜間空閒出來的資源，其實都是浪費的。那夜間空閒出來的這部分資源是不是也可以用來跑離線業務呢？
在 / 離線業務混部
在線業務（latency-sensitive service）：和用戶存在交互的、並且對交互延時敏感的應用稱爲在線業務。例如：網絡搜索服務、即時通訊服務、支付服務、遊戲服務等，延遲對於這些服務的服務質量至關重要，故稱爲“延時敏感”，在線業務通常有着嚴格的 SLO（service-level objective）。
離線業務 (batch job)：和用戶不存在交互，對延時不敏感的應用稱爲離線業務。例如：Hadoop 生態下的 MapReduce 作業、Spark 作業、機器學習的訓練作業、視頻轉碼服務等。這些作業對於其完成時間的容忍度較高，故稱爲“延時不敏感”。離線業務通常沒有嚴格的 SLO 。
混合部署（co-location）：是指將在線業務和離線業務混合部署在同一集羣和服務器上。
傳統的數據中心中，之所以將在 / 離線服務分開部署管理，實屬無奈之舉：
- 混部會帶來底層共享資源（CPU、內存、網絡、磁盤等）的競爭，會導致在線業務性能下降，並且這種下降是不可預測的
- 在 / 離線服務分屬不同的研發、產品團隊，成本管理是分開的
- 在 / 離線服務使用不同的資源調度管理系統，無法統一調度
如果能夠將離線服務跑在在線服務的機器上，充分利用在線服務的空閒資源，則能夠顯著提升資源利用率降低服務器成本。
隨着雲原生理念、容器和微服務的普及，Kubernetes 逐步統治了容器編排領域，成爲數據中心的基礎設施。將在 / 離線業務統一使用 Kubernetes 調度管理，日漸成熟。
接下來，本章節會詳細講解如何基於 Kubernetes 實現在 / 離線業務的混部，在複雜的基礎設施架構下，面對衆多的共享資源，如何實現多維度的資源隔離，最小化在 / 離線業務之間的性能干擾，保證在線業務的運行性能、提升離線業務運行效率。
Kubernetes native feature
因爲要基於 Kubernetes 實現在 / 離線業務的混部，所以需要先了解 Kubernetes 有哪些功能能夠幫助實現混部，以及 Kubernetes 本身存在哪些問題。
Pod Priority
pod 是有優先級（pod priority）的，相應字段是pod.spec.priority，它表示了 pod 的重要程度，值越大優先級越高。調度器調度的時候會優先調度高優先級的 pod，Kubelet 在驅逐過載節點的 pod 時，會優先驅逐低優先級的 pod。
所以，可以將離線任務設置較小的 pod priority。
Pod QoS
Pod 有三種 QoS class：
Best Effort：如果 pod 的 cpu/memory 資源的 request 和 limit 都沒有設置，則該 pod 屬於Best Effort類型Guaranteed：如果 pod 的 cpu/memory 資源的 request 和 limit 都設置了，並且每個資源的 request 值等於 limit 值，則該 pod 屬於Guaranteed類型Burstable: 剩下的則是Burstable類型
其中，Guaranteed pod 對於 SLO 要求最高，有最高的資源保證；Burstable pod 對於 SLO 要求次之，僅保證 request 部分的資源；Best Effort pod 對於 SLO 要求最低，資源無法保證。
Best Effort類型 pod 的 OOM Score 是最大的，也就是說在發生系統 OOM 的時候，首先 kill 的就是Best Effort類型的 pod。
當節點上內存、磁盤等非可壓縮資源負載過高時，kubelet 會驅逐上面的 pod，保證節點穩定性，驅逐的順序是：Best Effort、Burstable、Guaranteed。
所以，是不是可以將離線任務歸爲Best Effort class 呢？
Kubelet CGroup Manager
Kubernetes 是使用 cgroups 來實現 pod 的資源限制的。
圖 4 是 Kubernetes cpu cgroups 的層級，三種不同的顏色表示三種不同的 QoS class：
- kubepods 的 cpu.share 只在 kubelet 啓動的時候設置一次
- besteffort 和 burstable 的 cpu.share，每隔 1 分鐘更新一次. 有 pod 創建刪除也會觸發更新
- pod 的 cpu.share 和 cfs quota 只在創建時設置，後面不再更新
圖 5 是 Kubernetes memory cgroups 的層級，三種不同的顏色表示三種不同的 QoS class：
- kubepods 的 memory.limit_in_bytes 只在 kubelet 啓動時設置一次
- besteffort 和 burstable 的 memory.limit_in_bytes，後面不會更新
- pod 的 memory.limit_in_bytes 只在創建時設置，後面不會更新
之所以在這講一下 Kubernetes pod cgroups 的層級組織結構和動態更新策略，是因爲我們開發的資源隔離組件也是通過更改 cgroups 配置來實現資源隔離的。如果不知道 Kubernetes 原生的 cgroups 管理策略，很容易發生更新失效或者衝突，引發故障。
K8S 本身存在的問題
靜態調度
Kubernetes 是使用的靜態調度。靜態調度是指根據容器的資源請求（resource request）進行調度，而不考慮節點的實際負載。所以，經常會發生節點負載很低，但是調度不了新的 pod 上去的情況。
Kubernetes 爲什麼會使用靜態調度呢？因爲要實現一個基於節點負載進行動態調度的通用框架是很困難的。而靜態調度實現簡單、管理方便，但是對於用戶的要求要高一些，如果 resource request 配置的不合理，可能會導致節點之間負載不均衡以及利用率較低。
隔離性較弱
Kubernetes 是沒有區分在線業務和離線業務的，當前的 cgroups 層級組織結構也很難將在 / 離線業務區分開，很難實現動態的資源分配和動態的資源隔離。所以，也無從談起在 / 離線業務的性能隔離，頂多就是不同 pod 之間的隔離。
而 Kubernetes 對於 pod 之間的資源隔離也是很弱的，僅僅通過 cgroups 在 cpu 維度使用cpu.shares控制發生 cpu 爭用時的時間片分配比例，使用cfs quota限制 cpu 使用上限；內存維度使用memory limit in bytes限制使用上限。
如果貿然將在 / 離線業務混部在同一臺機器上，是無法保證在線業務的 SLO 的。
混部系統設計
我們基於 Kubernetes 實現了在 / 離線業務混部系統，遵循以下設計原則：
- 動態調度：根據節點的真實負載實現離線業務的動態調度
- 動態資源分配和隔離：根據在線業務的負載，動態調整分配給離線業務的資源量，動態執行資源隔離策略，降低甚至消除彼此之間的性能干擾
- 插件化：不對 k8s 做任何 in-tree 的侵入式改動，所有組件要基於 k8s 的擴展機制開發，並且混部系統本身擴展性強
- 及時響應：當混部節點資源利用率過高，或者對在線業務產生影響時，能夠及時發現，並驅逐離線業務，以保證在線業務的 SLA
- 可運維、可觀測：對用戶和運維人員友好，接入成本低，使用成本低
Resource Reclaim
Resource Reclaim 是指回收在線業務已申請的，但是目前還空閒的資源，然後給離線業務使用。這部分資源是low-quality的，沒有太高的可用性保證.
我們自定義了擴展資源colocation/cpu和colocation/memory（分別對應原生的 cpu 和 memory），來表徵上述 reclaimed resource，實現離線任務的動態調度。
節點上在線業務 CPU Usage 高，則我們分配給離線業務的資源就會減少；在線業務 CPU Usage 低，則我們就可以將更多的資源分配給離線業務。
動態調度
基於擴展資源colocation/cpu和colocation/memory 實現離線任務的動態調度，優先將離線任務調度到節點負載較低、離線任務較少的混部節點上，均衡不同節點之間的負載、減少業務之間的資源競爭。
動態資源分配和動態資源隔離
Google 在數據中心資源管理領域，很多年以前就開始投入大量人力、物力。由於硬件在性能隔離上的侷限性，Google 在軟件層面做了大量的改造，率先提出了多項資源隔離技術，包括 cgroups、Container 等（內核的很多功能特性都是業務需求觸發的，而不是憑空想象出來的）。我們對於在 / 離線業務的性能隔離也是主要通過 cgroup 來實現的。
kubelet cgroup manager 沒有可擴展點，直接修改 kubelet 代碼又會給後續的運維升級帶來比較大的成本，因此我們單獨開發了一個zeus-isolation-agent運行在每個混部節點上，通過定時動態更新 cgroup 來實現在 / 離線業務資源隔離。
從 CPU、內存、緩存、磁盤到網絡，我們實現了多維度的隔離策略，顯著降低在 / 離線業務之間的互相干擾。以緩存爲例，我們對內核進行了定製化改造，給在 / 離線業務設置不同的緩存回收優先級，優先回收離線業務使用的緩存。
離線業務的重調度
存在這樣一種場景，剛開始時混部節點上的在線業務較少、負載較低，能夠分配給離線業務的資源較多，因此用戶能夠調度較多的離線業務上去。但是，後來用戶調度了更多的在線業務上來或者在線業務的流量飆升，導致節點上能夠給離線業務的資源非常有限，離線任務執行效率會很低。假如此時，其他混部節點比較空閒，爲了避免離線任務的飢餓、減小業務之間的資源競爭，我們會重調度離線任務到其他 node 上。
離線任務的重調度，主要有如下優點：
- 均衡各個混部節點的負載情況，避免有的節點負載較高而有的節點又過於空閒
- 避免某個節點負載過高，以至於影響到在線業務性能和穩定性
- 提高離線業務的執行效率
但是，重調度也有缺點，如果沒有遠程 checkpoint 機制，會導致重調度之前的算力被浪費。影響程度有多大，是跟單個任務的處理時長有關係的。如果處理一個任務的時長是秒級，那麼重調度的影響是微乎其微的。如果處理一個任務的時長是天級別的，那麼重調度的影響還是比較大的。因此，是否使用重調度功能、重調度的觸發閾值等用戶都是可以實現 workload 級別的配置的。
落地成果
上述在 / 離線業務混部方案已經集成到網易輕舟容器平臺 NCS 中，在網易內部得到廣泛應用，大幅提高了服務器資源利用率，取得顯著成果。
以網易傳媒爲例，傳媒將視頻轉碼業務作爲離線業務混部到了在線業務的機器上，混部後 CPU 利用率從 6%-15% 提高到 55% 左右。
先了解一下視頻轉碼服務的特點：
- CPU 密集型，大量讀寫磁盤保存臨時數據，有一定量網絡 IO
- Long-running pod，而不是一個
run-to-complete類型的 pod，它會從隊列中不斷取視頻任務進行轉碼處理，沒有任務的話就空閒且保持運行 - 轉碼單個視頻的時長在秒級，因此重調度對其影響是微乎其微的
Redis+ 視頻轉碼
Redis 業務是對於時延比較敏感的在線業務，SLO 要求較高，但是其 CPU 利用率較低，因此我們嘗試將視頻轉碼業務混部到了 Redis 專屬節點上，下面我們看一下這兩個在 / 離業務混部的效果。
從圖 9 可以看到，Redis 節點混部前 CPU 利用率在 8% 左右，混部後達到 30~35%，利用率大幅提升。
然後我們再看一下混部前後 redis 的 SET/GET 操作的 RT 對比。
從圖 10 和 表 3 可以看出，混部前後 GET 操作的 RT 基本沒有變化。
從圖 11 和 表 4 可以看出，混部前後 SET 操作的 RT 基本沒有變化。
廣告推薦 + 視頻轉碼
廣告推薦服務也是一個對穩定性和性能要求很高的時延敏感的在線類型業務，下面我們看一下轉碼服務和廣告推薦服務混部取得的效果（節點上還有其他類型的在線服務，這裏我們以時延敏感的廣告推薦服務爲例）。
從圖 12 可以看到，混部之前 cpu 利用率在 10-20% 之間，混部之後 cpu 利用率長時間維持在 55% 左右，利用率提升幅度較大。
混部的目的是提高資源利用率、降低成本，但是前提是不能對在線業務產生明顯的性能影響。因此，我們再看一下該廣告推薦服務的某個核心性能指標在混部前後的變化：
從圖 13 發現，混部前後該核心性能指標是沒有任何衰減和惡化的，混部前的平均 RT 是 6.59ms，混部後的平均 RT 是 6.65ms:
總結和展望
目前，混部已經在網易得到廣泛落地，取得顯著成果。接下來，我們會繼續探索和實踐雲原生技術，基於網易輕舟將混部方案落地到更多企業，讓更多企業享受到雲原生的紅利。
作者簡介
張曉龍，網易技術委員會委員，網易數帆輕舟事業部技術總監，2012 年浙江大學博士畢業後加入網易杭州研究院，負責基礎設施研發 / 運維至今。在虛擬化、網絡、容器、大規模基礎設施管理以及分佈式系統等技術架構有多年經驗，當前主要興趣點在雲原生技術方向。
李嵐清，網易數帆輕舟事業部資深系統開發工程師，具有多年 Kubernetes 開發運維經驗，負責在 / 離線業務混部、容器網絡編排等多個項目，推動和協助網易內部多個業務實現容器化。目前專注於雲原生、分佈式系統架構等技術領域。
陳林亮，網易杭州研究院資深雲計算開發工程師，具有多年雲計算開發，運維及優化經驗，參與開發網易雲計算平臺研發及迭代。目前專注於在 / 離線業務混部、容器編排資源優化等方向。