2022年6月30日，中國信通院、騰訊云、FinOps產業標準工作組聯合發起的《原動力x云原生正發聲 降本增效大講堂》系列直播活動第2講如期舉行，騰訊云容器技術專家胡啟明分享了Kubernetes云上資源的分析與優化。

胡啟明是開源項目Crane的Founder和負責人，專注Kubernetes云原生領域8年，負責專有云容器產品、云原生應用平臺的研發和管理，是Kubernetes、Dapr、KubeEdge等多個開源項目的Contributor。本文整理自胡啟明的分享。

Kubernetes云上資源管理

Kubernetes資源模型：Request和Limit

Request代表Kubernetes應用聲明它希望獲得的最小的資源使用量。

Limit代表Kubernetes應用聲明它希望獲得的最大的資源使用量。

Kubernetes的調度器，會根據Request的申請量去調度應用到Kubernetes的節點上。

資源預留帶來的資源浪費

關于Request的模型，用戶設置時存在一個問題：用戶的開發者不一定對業務線上運行情況完全感知。例如：不知道業務在線上運行時需要多少CPU和內存，以及業務洪峰的場景下資源使用量會上漲的維度。因此，基于這些問題，在業務開發、運維在配置Request時，開發者會選擇保守策略，常把配置設高。

同時，也帶來另一個問題：資源浪費比較顯著。如下圖所示，應用的Request聲明了4個核，但實際使用不超過2個核。這都是由于保守、業務運行不了解帶來的資源浪費。

資源緊缺帶來的資源浪費

CPU是可壓縮資源。當CPU緊缺時，實際用量可以超過CPU總量，此時會出現資源的爭搶，導致應用處理程序速度變慢。

內存是不可壓縮資源，如果業務運行中超過了上限，就會呈現下圖的情況。

如上圖所示，Kubernetes中的節點上部署了兩個容器，它們在處理業務都有規律：

在晚上，業務的使用量會降低，白天高峰期業務容量就會偏高；

晝夜規律比較相似，相似的業務部署在了同一個節點上；

業務高峰期，容器的內存用量會達到它的Limit值，但由于調度應用是根據Request完成的，會導致在業務高峰期節點上內存被耗盡。

資源被耗盡時候，會發生什么事？

如果節點的內存耗盡，Kubernetes會按順序驅逐容器，排序規則是容器實際內存使用超出Request的用量。如果去驅逐用量大于Request的東西，業務就會發生損傷，因為它的容器被Kill，并且這時候往往是處在于業務的高峰期，使業務受到損傷。

如果容器內所有的進程分配的內存超過了內存Limit，節點上的OOM Killer會立刻Kill這些進程。這種場景下，業務的使用也會受到損傷，用戶也會感知。這導致了應用開發者或者SRE去配置資源時會采取保守策略，以保證業務穩定性和正確性，這加劇了云上資源浪費。

大量資源無法使用導致資源浪費

當業務上了Kubernetes等云原生平臺后，它的資源的用量和與使用率會偏低。下圖顯示資源總量很大，但實際使用量卻很低，導致大量資源的使用浪費。

Kubernetes彈性伸縮HPA工作原理

HPA工作原理如下圖所示。

在云上，用戶通過Service+Load Balance，請求到一個Deployment，Deployment里有幾個Pod。為了讓Deployment+Pod在用戶流量增大時自動擴容，在流量減少時自動縮容，達到按需計費，于是創建了HPA。

HPA會讓用戶設置最小的副本數和最大的副本數，并且用戶設置目標的CPU使用率。根據目標使用率，在最小副本數和最大副本數之間做自動彈性伸縮。

HPA在社區發展了已有3~4年，版本目前達到v2，功能比較完善。社區的HPA不但支持基于K8s內置的CPU和Memory指標，還提供了豐富的擴展能力customer metric、External metric的外部指標，讓用戶可以通過外部的監控指標來對業務做彈性。

最常見的基于Prometheus的adapter，讓用戶基于Prometheus的metric自動做彈性。社區有一個開源產品叫KEDA，它專注于通過Event Driven的方式讓業務做彈性。本質是使用了HPA，把一些基于Kafka、MQ數據的event去做彈性的輸入，通過external metric的方式讓HPA去做水平彈性。

HPA原生能力不足

社區的HPA也有局限性，主要在兩個方面。

在業務流量的洪峰來臨時來不及擴容。例如：用戶MQ的connection會提升，隨著message數量會增加，CPU的用量會提升，但如果資源洪峰已經來臨時，再去擴就常常會發現來不及。一方面原因是Event Driven，洪峰來臨再去彈，另外一方面的原因是容器化的業務啟動速度趕不上流量來的速度。由于業務系統慢，導致很多業務沒辦法使用社區的HPA。

