kubernetes 降本增效標準指南｜ProphetPilot：容器智慧成本管理引擎

作者

田奇，騰訊雲高階工程師，專注大規模離線上混部，彈性伸縮，雲原生成本優化，熟悉Kubernetes，關注雲原生大資料、AI。

王孝威，騰訊雲容器產品經理，熱衷於為客戶提供高效的 Kubernetes 使用方式，為客戶極致降本增效服務。

前言

隨著 Kubernetes 的普及，企業已經普遍接受了容器，正在向雲原生演進。但是當前的 Kubernetes 只解決雲原生的第一步（Day 1），就是利用容器編排排程和宣告式API等，來解決資源獲取、應用部署、高可用容災、基礎運維等難題。但是目前採納 Kubernetes 的企業也遇到了前往高階階段的問題，運營龐大複雜的 Kubernetes 叢集是非常困難的，例如：

• 如何評估資源需求？例如：原生 Kubernetes 的排程需要根據容器對資源的請求（Request），一個容器到底需要多少資源量？叢集整體的資源量該設定成多少？節點數多少才合適？
• 如何達到真正的智慧擴縮？如何靈活處理具有波峰波谷的變換流量？如果要設定 HPA，到底該用哪個指標？副本數的變換範圍如何設定？
• 如何檢視容器的成本狀況？目前叢集本身可以檢視資源使用量、利用率情況，但這些資源對應的賬單具體是多少？Kubernetes 叢集裡面可能有節點、硬碟、網路、LB 等多種資源，如何聚合這些離散的資源賬單，並以不同維度展示？
• 如何提高資源使用效率？如何識別無效和不合理的資源申請負載？如何最合理的選擇節點的規格和計費型別？
• ...

以上這些問題都需要在運營 Kubernetes 的第二步（Day 2）來解決：

降低使用者的運營複雜度，為 Kubernetes 插上智慧引擎，減輕客戶的運營負擔，是 TKE 一直以來致力的事情。在前幾期的“降本增效”系列文章中，我們談到了成本控制系統、常用的利用率提升工具、資源利用率現象剖析、理解和應用彈性。TKE 在使用者需求的基礎上，提出容器智慧 ProphetPilot，本文將從背景現狀、產品功能、分層模型闡述 ProphetPilot 相關概念。

背景和現狀

當前 TKE 上有很多關於彈性、資源利用率、成本節約、負載感知排程元件，比如 HPA、HPC、VPA、CA、在離線混部等產品，更多可檢視資源利用率提升工具大全。雖然目前 TKE 為客戶帶來了豐富的降本增效產品選擇，但是存在以下幾個方面的不足；

1. 使用者面對這麼多伸縮元件，往往難以抉擇，當前應用最為廣泛的也是有 HPA 和 CA，其他的元件往往不敢使用或者不知道何時該使用，以及為什麼需要採用
2. 有些元件是社群元件或 Kubernetes 原生能力，功能往往還不夠強大，比如 HPA，擴縮容感知不夠及時和準確，並不一定滿足客戶的需求
3. 元件之間缺乏協調一致的體驗，各自擁有各自的功能，甚至一起使用會發生衝突，例如 VPA 和 HPA 不能同時使用 CPU 或記憶體的指標

下圖對比了各個元件之間的聯絡，主要從 Observer、Analyzer、Action 來說明各個維度的關係：

• Observer（觀測）：監控和收集工作負載的執行狀態
• Analyzer（分析）：分析它的執行模式。例如：
  例1. 負載的 CPU 使用量是否是週期性的變化？
  例2. 負載是否在某些固定時刻流量會上升或下降？
  例3. 負載裡容器的 Request 是否設定合理？等等
• Action（動作）：根據分析負載的執行模式，執行最佳的策略。以 Analyzer 維度的例子來看，例1可以推薦使用 HPA，例2可以推薦使用 HPC，例3可以推薦使用 VPA

功能簡介

ProphetPilot 主要解決 Observer 和 Analyzer 兩大部分，其功能可貫穿彈性和混部所有元件，針對開源元件無法滿足需求的場景，TKE 採用自研 Executor，來滿足快速發展的業務需求：

推薦中心

推薦是整個成本管理中心的大腦，他會衡量和計算 Cost（成本） 和 Efficiency（效率，主要指的是資源利用率）、Reliability（可用性、穩定性） 的關係。例如：

• 當前的叢集是不是適合使用在離線混部。為什麼適合使用在離線混部？原因可能是因為它觀察到大部分容器的指標是週期高低峰，但是又沒有穩定的離線高負載容器，因此建議使用者執行混部，從而提升資源使用效率；

