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

胡啟明是開源項目Crane的Founder和負(fù)責(zé)人，專注Kubernetes云原生領(lǐng)域8年，負(fù)責(zé)專有云容器產(chǎn)品、云原生應(yīng)用平臺的研發(fā)和管理，是Kubernetes、Dapr、KubeEdge等多個開源項目的Contributor。本文整理自胡啟明的分享。

Kubernetes云上資源管理

Kubernetes資源模型：Request和Limit

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

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

Kubernetes的調(diào)度器，會根據(jù)Request的申請量去調(diào)度應(yīng)用到Kubernetes的節(jié)點上。

資源預(yù)留帶來的資源浪費

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

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

資源緊缺帶來的資源浪費

CPU是可壓縮資源。當(dāng)CPU緊缺時，實際用量可以超過CPU總量，此時會出現(xiàn)資源的爭搶，導(dǎo)致應(yīng)用處理程序速度變慢。

內(nèi)存是不可壓縮資源，如果業(yè)務(wù)運行中超過了上限，就會呈現(xiàn)下圖的情況。

如上圖所示，Kubernetes中的節(jié)點上部署了兩個容器，它們在處理業(yè)務(wù)都有規(guī)律：

在晚上，業(yè)務(wù)的使用量會降低，白天高峰期業(yè)務(wù)容量就會偏高；

晝夜規(guī)律比較相似，相似的業(yè)務(wù)部署在了同一個節(jié)點上；

業(yè)務(wù)高峰期，容器的內(nèi)存用量會達(dá)到它的Limit值，但由于調(diào)度應(yīng)用是根據(jù)Request完成的，會導(dǎo)致在業(yè)務(wù)高峰期節(jié)點上內(nèi)存被耗盡。

資源被耗盡時候，會發(fā)生什么事？

如果節(jié)點的內(nèi)存耗盡，Kubernetes會按順序驅(qū)逐容器，排序規(guī)則是容器實際內(nèi)存使用超出Request的用量。如果去驅(qū)逐用量大于Request的東西，業(yè)務(wù)就會發(fā)生損傷，因為它的容器被Kill，并且這時候往往是處在于業(yè)務(wù)的高峰期，使業(yè)務(wù)受到損傷。

如果容器內(nèi)所有的進(jìn)程分配的內(nèi)存超過了內(nèi)存Limit，節(jié)點上的OOM Killer會立刻Kill這些進(jìn)程。這種場景下，業(yè)務(wù)的使用也會受到損傷，用戶也會感知。這導(dǎo)致了應(yīng)用開發(fā)者或者SRE去配置資源時會采取保守策略，以保證業(yè)務(wù)穩(wěn)定性和正確性，這加劇了云上資源浪費。

大量資源無法使用導(dǎo)致資源浪費

當(dāng)業(yè)務(wù)上了Kubernetes等云原生平臺后，它的資源的用量和與使用率會偏低。下圖顯示資源總量很大，但實際使用量卻很低，導(dǎo)致大量資源的使用浪費。

Kubernetes彈性伸縮HPA工作原理

HPA工作原理如下圖所示。

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

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

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

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

HPA原生能力不足

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

在業(yè)務(wù)流量的洪峰來臨時來不及擴容。例如：用戶MQ的connection會提升，隨著message數(shù)量會增加，CPU的用量會提升，但如果資源洪峰已經(jīng)來臨時，再去擴就常常會發(fā)現(xiàn)來不及。一方面原因是Event Driven，洪峰來臨再去彈，另外一方面的原因是容器化的業(yè)務(wù)啟動速度趕不上流量來的速度。由于業(yè)務(wù)系統(tǒng)慢，導(dǎo)致很多業(yè)務(wù)沒辦法使用社區(qū)的HPA。

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

VPA工作原理和局限性

VPA工作原理如下。

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

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

在現(xiàn)實中，VPA的落地場景其實不多，因為VPA有其局限性：業(yè)務(wù)很難接受隨時重建的Pod。