流量抖動。在下圖的“深V”時間點內，如果使用HPA將導致HPA的副本劇烈抖動。雖然HPA里有個behavior的功能可以減少抖動，但調大behavior減少抖動時，HPA的彈性會變得遲鈍，導致彈性效果不理想。

VPA工作原理和局限性

VPA工作原理如下。

首先，用戶會創建一個VPA的對象，它會有VPA的Recommend，便于定期獲取VPA里面的彈性配置。同時，Recommend也會去從ApiServer拿到整個集群中的狀態信息。通過VPA的算法，根據這兩個信息計算出用戶應用推薦配置CPU和memory的數量。最后，根據資源配置推薦信息更新到VPA上去。

還有一個組件叫做VPA Updater，它會去獲取彈性配置，并且感知到配置后，需要把Pod重建，配置它才能生效。因此，VPA Updater會對Pod做Eviction。眾所周知，當Pod做Eviction時，它會自動創建新的Pod來替代它，新的Pod的創建請求會被VPA Admission plugin給攔截，攔截之后它會把VPA上面的彈性配置更新到Pod Spec，新建的Pod就會使用VPA推薦的資源配置。

在現實中，VPA的落地場景其實不多，因為VPA有其局限性：業務很難接受隨時重建的Pod。

例如一個業務正在接受一個用戶的數據處理，這時Pod重建了，用戶的業務使用就會受損， Pod 重建無法通知到業務，并且一定會對業務造成影響，導致很多時候在生產環境很難使用VPA。

基于Crane的Kubernetes的資源分析與優化

Crane是騰訊的一個基于Kubernetes的開源項目，全稱是Cloud Resource Analytics and Economics，譯為“云上資源的分析和降本”。

Crane是基于FinOps的理論來去編排設計的能力模型，從下往上看分為五層：

Understand Fully Loaded Costs：多維度業務成本分攤表、標簽管理、分期賬單、預算和配額管理等。

Enable Real Time Decision Making：資源利用率報表、異常識別、識別資源浪費等。

Benchmark Performance：趨勢和變化分析、評分和PKI、內部評比、跨供應商評分對比等。

Optimize Usage：支持的資源優化的能力，比如資源回收再分配、Request推薦、基于預測的智能彈性、機型推薦等。

Optimize Rate：提供計費方面的能力，比如計費方式推薦、抵用券支持等。

云上資源的分析和優化

下圖展示的是Kubernetes云上資源的分析和優化的能力。

Kubernetes里有個重要的概念，叫做Infrastructure as Code。Kubernetes上所有資源都是可以通過YAML配置的方式來去聲明，例如Deployment、Job、PV、SVC、node、CPU，都可以用通過一段YAML配置來去聲明。Crane提供了一套分析推薦的插件能力，去分析Kubernetes中的云資源。

同時，輸入的一方面是云資源，另一方面是Kubernetes的觀測數據，例如Deployment對應CPU的使用率，內存的使用率，都是觀測數據。

“云資源+觀測數據+分析算法”作為一個輸入，再加上資源推薦的插件，能給用戶推薦優化的建議。比如，資源推薦的插件會根據用戶的應用配置、實際使用量、推薦算法，得到建議資源CPU和memory的配置值。

在分析結果之后，還可以利用一些工具包，比如Kubernetes的插件，把資源優化的分析結果匯總給用戶，讓用戶能夠觀測到優化結果。優化結果通過API去計算云端費用的節省，幫助用戶在云上做成本決策。

云上資源的分析與優化，還提供了一個插件系統。用戶可以自定義推薦的插件，使用推薦的framework插到分析的推薦系統中去，實現自定義分析和推薦的邏輯。

資源推薦

下圖展示的是資源推薦中的訴求、方案以及成效。

從“讓應用的資源配置更簡單”的訴求出發。

Crane方案是根據應用的歷史用量推薦，支持按照機型規格做調整，基于VPA的算法進行資源推薦。很多業務都跑在Serverless構上，Serverless架構上的資源規格、機型規格都會做規整，例如1.5Core/3G的資源就會向上規整到2Core/4G上，Crane的推薦結果會根據規則做規整，同樣是基于VPA算法。

成效如上圖右側所示，沒有使用資源推薦之前，很多業務的機型是偏大的，經過資源推薦優化之后，用戶采納推薦配置并且重建了容器。資源推薦是使用推薦建議的方式，讓用戶去選擇時間和是否采納建議。在用戶采納之后，才會去批量的rolling更新，避免VPA隨時更新應用的配置，導致應用被重啟的問題。

副本/彈性推薦

下圖展示的是副本/彈性推薦中的訴求、方案以及成效。

從“讓應用副本配置更簡單”的訴求出發。

