Kubernetes降本增效標(biāo)準(zhǔn)指南 | 基于K8s擴(kuò)展機(jī)制構(gòu)建云上成本控制系統(tǒng)

導(dǎo)語

Kubernetes作為IaaS和PaaS中間的一層，通過聲明式API/控制器模式、以應(yīng)用服務(wù)為中心、并且從API到運(yùn)行時(shí)都提供了高度靈活的可擴(kuò)展機(jī)制，為云廠商、各企業(yè)構(gòu)建應(yīng)用托管服務(wù)甚至云原生服務(wù)提供了統(tǒng)一的標(biāo)準(zhǔn)和基礎(chǔ)設(shè)施管理的各項(xiàng)能力。

隨著企業(yè)上云進(jìn)入穩(wěn)定期，成本控制就是永遠(yuǎn)逃不開的話題。本文通過Kubernetes的擴(kuò)展機(jī)制Admission Webhook、Scheduler Framework和CRD+Operator，結(jié)合云上資源的特異性，介紹如何基于Kubernetes和云上環(huán)境構(gòu)建成本控制系統(tǒng)。

TKE的頭部客戶S（離線計(jì)算場景），面對增長的客戶月活以及相應(yīng)劇增的計(jì)算需求，強(qiáng)烈希望騰訊云容器服務(wù)能提供更低單價(jià)的算力和更彈性的架構(gòu)。S通過構(gòu)建合適的成本控制系統(tǒng)，將月賬單降低了接近80%（業(yè)務(wù)計(jì)算量相同）。結(jié)合S的業(yè)務(wù)場景，我們主要建議S做了如下低成本改造動(dòng)作：

·通過Spot Controller配置了較高的競價(jià)實(shí)例比例（接近90%），同時(shí)配置了10%左右的包年包月實(shí)例作為穩(wěn)定資源的buffer池。由于Spot比例設(shè)置較高，為了增強(qiáng)資源供應(yīng)的穩(wěn)定性，S配置了多種備選機(jī)型來擴(kuò)大資源池的供應(yīng)范圍，保持回收頻率在極低水平。

·為了進(jìn)一步保障業(yè)務(wù)的高可用，S設(shè)置了多可用區(qū)平衡分布的擴(kuò)容策略，來保障實(shí)例在多可用區(qū)打散分布。

·為了保證彈性以及架構(gòu)的容錯(cuò)性，S同時(shí)使用了業(yè)務(wù)彈性伸縮(HPA)+資源彈性伸縮(節(jié)點(diǎn)池）來完成應(yīng)用層彈性伸縮到資源層的彈性伸縮平滑過渡，同時(shí)也可以在業(yè)務(wù)低谷時(shí)自動(dòng)釋放閑置資源，進(jìn)一步節(jié)成本。

·為了應(yīng)對極端情況下的回收情況，S安裝了Spot Agent來保障業(yè)務(wù)的優(yōu)雅終止以及計(jì)算過程的斷點(diǎn)續(xù)傳。

WHY SPOT?我們需要一種云原生的低成本算力

TKE能力的底座是集群以及節(jié)點(diǎn)能力（底層依賴騰訊云的CVM實(shí)現(xiàn)），而TKE本身是不計(jì)費(fèi)的，那么您購買節(jié)點(diǎn)時(shí)選擇的計(jì)費(fèi)方式將極大程度上決定您的總體使用成本。

根據(jù)不同的使用場景，用戶最常使用的計(jì)費(fèi)方式為按量計(jì)費(fèi)或者包年包月：

·按量計(jì)費(fèi)是一種符合云計(jì)算理念的計(jì)費(fèi)方式——按需使用，彈性供應(yīng)，秒級計(jì)費(fèi)。按量計(jì)費(fèi)的這種按需使用的特性，和云上的彈性伸縮能力天然適配，很多用戶也會(huì)搭配使用。

·包年包月是一種更低成本的計(jì)費(fèi)方式——提前付費(fèi)，降低成本您在十分明確使用期限的情況下，可以以低折扣按月、按年、按周的方式購買實(shí)例。

那么，有沒有一種計(jì)費(fèi)類型，既具備云原生按量計(jì)費(fèi)的特性、能夠匹配彈性伸縮能力，又能夠像包年包月實(shí)例一樣提供較低折扣呢？競價(jià)實(shí)例，就是這個(gè)問題的答案。

競價(jià)實(shí)例（Spot）是云服務(wù)器CVM的一種新實(shí)例運(yùn)作模式，它最核心的特點(diǎn)是折扣售賣和系統(tǒng)中斷機(jī)制。

競價(jià)實(shí)例是三種計(jì)費(fèi)模式中成本最低的一種使用方式（低至兩折),可以極大程度降低您的云資源支出。

