騰訊會議，一款提供靈活協作的線上會議解決方案。其中大量的模塊是有狀態服務，在使用Kubernetes為其進行容器化部署時，Pod升級需保持共享內存、長連接服務。升級時只容忍ms級抖動，需提供大規模分批灰度發布、業務配額控制等能力，並同時解決集群節點負載不均衡、上萬Pods的Workload的HPA性能差等問題。這里將向大家介紹TKEx容器平台及其在灰度發布、資源管理、彈性伸縮等方面的能力。
海量規模下Kubernetes面臨的挑戰
在騰訊自研業務中，已經有幾百萬核跑在Kubernetes上，要在如此體量的容器場景提供可靠穩定的容器服務，無論在底層、集群能力、運營或運維等各個方面都面臨具體挑戰。
- 我們怎么進行容器可靠高性能的灰度發布? 尤其是在自研業務里面，大量的服務是有狀態的服務, 原生的Kubernetes StatefulSet已經無法滿足我們如此大規模的容器發布需求。
- 調度層面需要做哪些優化，從而保證在Pod漂移和重調度的過程中保證業務的穩定性。
- 在優化資源編排性能方面，如何在整個平台層面和業務層面做好后台管理。
- 在大規模的彈性伸縮方面如何提供高性能和全面的彈性伸縮能力。
TKEx容器平台簡介
TKEx容器平台的底層基於騰訊公有雲的TKE和EKS兩個產品，它是使用Kubernetes原生的技術手段服務於騰訊內部的業務, 包括騰訊會議、騰訊課堂、QQ及騰訊看點等。TKEx在灰度發布、服務路由、彈性伸縮、容器調度、資源管理、多集群管理、業務容災、在離線混部等方面做了大量工作，比如：
- 通過Kubernetes API/Contoller/Operator的原生方式適配騰訊內部各種系統，比如服務路由系統、CMDB、CI、安全平台等。
- 通過聲明式的方式，對所有的托管業務進行生命周期管理。
- 支持在線業務、大數據、AI等類型作業。
- 實現在線業務和離線業務的混合部署，同時提升整個資源的利用率。
- 通過優化linux的內核，增強資源底層隔離能力。
- 集成Tencent Cloud Mesh(TCM)服務為自研業務提供ServiceMesh服務。
- 在大規模的集群里面，對彈性伸縮的各種組件進行改造和優化，以保證它的性能和可用性。
- 基於業務產品維度，提供多租戶和配額管理能力。
下面是TKEx平台縮略版的架構圖，僅包括本次討論的相關能力。
- 底層基於TKE和EKS兩個產品，在上層服務於在線業務、AI訓練以及大數據作業。
- 中間這四個框主要包括在應用和路由管理、資源編排調度、彈性伸縮、混部。下面會重點介紹其中前三個部分。
高效穩定的發布能力
業務沒有大規模使用StatefulSet的滾動更新能力，對於有狀態服務來說，原生的滾動更新機制的發布可控性太差，對於multi-zone容災部署的業務更是很難做精細化的發布策略。我們提供了分批灰度發布策略供有狀態服務使用，約80%的Workload都選擇了這種策略。
以一個業務分兩批進行發布為例，第一批升級兩個Pod，用戶可以指定是哪兩個Pod，也可以按照一定比例指定第一批是10%，由平台自動選擇10%的Pod進行灰度，剩余Pods在第二批進行灰度。
- 自動分批機制：如果Pod的探針完善且能真實反映業務是否可用，用戶可以使用自動分批機制，上一批次完成后可通過自定義的批次時間間隔和健康檢查機制自動進行下一批的灰度發布或者自動回滾。
- 手動分批機制：用戶也可以通過手動分批機制，在上一批次灰度完成后，可人為在業務層面確認上一批的灰度是否成功，來決定是否觸發下一批灰度還是回滾。
分批灰度發布更安全、更可靠、更可控的特性，整個發布過程更靈活。由於單個批次內所有選中Pods的更新都是並發的，因此可以應付緊急快速發布的需求。
StatefulSetPlus是我們用來實現分批灰度發布的CRD，它繼承了Kubernetes原生的StatefulSet的所有能力，並在此之上新增和優化了大量特性。StatefulSetPlus主要提供的核心特性包括自動的以及手動的分批灰度發布，在發布異常時可以進行全量一次回滾或者分批次的回滾。Pod更新的策略支持兩種形式，一種是Pod重建的方式，另一種是Pod的原地升級方式。同時我們還提供了一些高級特性，比如：
- 支持Pod升級過程中保持Pod使用的共享內存數據不丟失，這個特性非常適合於像騰訊會議這樣的音視頻業務。
- 如果升級過程中觸發了Workload的擴容，那么擴容的時候會使用上一個好的版本進行擴容，而不是像原生的StatefulSet和Deployment一樣，使用最新的鏡像進行擴容，因為最新的鏡像版本有可能是不可用的，擴容出來的Pod可服務型存在風險。
- 在存儲編排方面，我們繼承了StatefulSet的Per Pod Per PV的特性，同時也支持Per Workload Per PV的特性，即單個StatefulSetPlus下面所有的Pod共享一個PV，也就是類似Deployment共享PV的模式。
- 在StatefulSet里面，當節點出現異常，比如出現了NodeLost的情況下，出於有狀態服務的可用性考慮，不會進行Pod重建。在StatefulSetPlus中，監聽到NodeLost后，對應的Pod會自動漂移。這還不夠，我們會通過NPD檢測，上報事件或Patch Condition快速發現節點異常，對StatefulSetPlus Pod進行原地重建或者漂移等決策。
- 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的垂直擴縮容，主要解決的問題是:
- 當業務出現突發流量的時候，HPA擴容不及時，導致下面Pod的資源利用率暴漲，進而引發業務的雪崩。VWA有更快的響應速度，並且不需要重建Pod，因此比HPA更快更安全。
- 業務在使用容器規格的時候，經常把容器規格配置得比較高，Pod資源使用率會比較低，通過VWA自動進行降配，優化資源利用率。
- 當節點出現高負載的情況下，這個節點上面跑着在線和離線業務，我們會通過VWA快速地對離線業務容器進行在線降配，從而保證在線業務的服務質量。
這里面核心的特性，包括提供原地升級容器規格的能力，而不需要重建Container，性能上做了優化，單集群能支持上千個VWA對象的擴縮容。同時也支持VWA的個性化配置，比如可以配置每一個VWA對象的循環同步周期，每次擴容的最大比例以及縮容的最大比例等。
最后再介紹一下在HPA方面我們做的工作。Kubernetes原生的HPA Controller是內置在kube-controller-manager里面的，它存在着以下缺陷：
- 它不能獨立部署，如果集群中有成千上萬的HPA對象，原生HPA Controller是很難承受的，穩定性也直接受限於kube-controller-manager。
- 另外在性能方面，原生HPA Controller在一個協程里面遍歷所有HPA對象，所以在大規模HPA場景下，同步實時性得不到保證。
我們自研了一個HPAPlus Controller，它兼容了原生的HPA對象，然后可以獨立部署，在性能方面類似VWA一樣做了很多性能優化，同時豐富了每個HPA對象可自定義的配置，比如同步周期、擴容比例、容忍度等。
HPAPlus-Controller還實現了與CronHPA和VWA進行聯動決策，比如當VWA持續擴縮容達到了所屬節點的上限，無法繼續擴容的時候，這個時候會自動托管給HPA觸發橫向擴容。
總結
騰訊自研業務海量規模，除了文中介紹到彈性伸縮、調度和資源管理、灰度發布等方面面臨的挑戰外，我們還在多集群管理、在離線混部、ServiceMesh、異構計算、AI/大數據框架支持等多方面做了大量工作。另外，TKEx底層正在大量使用EKS彈性容器服務來提供更好的容器資源隔離能力、彈性能力，以實現真正的零集群運維成本和高資源利用率的目標。
【騰訊雲原生】雲說新品、雲研新術、雲游新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