Crane方案會去掃描集群中的應用，根據它的應用歷史用量，基于HPA的算法計算未來副本數。其中，部分應用用量有晝夜規律波動，這類業務則可以推薦它的副本配置，實現降本。對于能夠支持動態擴縮、有規律性的業務，可以配智能彈性Effective HPA，用戶進行降本增效。

成效如上圖右側所示，大部分業務配了很多副本數，但經過計算發現降到三個副本也可以滿足業務訴求。

內部大規模落地實踐

騰訊的智能推薦的能力在騰訊內部和自研業務上大規模落地，部署到數百個Kubernetes的集群，管控了數百萬個CPU的核，在全面上線一個月之內，大盤的總和數縮減了25%。

騰訊把集群中資源推薦的建議展現到控制臺里，讓用戶看到工作負載、當前的核數、推薦的資源量、推薦副本數。

該頁面還能幫用戶整理出工作環境中的應用數字、可以被優化的數字以及用戶采納優化建議后能降低多少CPU和內存的使用，通過圖形的方式展現出來，方便用戶去決策。我們還支持基于kubectl插件去分析整個集群中的狀態。

智能彈性—Effective HPA

HPA落地有兩個問題：彈性時間滯后、彈性毛刺。

上圖展示的是智能彈性的功能，Effective HPA。Effective HPA是基于時間預測的算法，通過預測未來的metric使用量去解決問題，它有以下能力。

第一個能力：提前擴容，保證服務質量。采取時間序列算法（Fast Fourier Trans former），可以根據過去7天或者14天的metric，預測未來7天metric變化軌跡。通過預測窗口里面metric的最大值做提前擴容，還會采取metric兜底保護策略。

第二個能力：減少無效縮容。能夠預測未來的一個資源用量，當曲線發生抖動時，因為取的預測窗口中的最大值，所以整個曲線的抖動毛刺程度明顯降低。

第三個能力：支持Cron配置。應對大促、節假日等有規律的流量洪峰。

第四個能力：易于使用。Effective HPA完全兼容社區HPA的功能，還支持Dryrun觀測，指標支持Prometheus Metric。

下圖展示的是Effective HPA的架構。

用戶創建Effective HPA的對象后會生成兩個資源對象：

一個是TimeSeries Prediction；

另一個是社區原生的HPA。

TimeSeries Prediction是時間序列預測的Controller的對象。創建后有一個組件叫Predictor開始從Prometheus中拿取應用歷史數據，并且通過預測算法得到未來持續預測，把預測結果更新到TimeSeriesPredicton中。

社區HPA在創建后，HPA的Controller就會工作。定義中的metric的配置向Kubernetes的ApiServer請求。一方面，它會去向Metric server去請求它的CPU的用量。另一方面，它向Crane metric adapter去請求預測數據。

最后，Metric-adapter會從TSP中獲取它的預測數據，并且把結果返回給HPA Controller。HPA Controller將兩個源頭數據通過HPA算法，計算得到較高的副本數，并且用副本數更新到真實的應用中，這就是Effective HPA智能彈性的工作過程。

CronHPA 、KEDA、Effective HPA有什么差異點呢？如下圖所示。

CronHPA是通過修改HPA的配置去控制底層的HPA，并且控制應用的彈性伸縮。由于它是自動修改HPA的配置，這就會導致用戶的HPA配置能力遭到弱化。

KEDA實現原理是為每一個框配置生成metric。但它的問題是在Cron的周期之外，KEDA的Cron配置會自動把用戶的應用縮容到一個副本，原因是它把每一個Cron都定義成了metric。由于metric定義互相不感知，就導致metric返回的默認值只能設置為1，因為它不能夠去影響別的metric配置。

Effective HPA的Cron配置解決了前兩個問題。通過預測、觀測和周期性觸發策略共同作用、計算和考慮，最后取中間的較大值。Cron的問題也解決了，在用戶配置的Cron周期之內，副本數能夠保持跟當前的配置不變，不會自動縮溶。

智能彈性落地成效

下圖展示的是智能彈性的落地成效。

騰訊內部的安全部門WAP和騰訊的容器服務，在生產環境已經使用了Effective HPA做彈性伸縮器。作為一個開源產品，很多公司對Effective HPA感興趣，并且正在使用。

酷樂家生產環境全量使用。酷樂家原本在生產環境中已經全量使用了HPA，由于沒有辦法提前擴容，導致它的配置相當保守。酷樂家看到Cron的Effective HPA后，將HPA存量切換到了Effective HPA，在生產環境全量使用后，解決了彈性問題，提升了平均使用率。

目前Effective HPA在生產環境已經管控了數千個應用。

平均利用率的提升達到10%。如上圖右下方所示，藍線是預測的metric，綠線是CPU實時的metric容量，黃線是使用Effective HPA后的提前擴容能力。

審核編輯 ：李倩