但正如它的名字一樣，您和其他同時(shí)使用競價(jià)實(shí)例的用戶存在一定的競爭關(guān)系：在特定場景下，實(shí)例可能會(huì)被回收，我們官方將這種回收定義為系統(tǒng)主動(dòng)中斷（庫存波動(dòng)）：當(dāng)前階段，在騰訊云的競價(jià)實(shí)例模型下，僅會(huì)因?yàn)楦們r(jià)實(shí)例資源池庫存不足而產(chǎn)生中斷。資源管控系統(tǒng)會(huì)自動(dòng)根據(jù)實(shí)時(shí)庫存變化回收這些折扣售賣的實(shí)例。當(dāng)您成功購買一個(gè)競價(jià)實(shí)例后，它的使用和按量計(jì)費(fèi)的CVM實(shí)例基本毫無區(qū)別，包括控制臺操作、遠(yuǎn)程登錄、服務(wù)部署、關(guān)聯(lián)VPC等。

在豐富的實(shí)踐與探索中，我們發(fā)現(xiàn)，Spot非常適合容器、無狀態(tài)服務(wù)、CI/CD、強(qiáng)化學(xué)習(xí)、離線轉(zhuǎn)碼、大數(shù)據(jù)分析等具有容錯(cuò)能力的業(yè)務(wù)應(yīng)用，尤其是基于云原生框架構(gòu)建的應(yīng)用，在這些場景下可以在巨幅降低成本(80%以上)的前提下，保證業(yè)務(wù)的穩(wěn)定性。

不懼中斷—云原生框架保證業(yè)務(wù)穩(wěn)定性

上面我們已經(jīng)介紹了競價(jià)實(shí)例的核心特性，可能您看到系統(tǒng)主動(dòng)中斷這個(gè)概念，心里會(huì)浮現(xiàn)一些顧慮以及疑惑：

Q1:回收機(jī)制是怎么樣的？會(huì)提前通知嗎？

Q2:我想要節(jié)約成本，我可以做些什么來降低甚至消除回收帶來的潛在風(fēng)險(xiǎn)嗎？

Q3:是否有自動(dòng)化的方式可以抵消回收帶來的對業(yè)務(wù)的潛在影響？

Q4:怎么判斷我的業(yè)務(wù)是否適合使用競價(jià)實(shí)例？

這幾個(gè)問題，本文都會(huì)一一解答。我們依托于豐富的實(shí)戰(zhàn)經(jīng)驗(yàn)，基于Kubenetes構(gòu)建了云上成本控制系統(tǒng)，利用彈性供應(yīng)能力以及云原生的維持業(yè)務(wù)期望狀態(tài)的能力，定義且實(shí)現(xiàn)了一種低成本且穩(wěn)定的算力交付形式。

·競價(jià)實(shí)例在被系統(tǒng)回收前的2-5分鐘（不同云服務(wù)商配置的時(shí)間不一致），都會(huì)發(fā)出回收信號、或者以虛擬機(jī)元數(shù)據(jù)信息的方式體現(xiàn)出來，TKE基于云原生的優(yōu)雅終止以及Workload Controller維持應(yīng)用期望狀態(tài)的特性，有效降低了回收的風(fēng)險(xiǎn)，在感知回收信號后，可以優(yōu)雅終止競價(jià)實(shí)例上運(yùn)行的應(yīng)用副本，同時(shí)自動(dòng)創(chuàng)建新的副本來滿足業(yè)務(wù)期望狀態(tài)。