• 當前的叢集中，有些容器的資源利用率一直是平穩型，且資源較低，則推薦進行 VPA 操作，變更 Request 和 Limit，如果使用者是“富容器”，不願意接受顯示的 Request Limit 變更，則直接進行混部建議，因為混部會修改CGroup，這個對使用者不可見，但是可以提高資源利用率，且排程更多 Pod；

• 當前的叢集負載情況，是不是需要進行 CA操作？傳統的 CA 只是簡單感知 Pod Pending，基於 Request 計算資源不足。然而此時叢集的資源使用率可能是非常低的，此時更合適的操作是 VPA。由於目前很多企業無法接受 VPA 變更 Pod 的 Request 時會重建 Pod，TKE也即將支援原地更新；

• 當前是否能夠進行 HPA？傳統的 HPA 只是簡單的從監控定期更新資料。突發流量時，感知緩慢，而推薦中心能夠協同本地感知，聯合其他副本一起協同，快速進行 HPA 的動作，從而做到秒級 HPA 快速突發擴容；採用 eBPF，在感知到某種系統呼叫過度時候，直接配置事件觸發擴容；

• 針對傳統的 PaaS 平臺，比如 DBA 叢集，這部分叢集的應用特徵都具備資料庫的特性，而經驗豐富的 DBA 對資料庫的特徵、引數調優具備更多的優化經驗，我們允許 PaaS 平臺自定義推薦中心的推薦策略，從而讓 PaaS 平臺方做到極致的業務資源優化，成本控制，穩定性保證；

• 針對傳統的各類通用 Web 服務，計算服務等非中介軟體、DBA 業務，這部分客戶，一般都是儘量減少其運維量，為了降低這部分客戶的管理複雜度，運維成本，TKE 會結合真實的監控資料，根據分層模型，推薦以下內容：

  1. 智慧推薦 Workload 的 Request 和 Limit；
  2. 叢集資源評估，根據叢集歷史負載水平，評估資源量；
  3. 根據當前 Workload 的 QPS 和負載情況，推薦合理的副本數；
  4. 預測當前 Node 和 Pod 的資源使用量，反饋給排程器，做智慧排程；
  5. 推薦組合購買的雲例項，以最低價格、最合理的配置基於使用者購買建議。

成本分析

成本分析重點在於從成本的角度觀察叢集的成本使用情況，因為現有的 Kubernetes 叢集中，只能看到資源的使用情況，而無法分析和觀察更具體的成本維度的資料。主要功能點包含：

1. 負責展示業務的成本消耗，資源消耗，資源使用效率
2. 分析 Top10 資源消耗的業務，推動業務進行資源優化、改造
3. 分析叢集的下月預估成本，每個資源物件的下月預估成本
4. 檢視成本曲線、業務增長曲線和成本曲線對比
5. 根據推薦中心推薦的方案預估的成本節省
6. 多維度的觀測：節點/名稱空間/工作負載/Pod/Container
7. 多週期的觀測：日/周/月/自定義
8. 定期生成報告
9. 儲存歷史重要資料

告警通知

不管是否自動執行策略，在 ProphetPilot 發現叢集中某些配置不合理，或某些動作需要執行時，都會提供相關的提示和告警。此外，每一次策略推薦，動作執行，都會進行資料儲存，方便使用者檢視歷史事件，以及事件觸發的原因，方便進行歷史回溯。

策略

策略是推薦中心推薦的方案執行的方式，ProphetPilot 將提供多種策略，主要分成四種型別：

1. 自動執行策略：完全的自定義執行策略，包括自定義設定一些觸發標準，例如：電商裡的訂單業務對穩定性要求很高，可以設定比較大的資源使用冗餘，及時資源利用率很低也被判斷為正常情況。但一些離線批處理任務優先順序不高，對時延不敏感，可以設定較高的資源利用率標準；
2. 計劃執行策略：在未來的某一時刻點執行某種策略；或者是當推薦動作產生後，延遲一定時間執行動作。例如當節點數縮容、工作負載水平縮容時，可以儘量慢一些，防止流量再次飆升；
3. 週期策略：類似 CronJob，定時按週期執行某些策略；
4. 人工確認策略：完全手工的行為，ProphetPilot 不會自動執行這些策略，當推薦動作產生後，會通過告警通知客戶手工執行策略。

執行引擎

執行引擎就是執行的具體動作，例如 HPA、VPA、在離線混部等動作，更多可檢視資源利用率提升工具大全。

容器智慧分層模型

應用層

