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

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

海量規模下Kubernetes面臨的挑戰

在騰訊自研業務中，已經有幾百萬核跑在Kubernetes上，要在如此體量的容器場景提供可靠穩定的容器服務，不管在底層、集羣能力、運營或運維等各個方面都面臨具體挑戰。

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平臺縮略版的架構圖，僅包括本次討論的相關能力。

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

高效穩定的發佈能力

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

以一個業務分兩批進行發佈爲例，第一批升級兩個Pod，用戶能夠指定是哪兩個Pod，也能夠按照必定比例指定第一批是10%，由平臺自動選擇10%的Pod進行灰度，剩餘Pods在第二批進行灰度。

• 自動分批機制：若是Pod的探針完善且能真實反映業務是否可用，用戶可使用自動分批機制，上一批次完成後可經過自定義的批次時間間隔和健康檢查機制自動進行下一批的灰度發佈或者自動回滾。
• 手動分批機制：用戶也能夠經過手動分批機制，在上一批次灰度完成後，可人爲在業務層面確認上一批的灰度是否成功，來決定是否觸發下一批灰度仍是回滾。

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

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裏面，經過一個佔位容器和業務容器進行文件鎖的搶佔動做，來實現升級過程當中兩個容器的角色進行快速切換。

動態的資源調度和管理

kubernetes的調度原生是使用靜態調度的方式，在生產環境會出現集羣裏面各個節點的負載不均衡的狀況，而且形成很大的資源浪費。

動態調度器是咱們自研的一個調度器擴展器，主要任務是平衡集羣中各個節點真實的負載，在調度的時候，將各個節點的真實負載歸入考量的範疇。

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

咱們但願可以快速地感知集羣的異常狀況，包括kubelet異常、docker異常、內核死鎖以及節點是否出現文件描述符即將耗盡的狀況，從而能在第一時間去作決策，避免問題的惡化。其中快速發現這個動做是由Node Problem Detector（NPD）組件負責的，NPD組件是基於社區的NPD進行了大量的策略擴展。

NPD檢測到異常後，除了NPD組件自己對節點自愈的動做以外，de-scheduler還會基於異常事件和當前集羣/Workload現狀協助進行動做決策，好比Pod驅逐、Container原地重啓。這裏要重點提一下，咱們基於Self算法的分佈式的Ping檢測，可以快速發現節點的網絡異常狀況，由de-scheduler對網絡異常節點上的Pods進行漂移。

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

好比從業務維度，騰訊會議是一個產品、騰訊課堂是一個產品，每一個產品下面都會有多級業務模塊，在作資源規劃和配額管理的時候，是基於產品維度的。在實際部署的時候，實際上Workload綁定到對應的CMDB的最後一級模塊。因此，這裏須要自動的將產品配額下發到CMDB多級模塊的機制，經過DynamicQuota不僅是作資源使用上限的控制，更重要的是保證這個業務有這麼多配額能夠用，防止被其餘業務搶佔了。

固然這裏還有一些關鍵問題，好比爲了不資源浪費，咱們須要把一些產品的空閒資源借調給其餘已經超過配額控制可是須要繼續使用更多資源的業務，這樣配額就有了靈活的彈性。

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

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

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

咱們自研了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對象可自定義的配置，好比同步週期、擴容比例、容忍度等。

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

總結

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

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公衆號，及時獲取更多幹貨！！