騰訊云：騰訊會議大規(guī)模使用Kubernetes的技術(shù)實踐

騰訊會議，一款提供靈活協(xié)作的線上會議解決方案。其中大量的模塊是有狀態(tài)服務(wù)，在使用Kubernetes為其進行容器化部署時，Pod升級需保持共享內(nèi)存、長連接服務(wù)。升級時只容忍ms級抖動，需提供大規(guī)模分批灰度發(fā)布、業(yè)務(wù)配額控制等能力，并同時解決集群節(jié)點負載不均衡、上萬Pods的Workload的HPA性能差等問題。這里將向大家介紹TKEx容器平臺及其在灰度發(fā)布、資源管理、彈性伸縮等方面的能力。

海量規(guī)模下Kubernetes面臨的挑戰(zhàn)

在騰訊自研業(yè)務(wù)中，已經(jīng)有幾百萬核跑在Kubernetes上，要在如此體量的容器場景提供可靠穩(wěn)定的容器服務(wù)，無論在底層、集群能力、運營或運維等各個方面都面臨巨大挑戰(zhàn)。

1.我們怎么進行容器可靠高性能的灰度發(fā)布?尤其是在自研業(yè)務(wù)里面，大量的服務(wù)是有狀態(tài)的服務(wù),原生的Kubernetes StatefulSet已經(jīng)無法滿足我們?nèi)绱舜笠?guī)模的容器發(fā)布需求。

2.調(diào)度層面需要做哪些優(yōu)化，從而保證在Pod漂移和重調(diào)度的過程中保證業(yè)務(wù)的穩(wěn)定性。

3.在優(yōu)化資源編排性能方面，如何在整個平臺層面和業(yè)務(wù)層面做好后臺管理。

4.在大規(guī)模的彈性伸縮方面如何提供高性能和全面的彈性伸縮能力。

TKEx容器平臺簡介

TKEx容器平臺的底層基于騰訊公有云的TKE和EKS兩個產(chǎn)品，它是使用Kubernetes原生的技術(shù)手段服務(wù)于騰訊內(nèi)部的業(yè)務(wù),包括騰訊會議、騰訊課堂、QQ及騰訊看點等。TKEx在灰度發(fā)布、服務(wù)路由、彈性伸縮、容器調(diào)度、資源管理、多集群管理、業(yè)務(wù)容災(zāi)、在離線混部等方面做了大量工作，比如：

1.通過Kubernetes API/Contoller/Operator的原生方式適配騰訊內(nèi)部各種系統(tǒng)，比如服務(wù)路由系統(tǒng)、CMDB、CI、安全平臺等。

2.通過聲明式的方式，對所有的托管業(yè)務(wù)進行生命周期管理。

3.支持在線業(yè)務(wù)、大數(shù)據(jù)、AI等類型作業(yè)。

4.實現(xiàn)在線業(yè)務(wù)和離線業(yè)務(wù)的混合部署，同時提升整個資源的利用率。

5.通過優(yōu)化linux的內(nèi)核，增強資源底層隔離能力。

6.集成Tencent Cloud Mesh(TCM)服務(wù)為自研業(yè)務(wù)提供ServiceMesh服務(wù)。

7.在大規(guī)模的集群里面，對彈性伸縮的各種組件進行改造和優(yōu)化，以保證它的性能和可用性。

8.基于業(yè)務(wù)產(chǎn)品維度，提供多租戶和配額管理能力。

下面是TKEx平臺縮略版的架構(gòu)圖，僅包括本次討論的相關(guān)能力。

1.底層基于TKE和EKS兩個產(chǎn)品，在上層服務(wù)于在線業(yè)務(wù)、AI訓(xùn)練以及大數(shù)據(jù)作業(yè)。

2.中間這四個框主要包括在應(yīng)用和路由管理、資源編排調(diào)度、彈性伸縮、混部。下面會重點介紹其中前三個部分。

高效穩(wěn)定的發(fā)布能力