隨著雲原生、微服務架構的普及，一套企業應用往往涉及到多個微服務，服務之間存在微妙的依賴關係，理解應用的微服務之間的關係，可以讓彈性伸縮擁有更加全面的視角，防止單一的區域性視角，導致擴容了 Workload 也沒有達到真實的效果，從而浪費了資源和成本。

比如下圖中，傳統的彈性伸縮往往只根據資源使用率，當 CPU 使用率很高的時候，觸發該 Workload 的擴容，但是 CPU 使用率高，可能只是假象，在下述列子中，NGINX 日誌寫的速率，Kafka 生產者寫入 Kafka 叢集的速率，日誌偏移更改速率，消費速率，以及 ES 索引計算效率都有關聯性；找到更關鍵的指標比如 Kafka 的生產速率就是比 CPU 更好的擴縮容指標：

ProphetPilot 理解應用層不同的應用特徵，市面上的這些中介軟體、資料庫等基礎產品都可以作為應用劃分，而服務本身也可以根據重要程度，為應用劃分出不同的等級，微服務之間的呼叫關係，則可以通過 ServiceMesh 進行獲取，從而在應用層建立起 Workload 的相關性依賴圖，做到業務的整體擴縮，而不是 Workload 的單獨擴縮。

排程層

分散式資源排程

當前的 Kubernetes 只解決企業雲原生的第一步（Day 1），讓企業能夠利用容器以及 Kubernetes 編排排程，來解決資源獲取、應用部署、高可用容災、運維等難題，但是它在資源模型上，還處在初級階段，比如研發需要評估服務到底需要多少資源，然後填寫 Request，最終 Kubernetes 按照 Request 做靜態資源排程，將 Pod 排程到合適的Node 上。

這樣做將面臨以下問題：

1. 研發為了服務穩定性，往往過度評估資源，造成浪費；

2. 研發根本不知道怎麼評估，甚至是沒有評估資源，相信大部分研發沒有辦法一眼看穿自己的服務需要多少資源，造成資源不足，或者是資源浪費；

3. Kubernetes 是按照靜態的資源排程的，實際容器執行後資源的使用狀態和排程的靜態資源決策是不一致的，造成資源浪費，或者資源爭搶嚴重。

當前的普遍做法是做超售，一般是兩個維度：

1. Node 維度超售，給節點設定超售，比如節點本身只有48核，但是可以設定超售2倍，讓他給排程器造成一種假象，按照96核排程；因為不同的節點計算能力和記憶體不匹配，計算能力強的節點，我們可以讓其 CPU 超售，從而能夠排程更多的 Pod，提高資源的分配效率；

2. Pod 維度超售，其實是配置 Limit 和 Request 之間的比例，同時在使用者心裡模型上，對於使用者宣告的資源到底保證的是 Limit 還是 Request，其實不同的企業有不同的方案；比如在某些企業就是以 Limit 來作為研發資源保證，研發在申請資源的時候填寫 Limit，容器平臺做 Limit 和 Request 的超售轉換，從而提高資源的分配效率；而在雲原生的模式中，Limit 和 Request 的概念直接暴露給了使用者，在 Kubernetes 中，Request 指的是可以保證的資源（因為 Kubernetes 按照 Request 排程分配資源）最少可以使用多少資源，而 Limit 指的是資源限制，最多使用多少資源。

而要解決這個問題，根本原因就在於當前的體系是按照 靜態資源排程，而非動態資源排程，如果我們按照容器的 Usage（可以加上一定的緩衝區間） 資源去排程，而不是按照容器的 Request 資源去排程，那麼我們就能做到真實的按量付費，就是真實的 Serverless 所宣稱的按量計費。

ProphetPilot 會統一進行資料計算，準確推薦出容器的資源消耗，並給出合適的資源配置建議；讓容器的 Request 逼近 Usage，從而讓排程器按照 Usage 排程資源。

單機容器排程

容器在單機層面，會根據分配的資源 Request 和 Limit 來做資源分配排程和資源隔離，雖然可以在一定程度上做到資源的隔離，做到資源的共享和複用，但是 Kubernetes 提供的這個資源模型目前還是比較基礎和簡單的模型；

Kubernetes 直接使用 Request 來排程，對 Node 進行裝箱，在單機層面，Linux 採用 Cgroup 的 CPU Share 模式來為容器分配 CPU 資源，按照 CPU Share 權重劃分 CPU 時間片，如果將一個 Node 按照Request 裝滿，則 Node 的 CPU 資源將按照 CPU Share 加權劃分給所有的容器；看起來是一個完美的計算模型，但是其實核心並不能完美的處理所有場景下的資源爭搶。