例如一個業(yè)務(wù)正在接受一個用戶的數(shù)據(jù)處理，這時Pod重建了，用戶的業(yè)務(wù)使用就會受損， Pod 重建無法通知到業(yè)務(wù)，并且一定會對業(yè)務(wù)造成影響，導(dǎo)致很多時候在生產(chǎn)環(huán)境很難使用VPA。

基于Crane的Kubernetes的資源分析與優(yōu)化

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

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

Understand Fully Loaded Costs：多維度業(yè)務(wù)成本分?jǐn)偙怼?a target="_blank">標(biāo)簽管理、分期賬單、預(yù)算和配額管理等。

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

Benchmark Performance：趨勢和變化分析、評分和PKI、內(nèi)部評比、跨供應(yīng)商評分對比等。

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

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

云上資源的分析和優(yōu)化

下圖展示的是Kubernetes云上資源的分析和優(yōu)化的能力。

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

同時，輸入的一方面是云資源，另一方面是Kubernetes的觀測數(shù)據(jù)，例如Deployment對應(yīng)CPU的使用率，內(nèi)存的使用率，都是觀測數(shù)據(jù)。

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

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

云上資源的分析與優(yōu)化，還提供了一個插件系統(tǒng)。用戶可以自定義推薦的插件，使用推薦的framework插到分析的推薦系統(tǒng)中去，實現(xiàn)自定義分析和推薦的邏輯。

資源推薦

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

從“讓應(yīng)用的資源配置更簡單”的訴求出發(fā)。

Crane方案是根據(jù)應(yīng)用的歷史用量推薦，支持按照機型規(guī)格做調(diào)整，基于VPA的算法進(jìn)行資源推薦。很多業(yè)務(wù)都跑在Serverless構(gòu)上，Serverless架構(gòu)上的資源規(guī)格、機型規(guī)格都會做規(guī)整，例如1.5Core/3G的資源就會向上規(guī)整到2Core/4G上，Crane的推薦結(jié)果會根據(jù)規(guī)則做規(guī)整，同樣是基于VPA算法。

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

副本/彈性推薦

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

從“讓應(yīng)用副本配置更簡單”的訴求出發(fā)。

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

成效如上圖右側(cè)所示，大部分業(yè)務(wù)配了很多副本數(shù)，但經(jīng)過計算發(fā)現(xiàn)降到三個副本也可以滿足業(yè)務(wù)訴求。

內(nèi)部大規(guī)模落地實踐

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

騰訊把集群中資源推薦的建議展現(xiàn)到控制臺里，讓用戶看到工作負(fù)載、當(dāng)前的核數(shù)、推薦的資源量、推薦副本數(shù)。

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

智能彈性—Effective HPA

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

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

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

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

第三個能力：支持Cron配置。應(yīng)對大促、節(jié)假日等有規(guī)律的流量洪峰。

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

下圖展示的是Effective HPA的架構(gòu)。

用戶創(chuàng)建Effective HPA的對象后會生成兩個資源對象：

一個是TimeSeries Prediction；

另一個是社區(qū)原生的HPA。

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

社區(qū)HPA在創(chuàng)建后，HPA的Controller就會工作。定義中的metric的配置向Kubernetes的ApiServer請求。一方面，它會去向Metric server去請求它的CPU的用量。另一方面，它向Crane metric adapter去請求預(yù)測數(shù)據(jù)。

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

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

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

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

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

智能彈性落地成效

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

騰訊內(nèi)部的安全部門WAP和騰訊的容器服務(wù)，在生產(chǎn)環(huán)境已經(jīng)使用了Effective HPA做彈性伸縮器。作為一個開源產(chǎn)品，很多公司對Effective HPA感興趣，并且正在使用。

酷樂家生產(chǎn)環(huán)境全量使用?？針芳以驹谏a(chǎn)環(huán)境中已經(jīng)全量使用了HPA，由于沒有辦法提前擴容，導(dǎo)致它的配置相當(dāng)保守?？針芳铱吹紺ron的Effective HPA后，將HPA存量切換到了Effective HPA，在生產(chǎn)環(huán)境全量使用后，解決了彈性問題，提升了平均使用率。

目前Effective HPA在生產(chǎn)環(huán)境已經(jīng)管控了數(shù)千個應(yīng)用。

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

審核編輯 ：李倩