業(yè)務(wù)沒有大規(guī)模使用StatefulSet的滾動更新能力，對于有狀態(tài)服務(wù)來說，原生的滾動更新機制的發(fā)布可控性太差，對于multi-zone容災(zāi)部署的業(yè)務(wù)更是很難做精細化的發(fā)布策略。我們提供了分批灰度發(fā)布策略供有狀態(tài)服務(wù)使用，約80%的Workload都選擇了這種策略。

以一個業(yè)務(wù)分兩批進行發(fā)布為例，第一批升級兩個Pod，用戶可以指定是哪兩個Pod，也可以按照一定比例指定第一批是10%，由平臺自動選擇10%的Pod進行灰度，剩余Pods在第二批進行灰度。

·自動分批機制：如果Pod的探針完善且能真實反映業(yè)務(wù)是否可用，用戶可以使用自動分批機制，上一批次完成后可通過自定義的批次時間間隔和健康檢查機制自動進行下一批的灰度發(fā)布或者自動回滾。

·手動分批機制：用戶也可以通過手動分批機制，在上一批次灰度完成后，可人為在業(yè)務(wù)層面確認上一批的灰度是否成功，來決定是否觸發(fā)下一批灰度還是回滾。

分批灰度發(fā)布更安全、更可靠、更可控的特性，整個發(fā)布過程更靈活。由于單個批次內(nèi)所有選中Pods的更新都是并發(fā)的，因此可以應(yīng)付緊急快速發(fā)布的需求。

StatefulSetPlus是我們用來實現(xiàn)分批灰度發(fā)布的CRD，它繼承了Kubernetes原生的StatefulSet的所有能力，并在此之上新增和優(yōu)化了大量特性。StatefulSetPlus主要提供的核心特性包括自動的以及手動的分批灰度發(fā)布，在發(fā)布異常時可以進行全量一次回滾或者分批次的回滾。Pod更新的策略支持兩種形式，一種是Pod重建的方式，另一種是Pod的原地升級方式。同時我們還提供了一些高級特性，比如：

1.支持Pod升級過程中保持Pod使用的共享內(nèi)存數(shù)據(jù)不丟失，這個特性非常適合于像騰訊會議這樣的音視頻業(yè)務(wù)。

2.如果升級過程中觸發(fā)了Workload的擴容，那么擴容的時候會使用上一個好的版本進行擴容，而不是像原生的StatefulSet和Deployment一樣，使用最新的鏡像進行擴容。因為最新的鏡像版本有可能是不可用的，擴容出來的Pod可服務(wù)型存在風險。

3.在存儲編排方面，我們繼承了StatefulSet的Per Pod Per PV的特性，同時也支持Per Workload Per PV的特性，即單個StatefulSetPlus下面所有的Pod共享一個PV，也就是類似Deployment共享PV的模式。

4.在StatefulSet里面，當節(jié)點出現(xiàn)異常，比如出現(xiàn)了NodeLost的情況下，出于有狀態(tài)服務(wù)的可用性考慮，不會進行Pod重建。在StatefulSetPlus中，監(jiān)聽到NodeLost后，對應(yīng)的Pod會自動漂移。這還不夠，我們會通過NPD檢測，上報事件或Patch Condition快速發(fā)現(xiàn)節(jié)點異常，對StatefulSetPlus Pod進行原地重建或者漂移等決策。

5.StatefulSetPlus還有一個非常重要的特性，就是它支持ConfigMap的版本管理以及ConfigMap的分批灰度發(fā)布，這是決定ConfigMap能否大規(guī)模在生產(chǎn)中使用的關(guān)鍵能力。

這里特別介紹一下，如何支持Pod升級過程中保持共享內(nèi)存數(shù)據(jù)不丟失，并且在升級過程中，單個Pod只有毫秒級的服務(wù)抖動。主要的實現(xiàn)原理就是在Pod里面，通過一個占位容器和業(yè)務(wù)容器進行文件鎖的搶占動作，來實現(xiàn)升級過程中兩個容器的角色進行快速切換。