比如，在離線混部場景下，離線業務利用多核平行計算提高計算資源利用率，若沒有進行獨佔綁核劃分，此時線上業務如果有流量高峰，就會受到離線業務的干擾，從而影響線上業務的SLA；核心層解決這個問題，需要非常雄厚的技術實力，往往還是得進行應用優先順序劃分，進行取捨，才能讓資源利用率提升的同時，高優保證高優先順序應用，而丟棄低優先順序應用，所以，劃分應用優先順序，或許是未來的方向，這個不僅僅是應用層，從應用層，到 Kubernetes，再到核心層，這個體系需要疏通，當前的 Kubernetes 使用的預設優先順序只有三種，未來可能會支援更多優先順序。

（圖片來源 https://mp.weixin.qq.com/s/Cbck85WmivAW0mtMYdeEIw)

ProphetPilot 允許使用者定義多種負載優先順序，從而能夠針對不同優先順序應用採取不同的服務保證；值得注意的是，過多的優先順序，會導致 容器驅逐產生級聯效應，所謂級聯效應是指，一個容器因為在當前節點資源不足被驅逐，然後被排程到另一個節點，結果導致另一個節點上更低優先順序的Pod被驅逐，要避免這種情況，ProphetPilot 將採取彈性例項，從而防止級聯驅逐發生。

同時，有些客戶希望在離線混部的時候，離線應用不能無限制被驅逐，要求離線應用必須有一定的 SLA，保證其在規定時間內跑完，對於這種需求，我們採用動態優先順序排程和彈性例項結合的方式，在離線 Pod 被第一次驅逐後，就會考慮其驅逐次數和計算時間，如果計算發現繼續驅逐的話，無法保障 SLA，則進行優先順序提高排程，如果還是沒有資源，則進行彈性公有云例項。

資源層

在雲端計算普及的今天，雲廠商提供了一系列可供選擇的 IaaS 計算資源、儲存資源、網路資源，比如就騰訊雲的CVM來說，就有幾百種產品規格，智慧容器模型在資源層應該選擇出最適合的 IaaS 資源，從而保證容器能夠穩定、高效、最低成本的方式執行。

計費模式

騰訊云云伺服器提供了按量付費、預付費、競價例項三種計費模式，不同的計費模式有不同的使用場景；ProphetPilot 能夠分析客戶叢集歷史的例項計費模式，結合叢集資源的未來走勢和使用者對於成本的訴求，推薦不同的計費例項；

1. 按量計費：比如在叢集中，如果使用者設定了電商大促等策略，則可以在規定時間開啟使用按量計費的例項，在時間結束則下掉；
2. 包年包月：比如在叢集中，如果觀察有服務長期執行超過1個月甚至更長，但是卻選擇了按量計費，此時如果更換為包年包月將會更加划算；
3. 競價例項：比如叢集資源不足，同時當前可能只是需要短時間執行離線任務，對於服務保證要求不高，但是對於成本有控制，則此時可以採用彈性競價例項的模式；

機型配置

機型主要是CPU、記憶體、磁碟等配置，包括硬體型號以及規格大小，ProphetPilot 通過評估叢集節點資源，以及業務規模，未來增長趨勢，在滿足業務資源需求的前提下，通過搜尋不同機型配置和價格空間，最後推薦出合理的機型配比；

雲模式

雲的當前演進模式是 混合雲，而客戶 IDC 和 公有云的彈性資源拉通，評估 IDC 資源是否充足，是否需要開啟彈性到公有云，以及彈出何種 IaaS 資源例項，是企業目前的難題，當前的模式往往還是傳統的提前按規劃批量採購模式，企業一部分資源是 IDC，一部分資源在公有云，還是存在資源閒置問題；打通混合雲網路後，企業將能夠實現真實的隨時按需彈性。

總之，在資源層面，ProphetPilot 會分析使用者叢集的節點規格分佈，資源使用效率，最終推薦客戶最合適的計費模式、節點規格配置。

總結

Kubernetes 叢集資源利用率低的本質是 Request 機制，即資源的預留和佔位機制。業務為了保證自己服務的穩定性，通常習慣申請較大的 Request，勢必會造成較大的資源浪費。如果能按照 Usage 來排程資源、調整負載，甚至是按照 Usage 來付費，做到真正的按需使用，這是成本管理終極形態，也是 ProphetPilot 的目標狀態，讓業務無需管理和配置任何資源的同時，保障服務的穩定性，實現“用完即走，隨用隨取”。如果您有任何建議或訴求，歡迎通過小助手與我們聯絡。

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！