騰訊會議，一款提供靈活協作的線上會議解決方案。其中大量的模組是有狀態服務，在使用Kubernetes為其進行容器化部署時，Pod升級需保持共享記憶體、長連線服務。升級時只容忍ms級抖動，需提供大規模分批灰度釋出、業務配額控制等能力，並同時解決叢集節點負載不均衡、上萬Pods的Workload的HPA效能差等問題。這裡將向大家介紹TKEx容器平臺及其在灰度釋出、資源管理、彈性伸縮等方面的能力。

### 海量規模下Kubernetes面臨的挑戰

在騰訊自研業務中，已經有幾百萬核跑在Kubernetes上，要在如此體量的容器場景提供可靠穩定的容器服務，無論在底層、叢集能力、運營或運維等各個方面都面臨具體挑戰。
![](https://main.qcloudimg.com/raw/72add7fa423cf12b842d530a108d77eb.png)

1. 我們怎麼進行容器可靠高效能的灰度釋出? 尤其是在自研業務裡面，大量的服務是有狀態的服務, 原生的Kubernetes StatefulSet已經無法滿足我們如此大規模的容器釋出需求。
2. 排程層面需要做哪些最佳化，從而保證在Pod漂移和重排程的過程中保證業務的穩定性。
3. 在最佳化資源編排效能方面，如何在整個平臺層面和業務層面做好後臺管理。
4. 在大規模的彈性伸縮方面如何提供高效能和全面的彈性伸縮能力。

### TKEx容器平臺簡介

TKEx容器平臺的底層基於騰訊公有云的TKE和EKS兩個產品，它是使用Kubernetes原生的技術手段服務於騰訊內部的業務, 包括騰訊會議、騰訊課堂、QQ及騰訊看點等。TKEx在灰度釋出、服務路由、彈性伸縮、容器排程、資源管理、多叢集管理、業務容災、在離線混部等方面做了大量工作，比如：

1. 透過Kubernetes API/Contoller/Operator的原生方式適配騰訊內部各種系統，比如服務路由系統、CMDB、CI、安全平臺等。
2. 透過宣告式的方式，對所有的託管業務進行生命週期管理。
3. 支援線上業務、大資料、AI等型別作業。
4. 實現線上業務和離線業務的混合部署，同時提升整個資源的利用率。
5. 透過最佳化linux的核心，增強資源底層隔離能力。
6. 整合Tencent Cloud Mesh(TCM)服務為自研業務提供ServiceMesh服務。
7. 在大規模的叢集裡面，對彈性伸縮的各種元件進行改造和最佳化，以保證它的效能和可用性。
8. 基於業務產品維度，提供多租戶和配額管理能力。

下面是TKEx平臺縮略版的架構圖，僅包括本次討論的相關能力。
![](https://main.qcloudimg.com/raw/604f576010f21068d0d8f96b81155c79.png)

1. 底層基於TKE和EKS兩個產品，在上層服務於線上業務、AI訓練以及大資料作業。
2. 中間這四個框主要包括在應用和路由管理、資源編排排程、彈性伸縮、混部。下面會重點介紹其中前三個部分。

### 高效穩定的釋出能力

業務沒有大規模使用StatefulSet的滾動更新能力，對於有狀態服務來說，原生的滾動更新機制的釋出可控性太差，對於multi-zone容災部署的業務更是很難做精細化的釋出策略。我們提供了分批灰度釋出策略供有狀態服務使用，約80%的Workload都選擇了這種策略。

![](https://main.qcloudimg.com/raw/d65bb085230e44583671c419123da607.png)

以一個業務分兩批進行釋出為例，第一批升級兩個Pod，使用者可以指定是哪兩個Pod，也可以按照一定比例指定第一批是10%，由平臺自動選擇10%的Pod進行灰度，剩餘Pods在第二批進行灰度。

- **自動分批機制**：如果Pod的探針完善且能真實反映業務是否可用，使用者可以使用自動分批機制，上一批次完成後可透過自定義的批次時間間隔和健康檢查機制自動進行下一批的灰度釋出或者自動回滾。
- **手動分批機制**：使用者也可以透過手動分批機制，在上一批次灰度完成後，可人為在業務層面確認上一批的灰度是否成功，來決定是否觸發下一批灰度還是回滾。

分批灰度釋出更安全、更可靠、更可控的特性，整個釋出過程更靈活。由於單個批次內所有選中Pods的更新都是併發的，因此可以應付緊急快速釋出的需求。

![](https://main.qcloudimg.com/raw/5c05e6273e3b488e1609a6114fd730d7.png)

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

1. 支援Pod升級過程中保持Pod使用的共享記憶體資料不丟失，這個特性非常適合於像騰訊會議這樣的音影片業務。
2. 如果升級過程中觸發了Workload的擴容，那麼擴容的時候會使用上一個好的版本進行擴容，而不是像原生的StatefulSet和Deployment一樣，使用最新的映象進行擴容，因為最新的映象版本有可能是不可用的，擴容出來的Pod可服務型存在風險。
3. 在儲存編排方面，我們繼承了StatefulSet的Per Pod Per PV的特性，同時也支援Per Workload Per PV的特性，即單個StatefulSetPlus下面所有的Pod共享一個PV，也就是類似Deployment共享PV的模式。
4. 在StatefulSet裡面，當節點出現異常，比如出現了NodeLost的情況下，出於有狀態服務的可用性考慮，不會進行Pod重建。在StatefulSetPlus中，監聽到NodeLost後，對應的Pod會自動漂移。這還不夠，我們會透過NPD檢測，上報事件或Patch Condition快速發現節點異常，對StatefulSetPlus Pod進行原地重建或者漂移等決策。
5. StatefulSetPlus還有一個非常重要的特性，就是它支援ConfigMap的版本管理以及ConfigMap的分批灰度釋出，這是決定ConfigMap能否大規模在生產中使用的關鍵能力。

這裡特別介紹一下，如何支援Pod升級過程中保持共享記憶體資料不丟失，並且在升級過程中，單個Pod只有毫秒級的服務抖動。主要的實現原理就是在Pod裡面，透過一個佔位容器和業務容器進行檔案鎖的搶佔動作，來實現升級過程中兩個容器的角色進行快速切換。

![](https://main.qcloudimg.com/raw/5b780d50cb1b78bb228030a9b7ee9b04.png)

### 動態的資源排程和管理

kubernetes的排程原生是使用靜態排程的方式，在生產環境會出現叢集裡面各個節點的負載不均衡的情況，並且造成很大的資源浪費。

動態排程器是我們自研的一個排程器擴充套件器，主要任務是平衡叢集中各個節點真實的負載，在排程的時候，將各個節點的真實負載納入考量的範疇。

![](https://main.qcloudimg.com/raw/ff6f454177782e093664c9f7e7ddc405.png)

動態排程器必須要解決的一個技術點是排程熱點的問題。當叢集中有一批節點負載比較低，這時使用者建立大量的Pod，這些Pod會集中排程到這些低負載的節點上面，這將導致這些低負載節點在幾分鐘之後又會成為高負載節點，從而影響這批節點上Pod的服務質量，這種現象尤其在叢集擴容後很容易出現。我們自研的排程熱點規避演算法，極大的避免了某個節點因為低負載被動態排程器排程後成為延遲性的高負載熱點，極少數高負載節點在de-scheduler中會基於Node CPU的歷史監控進行節點降熱操作。。

我們希望能夠快速地感知叢集的異常情況，包括kubelet異常、docker異常、核心死鎖以及節點是否出現檔案描述符即將耗盡的情況，從而能在第一時間去做決策，避免問題的惡化。其中快速發現這個動作是由Node Problem Detector（NPD）元件負責的，NPD元件是基於社群的NPD進行了大量的策略擴充套件。

![](https://main.qcloudimg.com/raw/6e3d1cca7a1d3846dd444b993a539ca2.png)

NPD檢測到異常後，除了NPD元件本身對節點自愈的動作之外，de-scheduler還會基於異常事件和當前叢集/Workload現狀協助進行動作決策，比如Pod驅逐、Container原地重啟。這裡要重點提一下，我們基於Self演算法的分散式的Ping檢測，能夠快速發現節點的網路異常情況，由de-scheduler對網路異常節點上的Pods進行漂移。

在騰訊內部，產品的管理是分多個層級的，因此在配額管理方面，我們沒有使用Kubernetes原生的ResourceQuota機制，而是研發了DynamicQuota CRD來實現多層級的、動態的面向業務的Quota管理。

![](https://main.qcloudimg.com/raw/cc2e2daa9e38ce5aa24f3ddd692903e5.png)

比如從業務維度，騰訊會議是一個產品、騰訊課堂是一個產品，每個產品下面都會有多級業務模組，在做資源規劃和配額管理的時候，是基於產品維度的。在實際部署的時候，實際上Workload繫結到對應的CMDB的最後一級模組。所以，這裡需要自動的將產品配額下發到CMDB多級模組的機制，透過DynamicQuota不只是做資源使用上限的控制，更重要的是保證這個業務有這麼多配額可以用，防止被其他業務搶佔了。

當然這裡還有一些關鍵問題，比如為了避免資源浪費，我們需要把一些產品的空閒資源借調給其他已經超過配額控制但是需要繼續使用更多資源的業務，這樣配額就有了靈活的彈性。

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

### 大規模和高效能的彈性伸縮

在擴縮容方面，這裡主要介紹縱向擴縮容和橫向擴縮容做的工作。社群的VPA不太適合很多騰訊的自研業務，因為擴縮容都是基於Pod的重建機制，在擴容效果和對業務的感知方面，都不是很好。

![](https://main.qcloudimg.com/raw/2f4a8799c6a2a5d4ff70e1bb209679e3.png)

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

1. 當業務出現突發流量的時候，HPA擴容不及時，導致下面Pod的資源利用率暴漲，進而引發業務的雪崩。VWA有更快的響應速度，並且不需要重建Pod，因此比HPA更快更安全。
2. 業務在使用容器規格的時候，經常把容器規格配置得比較高，Pod資源使用率會比較低，透過VWA自動進行降配，最佳化資源利用率。
3. 當節點出現高負載的情況下，這個節點上面跑著線上和離線業務，我們會透過VWA快速地對離線業務容器進行線上降配，從而保證線上業務的服務質量。

這裡面核心的特性，包括提供原地升級容器規格的能力，而不需要重建Container，效能上做了最佳化，單叢集能支援上千個VWA物件的擴縮容。同時也支援VWA的個性化配置，比如可以配置每一個VWA物件的迴圈同步週期，每次擴容的最大比例以及縮容的最大比例等。

最後再介紹一下在HPA方面我們做的工作。Kubernetes原生的HPA Controller是內建在kube-controller-manager裡面的，它存在著以下缺陷：

1. 它不能獨立部署，如果叢集中有成千上萬的HPA物件，原生HPA Controller是很難承受的，穩定性也直接受限於kube-controller-manager。
2. 另外在效能方面，原生HPA Controller在一個協程裡面遍歷所有HPA物件，所以在大規模HPA場景下，同步實時性得不到保證。

我們自研了一個HPAPlus Controller，它相容了原生的HPA物件，然後可以獨立部署，在效能方面類似VWA一樣做了很多效能最佳化，同時豐富了每個HPA物件可自定義的配置，比如同步週期、擴容比例、容忍度等。

![](https://main.qcloudimg.com/raw/eed246ea7dc7f8095283613ebdb2fda5.png)

HPAPlus-Controller還實現了與CronHPA和VWA進行聯動決策，比如當VWA持續擴縮容達到了所屬節點的上限，無法繼續擴容的時候，這個時候會自動託管給HPA觸發橫向擴容。

### 總結

騰訊自研業務海量規模，除了文中介紹到彈性伸縮、排程和資源管理、灰度釋出等方面面臨的挑戰外，我們還在多叢集管理、在離線混部、ServiceMesh、異構計算、AI/大資料框架支援等多方面做了大量工作。另外，TKEx底層正在大量使用EKS彈性容器服務來提供更好的容器資源隔離能力、彈效能力，以實現真正的零叢集運維成本和高資源利用率的目標。

騰訊會議大規模使用Kubernetes的技術實踐

相關文章