·TKE將維持期望狀態(tài)的能力從應(yīng)用層擴(kuò)展到了資源層，用戶無需關(guān)心資源購買過程，只需定義期望資源的狀態(tài)（規(guī)格、可用區(qū)、計(jì)費(fèi)類型）等，spot-controller會(huì)自動(dòng)供應(yīng)資源直至滿足客戶期望。

成本控制系統(tǒng)概述

上圖是整個(gè)成本控制系統(tǒng)的架構(gòu)圖。

在介紹系統(tǒng)各組件前，先提一下位于架構(gòu)圖最下面的資源池這一層，其中最主要的一種資源是競價(jià)實(shí)例(Spot)，各個(gè)主流云廠商都有提供，所謂競價(jià)實(shí)例（Spot）。

競價(jià)實(shí)例是用戶可以直接購買的，而碎片資源，則是指一些長期閑置的資源碎片，由于規(guī)格原因一直未被申請到，這些資源往往需要具有IaaS層操作權(quán)限，所以比較適合云廠商來使用，作為普通用戶，使用競價(jià)實(shí)例池即可。

整個(gè)系統(tǒng)由三部分組成，tke-spot-agent、cost-wehbhook+cost-scheduler，以及spot controller，這三部分是完全松耦合的，比如部分業(yè)務(wù)在前期只使用了tke-spot-agent.

·the-spot-agent以deamonset的方式運(yùn)行在每臺Node節(jié)點(diǎn)，用于監(jiān)聽競價(jià)實(shí)例的回收信號，從而實(shí)將節(jié)點(diǎn)Disable以禁止調(diào)度新的POD，優(yōu)雅驅(qū)逐POD等。

·cost-webhook+cost-scheduler是中心化的，每個(gè)集群只需部署一套，用于攔截用戶請求，將用戶請求通過自定義調(diào)度器調(diào)度，滿足指定比例的Pod被調(diào)度到競價(jià)實(shí)例。

·spot-controller也是中心化的，每個(gè)集群一套，用于處理用戶配置的CRD資源，調(diào)用云廠商提供的購買機(jī)器的云API進(jìn)行機(jī)型的購買，用戶得以按照一個(gè)簡單的描述文件聲明集群所需競價(jià)實(shí)例的配比，從而控制成本。

通過以上三個(gè)組件，分別實(shí)現(xiàn)了競價(jià)實(shí)例被回收前的優(yōu)雅處理、用戶對不同業(yè)務(wù)場景下將Pod按比例調(diào)度到競價(jià)實(shí)例上的成本感知調(diào)度、對用戶的成本聲明進(jìn)行協(xié)調(diào)控制。

tke-spot-agent-業(yè)務(wù)的優(yōu)雅終止以及平滑遷移

上文提到，競價(jià)實(shí)例在被系統(tǒng)回收前的2-5分鐘（不同云服務(wù)商配置的時(shí)間不一致），都會(huì)發(fā)出回收信號、或者以虛擬機(jī)元數(shù)據(jù)信息的方式體現(xiàn)出來，針對這個(gè)云廠商普遍存在的友好預(yù)警機(jī)制，我們可以提供一種守護(hù)服務(wù)，時(shí)刻監(jiān)聽這個(gè)來自IaaS層的預(yù)警信息，提前做一些處理，將業(yè)務(wù)應(yīng)用容器無損的遷移到其他虛擬機(jī)上。

從架構(gòu)上來講，這種守護(hù)服務(wù)，最優(yōu)的方式是以中心化的形式運(yùn)行在集群中，也就是一個(gè)Kubernetes集群只需運(yùn)行一個(gè)這樣的Pod，最多通過選舉機(jī)制啟動(dòng)一個(gè)standby容器做高可用，然而這樣的前提是，IaaS層的預(yù)警機(jī)制能夠以統(tǒng)一的消息發(fā)送過來，目前各大云廠商也只有極少數(shù)提供了這樣的發(fā)生消息的機(jī)制，只是在虛擬機(jī)元數(shù)據(jù)信息中做了體現(xiàn)，而且該信息只能在虛擬機(jī)的節(jié)點(diǎn)上查詢，考慮到當(dāng)前階段的普遍適用性，我們目前將該服務(wù)以Kubernetes daemonsets的方式部署在每一臺spot機(jī)型上。

