Kubernetes云上資源管理

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

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

Kubernetes云上資源管理

Kubernetes資源模型：Request和Limit

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

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

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

資源預(yù)留帶來(lái)的資源浪費(fèi)

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

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

資源緊缺帶來(lái)的資源浪費(fèi)

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

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

如上圖所示，Kubernetes中的節(jié)點(diǎn)上部署了兩個(gè)容器，它們?cè)谔幚順I(yè)務(wù)都有規(guī)律：

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

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

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

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

如果節(jié)點(diǎn)的內(nèi)存耗盡，Kubernetes會(huì)按順序驅(qū)逐容器，排序規(guī)則是容器實(shí)際內(nèi)存使用超出Request的用量。如果去驅(qū)逐用量大于Request的東西，業(yè)務(wù)就會(huì)發(fā)生損傷，因?yàn)樗娜萜鞅籏ill，并且這時(shí)候往往是處在于業(yè)務(wù)的高峰期，使業(yè)務(wù)受到損傷。

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

大量資源無(wú)法使用導(dǎo)致資源浪費(fèi)

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

Kubernetes彈性伸縮HPA工作原理

HPA工作原理如下圖所示。

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

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

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

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

HPA原生能力不足

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

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

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

VPA工作原理和局限性

VPA工作原理如下。

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

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

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

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

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

Crane是騰訊的一個(gè)基于Kubernetes的開(kāi)源項(xiàng)目，全稱是Cloud Resource Analytics and Economics，譯為“云上資源的分析和降本”。

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

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

Enable Real Time Decision Making：資源利用率報(bào)表、異常識(shí)別、識(shí)別資源浪費(fèi)等。

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

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

Optimize Rate：提供計(jì)費(fèi)方面的能力，比如計(jì)費(fèi)方式推薦、抵用券支持等。

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

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

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

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

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

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

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

資源推薦

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

從“讓?xiě)?yīng)用的資源配置更簡(jiǎn)單”的訴求出發(fā)。

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

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

副本/彈性推薦

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

從“讓?xiě)?yīng)用副本配置更簡(jiǎn)單”的訴求出發(fā)。

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

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

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

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

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

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

智能彈性—Effective HPA

HPA落地有兩個(gè)問(wèn)題：彈性時(shí)間滯后、彈性毛刺。

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

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

第二個(gè)能力：減少無(wú)效縮容。能夠預(yù)測(cè)未來(lái)的一個(gè)資源用量，當(dāng)曲線發(fā)生抖動(dòng)時(shí)，因?yàn)槿〉念A(yù)測(cè)窗口中的最大值，所以整個(gè)曲線的抖動(dòng)毛刺程度明顯降低。

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

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

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

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

一個(gè)是TimeSeries Prediction；

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

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

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

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

CronHPA 、KEDA、Effective HPA有什么差異點(diǎn)呢？如下圖所示。

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

KEDA實(shí)現(xiàn)原理是為每一個(gè)框配置生成metric。但它的問(wèn)題是在Cron的周期之外，KEDA的Cron配置會(huì)自動(dòng)把用戶的應(yīng)用縮容到一個(gè)副本，原因是它把每一個(gè)Cron都定義成了metric。由于metric定義互相不感知，就導(dǎo)致metric返回的默認(rèn)值只能設(shè)置為1，因?yàn)樗荒軌蛉ビ绊憚e的metric配置。

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

智能彈性落地成效

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

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

酷樂(lè)家生產(chǎn)環(huán)境全量使用?？針?lè)家原本在生產(chǎn)環(huán)境中已經(jīng)全量使用了HPA，由于沒(méi)有辦法提前擴(kuò)容，導(dǎo)致它的配置相當(dāng)保守。酷樂(lè)家看到Cron的Effective HPA后，將HPA存量切換到了Effective HPA，在生產(chǎn)環(huán)境全量使用后，解決了彈性問(wèn)題，提升了平均使用率。

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

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

審核編輯 ：李倩