動態(tài)的資源調(diào)度和管理

kubernetes的調(diào)度原生是使用靜態(tài)調(diào)度的方式，在生產(chǎn)環(huán)境會出現(xiàn)集群里面各個節(jié)點的負載不均衡的情況，并且造成很大的資源浪費。

動態(tài)調(diào)度器是我們自研的一個調(diào)度器擴展器，主要任務(wù)是平衡集群中各個節(jié)點真實的負載，在調(diào)度的時候，將各個節(jié)點的真實負載納入考量的范疇。

動態(tài)調(diào)度器必須要解決的一個技術(shù)點是調(diào)度熱點的問題。當集群中有一批節(jié)點負載比較低，這時用戶創(chuàng)建大量的Pod，這些Pod會集中調(diào)度到這些低負載的節(jié)點上面，這將導(dǎo)致這些低負載節(jié)點在幾分鐘之后又會成為高負載節(jié)點，從而影響這批節(jié)點上Pod的服務(wù)質(zhì)量，這種現(xiàn)象尤其在集群擴容后很容易出現(xiàn)。我們自研的調(diào)度熱點規(guī)避算法，極大的避免了某個節(jié)點因為低負載被動態(tài)調(diào)度器調(diào)度后成為延遲性的高負載熱點，極少數(shù)高負載節(jié)點在de-scheduler中會基于Node CPU的歷史監(jiān)控進行節(jié)點降熱操作。

我們希望能夠快速地感知集群的異常情況，包括kubelet異常、docker異常、內(nèi)核死鎖以及節(jié)點是否出現(xiàn)文件描述符即將耗盡的情況，從而能在第一時間去做決策，避免問題的惡化。其中快速發(fā)現(xiàn)這個動作是由Node Problem Detector（NPD）組件負責的，NPD組件是基于社區(qū)的NPD進行了大量的策略擴展。

NPD檢測到異常后，除了NPD組件本身對節(jié)點自愈的動作之外，de-scheduler還會基于異常事件和當前集群/Workload現(xiàn)狀協(xié)助進行動作決策，比如Pod驅(qū)逐、Container原地重啟。這里要重點提一下，我們基于Self算法的分布式的Ping檢測，能夠快速發(fā)現(xiàn)節(jié)點的網(wǎng)絡(luò)異常情況，由de-scheduler對網(wǎng)絡(luò)異常節(jié)點上的Pods進行漂移。

在騰訊內(nèi)部，產(chǎn)品的管理是分多個層級的，因此在配額管理方面，我們沒有使用Kubernetes原生的ResourceQuota機制，而是研發(fā)了DynamicQuota CRD來實現(xiàn)多層級的、動態(tài)的面向業(yè)務(wù)的Quota管理。

比如從業(yè)務(wù)維度，騰訊會議是一個產(chǎn)品，騰訊課堂是一個產(chǎn)品，每個產(chǎn)品下面都會有多級業(yè)務(wù)模塊，在做資源規(guī)劃和配額管理的時候，是基于產(chǎn)品維度的。在實際部署的時候，實際上Workload綁定到對應(yīng)的CMDB的最后一級模塊。所以，這里需要自動的將產(chǎn)品配額下發(fā)到CMDB多級模塊的機制，通過DynamicQuota不只是做資源使用上限的控制，更重要的是保證這個業(yè)務(wù)有這么多配額可以用，防止被其他業(yè)務(wù)搶占了。

當然這里還有一些關(guān)鍵問題，比如為了避免資源浪費，我們需要把一些產(chǎn)品的空閑資源借調(diào)給其他已經(jīng)超過配額控制但是需要繼續(xù)使用更多資源的業(yè)務(wù)，這樣配額就有了靈活的彈性。