云廠商虛擬機(jī)的元數(shù)據(jù)信息，可以在虛擬機(jī)上以HTTP的方式獲取，該守護(hù)服務(wù)啟動(dòng)后，不斷的監(jiān)聽該spot虛擬機(jī)的元數(shù)據(jù)信息，當(dāng)發(fā)現(xiàn)回收信息后，首先調(diào)用Kubernetes API將該虛擬機(jī)的調(diào)度狀態(tài)設(shè)置為不可調(diào)度，防止新的Pod被調(diào)度到這臺即將被回收的虛擬機(jī)上。緊接著，守護(hù)服務(wù)通過Kubernetes API獲取到當(dāng)前節(jié)點(diǎn)上所有的Pod，對這些Pod發(fā)起驅(qū)逐命令，Kubernetes為每個(gè)Pod配置了默認(rèn)優(yōu)雅退出時(shí)間，這個(gè)值是30s，有些業(yè)務(wù)應(yīng)用的場景可能在30秒內(nèi)難以處理完手頭的事情，守護(hù)服務(wù)在向Kubernetes API server發(fā)起請求時(shí)，可以攜帶一個(gè)叫做DeleteOptions的Kubernetes資源屬性，可以將優(yōu)雅退出的時(shí)間進(jìn)行用戶自定義，當(dāng)然，這個(gè)時(shí)間，設(shè)置為大于IaaS層對Spot虛擬機(jī)回收時(shí)間（2-5分鐘）就沒有意義了，Pod還沒有優(yōu)雅退出，虛擬機(jī)可能就已經(jīng)被回收了。

這里需要額外提到的是，業(yè)務(wù)應(yīng)用如何感知到spot實(shí)例即將被回收呢？這就要從Kubernetes的設(shè)計(jì)說起，Kubelet在真正刪除Pod之前，會(huì)在Pod上設(shè)置一個(gè)刪除標(biāo)記的起始時(shí)間，表示這個(gè)時(shí)刻收到了刪除該P(yáng)od的請求，并會(huì)給Pod的容器進(jìn)程發(fā)送一個(gè)SIGTerm信號，告訴業(yè)務(wù)進(jìn)程該P(yáng)od即將被刪除，而業(yè)務(wù)進(jìn)程要做的，就是實(shí)現(xiàn)一行代碼，去監(jiān)聽這個(gè)信號，這也算是云原生應(yīng)用的基本要求了，對于云原生應(yīng)用而言，云資源是不穩(wěn)定的。

cost webhook+cost scheduler-靈活的業(yè)務(wù)調(diào)度形式

cost webhook和cost scheduler兩個(gè)組件，本質(zhì)上是為了實(shí)現(xiàn)成本感知調(diào)度，也就是將指定比例的Pod調(diào)度到spot虛擬機(jī)上，指定比例的Pod調(diào)度到按量付費(fèi)包年包月的虛擬機(jī)上，達(dá)到既節(jié)約成本，又能平衡可用性。

從實(shí)現(xiàn)角度來說，最簡單的方式就是CRD+operator模式，用戶使用時(shí)聲明總共的副本數(shù)和spot實(shí)例的副本數(shù)，operator即可按照用戶的期望將固定比例Pod的node selector選擇為spot虛擬機(jī)。

然而，Kubernetes及其聲明式API模式的原則之一是，“犧牲小我，完成大你”，也就是說將復(fù)雜的事情全部由Kubernetes來做，用戶只需簡單的聲明即可。本著這樣的原則再來思考，這種CRD+operator的模式雖然簡單易行，但是對于用戶而言，就不那么友好了，用戶是平臺開發(fā)者甚至是應(yīng)用開發(fā)者，學(xué)習(xí)并掌握了Kubenretes的副本編排控制器如Deployment、Statefulsets等的使用配置參數(shù)，已經(jīng)擼起袖子開始使用了，突然告訴用戶一種新的配置，對于PaaS平臺開發(fā)者或者應(yīng)用開發(fā)者，都是不那么友好的。因此，思考一種對用戶更優(yōu)雅的實(shí)現(xiàn)，還是很有必要的。