同時我們也利用了DynamicQuota控制在線業(yè)務(wù)和離線業(yè)務(wù)占用資源的比例，主要是為了保證在線業(yè)務(wù)始終會有一定的配額可以使用，防止離線業(yè)務(wù)無限制侵占整個平臺的資源，同時也能更好的控制集群負載。

大規(guī)模和高性能的彈性伸縮

在擴縮容方面，這里主要介紹縱向擴縮容和橫向擴縮容做的工作。社區(qū)的VPA不太適合很多騰訊的自研業(yè)務(wù)，因為擴縮容都是基于Pod的重建機制，在擴容效果和對業(yè)務(wù)的感知方面，都不是很好。

我們自研了Vertical Workload AutoScaler(VWA)CRD用于Pod的垂直擴縮容，主要解決的問題是:

1.當業(yè)務(wù)出現(xiàn)突發(fā)流量的時候，HPA擴容不及時，導(dǎo)致下面Pod的資源利用率暴漲，進而引發(fā)業(yè)務(wù)的雪崩。VWA有更快的響應(yīng)速度，并且不需要重建Pod，因此比HPA更快更安全。

2.業(yè)務(wù)在使用容器規(guī)格的時候，經(jīng)常把容器規(guī)格配置得比較高，Pod資源使用率會比較低，通過VWA自動進行降配，優(yōu)化資源利用率。

3.當節(jié)點出現(xiàn)高負載的情況下，這個節(jié)點上面跑著在線和離線業(yè)務(wù)，我們會通過VWA快速地對離線業(yè)務(wù)容器進行在線降配，從而保證在線業(yè)務(wù)的服務(wù)質(zhì)量。

這里面核心的特性，包括提供原地升級容器規(guī)格的能力，而不需要重建Container，性能上做了優(yōu)化，單集群能支持上千個VWA對象的擴縮容。同時也支持VWA的個性化配置，比如可以配置每一個VWA對象的循環(huán)同步周期，每次擴容的最大比例以及縮容的最大比例等。

最后再介紹一下在HPA方面我們做的工作。Kubernetes原生的HPA Controller是內(nèi)置在kube-controller-manager里面的，它存在著以下缺陷：

1.它不能獨立部署，如果集群中有成千上萬的HPA對象，原生HPA Controller是很難承受的，穩(wěn)定性也直接受限于kube-controller-manager。

2.另外在性能方面，原生HPA Controller在一個協(xié)程里面遍歷所有HPA對象，所以在大規(guī)模HPA場景下，同步實時性得不到保證。

我們自研了一個HPAPlus Controller，它兼容了原生的HPA對象，然后可以獨立部署，在性能方面類似VWA一樣做了很多性能優(yōu)化，同時豐富了每個HPA對象可自定義的配置，比如同步周期、擴容比例、容忍度等。

HPAPlus-Controller還實現(xiàn)了與CronHPA和VWA進行聯(lián)動決策，比如當VWA持續(xù)擴縮容達到了所屬節(jié)點的上限，無法繼續(xù)擴容的時候，這個時候會自動托管給HPA觸發(fā)橫向擴容。

總結(jié)

騰訊自研業(yè)務(wù)海量規(guī)模，除了文中介紹到彈性伸縮、調(diào)度和資源管理、灰度發(fā)布等方面面臨的挑戰(zhàn)外，我們還在多集群管理、在離線混部、ServiceMesh、異構(gòu)計算、AI/大數(shù)據(jù)框架支持等多方面做了大量工作。另外，TKEx底層正在大量使用EKS彈性容器服務(wù)來提供更好的容器資源隔離能力、彈性能力，以實現(xiàn)真正的零集群運維成本和高資源利用率的目標。

王濤，騰訊云專家工程師，從事Kubernetes容器平臺的研發(fā)近6年，目前主要負責騰訊海量自研業(yè)務(wù)容器化上云的平臺研發(fā)。在利用云原生技術(shù)構(gòu)建DevOps、ServiceMesh、AI、大數(shù)據(jù)平臺等場景有豐富經(jīng)驗。