cost webhook和cost scheduler正是基于Kubernetes原生的Deployment而設(shè)計(jì)，在使用時(shí)，用戶只需要將Deployment打上熟悉的annotation，如pod-on-spot-instance=70%，cost webhook和cost scheduler即可完成將70%的Pod調(diào)度到spot實(shí)例，將30%的Pod調(diào)度到按量付費(fèi)包年包月實(shí)例上。

How Cost webhook works

具體來說，cost webhook是基于Kubernetes提供的動(dòng)態(tài)準(zhǔn)入控制機(jī)制實(shí)現(xiàn)的一個(gè)webhook，用戶請求到達(dá)API Server后，以此經(jīng)過路由、認(rèn)證、審計(jì)、鑒權(quán)等流程，而審計(jì)包括Mutating和Validating兩個(gè)階段，前者用于對API資源繼續(xù)修改，后者主要用于校驗(yàn)，如下圖。

（圖片來源：https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/）

cost webhook正是Mulating階段的webhook，在流程走到Mutating階段被調(diào)用執(zhí)行，cost webhook監(jiān)聽Deployment這種資源類型，判斷annotation中是否包含上述提到的pod-on-spot-instance=70%信息，如果有，則將該Deployment所屬的Pod的Scheduler Name修改為cost scheduler，對于這些Pod的調(diào)度，就交給cost scheduler來完成。

How Cost Scheduler works

cost scheduker也是基于Kubernetes的scheduker framework擴(kuò)展機(jī)制實(shí)現(xiàn)的自定義調(diào)度器。

（圖片來源：https://kubernetes.io/docs/concepts/scheduling-eviction/scheduling-framework/）

如上圖所示，Schedule Framework為我們提供了多個(gè)擴(kuò)展點(diǎn)，比如preFilter、Filter、Score等等，可以在調(diào)度的各個(gè)環(huán)節(jié)實(shí)現(xiàn)自定義擴(kuò)展。

cost scheduler主要基于Filter進(jìn)行擴(kuò)展，將Pod分為適合調(diào)度到spot實(shí)例和適合調(diào)度到非spot實(shí)例。

spot-controller-持續(xù)穩(wěn)定的算力交付

看到這里，可能您還有個(gè)疑問還沒有得到解答：是否有自動(dòng)化的方式可以抵消回收帶來的對業(yè)務(wù)的潛在影響？Spot-controller可以回答這個(gè)問題，它定義了一種算力交付的方式，將維持期望狀態(tài)的能力從應(yīng)用層擴(kuò)展到了資源層。

用戶無需關(guān)心資源購買過程，只需定義期望資源的狀態(tài)（規(guī)格、可用區(qū)、計(jì)費(fèi)類型）等，spot-controller會(huì)自動(dòng)供應(yīng)資源直至滿足客戶期望。

spot-controller在實(shí)現(xiàn)上采用了CRD+operator的模式，用戶只需填寫一份CR并提交到Kubernetes集群，spot-controller則監(jiān)聽該CR，負(fù)責(zé)集群node資源的新增和刪除，當(dāng)然，這需要擁有IaaS層虛擬機(jī)的創(chuàng)建和刪除權(quán)限。

從功能模塊來看，Spot-Controller的功能模塊分為以下幾個(gè)部分：

·混合算力供應(yīng)——抵消競價(jià)實(shí)例可能回收/庫存不足帶來的算力不足的風(fēng)險(xiǎn)

用戶可指定部分按量算力作為競價(jià)實(shí)例的算力補(bǔ)充，即穩(wěn)定的算力buffer

用戶可指定多種機(jī)型規(guī)格，降低某種機(jī)型售罄的潛在風(fēng)險(xiǎn)

用戶可指定多可用區(qū)，作用和配置多機(jī)型規(guī)格類似

·靈活的供應(yīng)策略——滿足不同的本質(zhì)需求

多可用區(qū)打散策略（在您配置的多可用區(qū)內(nèi)平均供應(yīng)算力，達(dá)到高可用）

容量高可用策略（優(yōu)先擴(kuò)容資源庫存最高的實(shí)例規(guī)格，達(dá)到高可用）

成本優(yōu)化策略（優(yōu)先擴(kuò)容成本最低的實(shí)例規(guī)格，具有最優(yōu)的成本優(yōu)化效果）

·釋放閑置資源——極致的彈性伸縮

結(jié)合TKE提供的全套彈性伸縮解決方案:HPA/VPA+Cluster Autoscaler,自動(dòng)釋放閑置資源，即可利用彈性能力進(jìn)一步助力成本縮減。

使用成本控制系統(tǒng)的最佳實(shí)踐

文章最后，通過沉淀我們在服務(wù)不同行業(yè)場景客戶的實(shí)戰(zhàn)經(jīng)驗(yàn)，我們給出了一些使用本系統(tǒng)以及競價(jià)實(shí)例的最佳實(shí)踐。從業(yè)務(wù)場景來看，如果您的業(yè)務(wù)是無狀態(tài)業(yè)務(wù)，比如可橫向伸縮的Web站點(diǎn)服務(wù)、圖像渲染、大數(shù)據(jù)分析、并行計(jì)算、強(qiáng)化學(xué)習(xí)、AI等，都非常適合使用這套成本控制系統(tǒng)。此外，我們有一些Tips供您參考，以獲得更佳的使用體驗(yàn)：

大數(shù)據(jù)/強(qiáng)化學(xué)習(xí)場景-切分任務(wù)粒度

·長時(shí)間作業(yè)拆成細(xì)粒度的作業(yè)，減少被中斷可能性（結(jié)合容器場景下的Workload能力）

·強(qiáng)化學(xué)習(xí)場景

在線業(yè)務(wù)場景-通過負(fù)載均衡在保證服務(wù)的穩(wěn)定性

·利用Kubernetes原生的Service能力，配合負(fù)載均衡，保障業(yè)務(wù)的高可用。

·通過合理配置Spot-controller中的不同資源配比，保證負(fù)載均衡后端資源的穩(wěn)定供應(yīng)。

·通過tke-spot-agent監(jiān)聽競價(jià)實(shí)例中斷情況，優(yōu)雅終止并遷移業(yè)務(wù)副本。

離線計(jì)算場景-支持?jǐn)帱c(diǎn)續(xù)算的計(jì)算調(diào)度模式

·將計(jì)算中間結(jié)果放到COS/CFS/NAS等持久存儲(chǔ)產(chǎn)品上。

·通過tke-spot-agent監(jiān)聽競價(jià)實(shí)例中斷情況，在應(yīng)用(Pod)中定義優(yōu)雅退出鉤子，保存中間計(jì)算結(jié)果。

·定義應(yīng)用(Pod)中定義啟動(dòng)鉤子，當(dāng)新業(yè)務(wù)副本成功啟動(dòng)后自動(dòng)從持久存儲(chǔ)中拉取中間結(jié)果，繼續(xù)計(jì)算。

在騰訊云容器服務(wù)使用競價(jià)實(shí)例

當(dāng)前TKE已經(jīng)通過節(jié)點(diǎn)池集成了競價(jià)實(shí)例，您可以直接通過TKE直接創(chuàng)建競價(jià)實(shí)例節(jié)點(diǎn)池。詳細(xì)可查看創(chuàng)建節(jié)點(diǎn)池[1]。并且可以通過TKE應(yīng)用市場部署上述Spot Agent應(yīng)用助力業(yè)務(wù)優(yōu)雅終止和平滑遷移。同時(shí)彈性容器服務(wù)EKS即將推出競價(jià)類型Pod，屆時(shí)您也可以通過彈性容器服務(wù)使用更低成本的計(jì)算資源。

總結(jié)

多數(shù)企業(yè)上云核心目的之一就是降低成本，且容器化讓成本具備了非常大的優(yōu)化空間，而真正降低成本需要深度利用云和容器化的彈性能力，并且容器能夠讓彈性和穩(wěn)定性得到了權(quán)衡。騰訊云容器團(tuán)隊(duì)將陸續(xù)提供上述成本控制系統(tǒng)套件，如您有任何建議或訴求歡迎通過小助手與我們聯(lián)系。

參考資料

[1]創(chuàng)建節(jié)點(diǎn)池:（https://cloud.tencent.com/document/product/457/43735）