春節前後因受新冠肺炎疫情影響，線上辦公應用迅速火爆，騰訊會議作為一款企業級線上辦公産品，迅速受到使用者認可。使用者數在爆炸式增長的同時，業務也在高速的疊代更新，40天完成14大版本更新，上演了一場小步快跑，快速疊代的經典案例。本文将從容器的角度着手，為大家呈現騰訊會議如何基于騰訊雲容器服務TKE，在後端容量達到100萬核的曆程下，版本快速疊代背後的雲原生技術。
騰訊會議作為面向企業級的關鍵産品，對産品的可用性和穩定性要求是非常高的，任何服務不穩定都可能會導緻使用者無法接入會議、會議中斷或音視訊品質差，進而導緻使用者投訴，影響到産品口碑，降低使用者信任度。
同時，使用者數爆炸式增長，需要後端能力可以實時跟上使用者的增長節奏，對擴容時效性有非常高的要求。此外，服務營運過程中，産品必然會有功能調優、bug修複等疊代更新，為了使對更新戶使用透明，要求平台能高效、可控地支援業務程式釋出更新。
解決思路
為解決上述業務場景需求，基于騰訊雲容器服務(TKE)實作了對騰訊會議的支撐。借助TKE的動态路由、固定網絡、彈性伸縮、以及可控更新等能力，完美地承載了騰訊會議、線上教育、空中課堂等疫情期間高增長業務的部署營運，管理平台架構如下：
管理平台基于TKE叢集部署服務，并基于此做了一些功能拓展，圖示綠色标示已實作的能力，紅色标示進行中，灰色為規劃中待實施；TKE叢集以騰訊雲CVM、CBS、CLB、VPC等基礎能力為根基，部署雲原生的k8s叢集；通過基于TKE拓展的operator，從路由(CLB/L5 Controller)、網絡(Ipamd)、資源管理(NodeResourceOversell、DynamicQuota)、彈性伸縮(VPA、HPAPlus)等多個次元做了功能優化，很好地支撐了騰訊會議等騰訊自研業務的部署營運。
業務部署模型如下：
這裡業務分三套環境部署，分别對應測試、預釋出、正式三套namespace。業務在namespace下以多套微服務模式部署。每套服務包含一套獨立完整的執行資源，如：workload、service/ingress、configmap、secret、pv/pvc等
騰訊雲容器服務TKE英文全稱是Tencent kubernetes Engine，簡稱TKE，旨在為使用者提供穩定、安全、高效、靈活擴充、簡單易用的 Kubernetes 容器管理平台。TKE基于原生 kubernetes 提供以容器為核心的、高度可擴充的高性能容器管理服務，完全相容原生 kubernetes API ，擴充了騰訊雲的雲硬碟、負載均衡等 kubernetes 插件，為容器化的應用提供高效部署、資源排程、服務發現和動态伸縮等一系列完整功能，解決使用者開發、測試及運維過程的環境一緻性問題，提高了大規模容器叢集管理的便捷性，幫助使用者降低成本，提高效率。
具體方案解析
下面将從具體從品質保證、效率以及可控更新三大方面介紹騰訊雲容器服務TKE是如何支撐騰訊會議的業務演進的。
1、品質保證
業務服務穩定性直接決定了産品口碑，為了保證騰訊會議等業務的服務品質，騰訊雲在以下動态路由、異常檢測、并行擴容、業務遷移幾個次元做了保障措施：
1.1動态路由
動态路由是基于騰訊自研的路由系統L5，通過在TKE叢集内拓展service能力實作的L5-controller元件。L5-controller控制層面實作邏輯和通用controller類似，基本流程包括監聽變更事件，觸發回調，入隊列；拉起worker，更新路由。 複制
不過為了保障路由的一緻性，擴充了主輔兩套功能流程，如上圖分别用橙、綠色箭頭标示流程，主流程保障實效行，輔流程保障一緻性。其中，主流程通過監聽事件，實時觸發，且多worker并發執行，保障路由更新時效性，秒級生效。輔助流程串行掃描叢集中的service，拉取該service對應的路由配置資料與L5路由系統中的資料做對賬，查漏補缺，任何非通過中控台的路由設定，都會被做強一緻性檢測到并覆寫，分鐘級生效。L5-controller資料層面可以保證變更設定秒級生效，強一緻性分鐘級實施
1.2 異常檢測
通過雲原生k8s自帶的以下能力，支援使用者自定義pod健康檢查，保證服務在異常時段内，流量隔離
- livenessProbe：存活檢查探針
- readinessProbe：就緒檢查探針
- postStart：pod正常拉起前指定執行動作
- preStop：pod銷毀前指定執行動作
- terminationGracePeriodSeconds：pod終止等待時間
通過以上幾個功能特性的使用，配合動态路由能力，可以實作業務服務的高穩定性保障。
1.3 并行擴容
在騰訊會議這種網際網路海量使用者場景中，對擴容敏感性的把握是非常需要的，流量短時間爆發式增長，要求後端擴容節奏必須能跟上，是以騰訊雲對雲原生的HPA的兩大能力做擴充，其一是并發量，以高并發的方式運作擴容檢測流程，高并發主動檢測業務高負載，然後根據實況實時觸發擴容；其二是計算周期，支援使用者自定義設定檢測計算周期，最低甚至可達到秒級，當檢測流程在計算周期内發現高負載，可實時觸發擴容。
1.4 業務遷移
業務遷移主要通過以下三種模式實作：
helm部署：雲原生的方式，一份配置，多叢集分發，優點是高效可管理，缺點是容易和現網運作配置存在缺漏差異，導緻不一定完全可用，強依賴于部署規範
namespace打包複制：将業務的ns及該ns下所有資源全量打包，複制部署到另外的叢集中，盡可能地保證業務的執行環境及配置還原，中控台已實作一鍵操作，快速高效
namespace打包複用：和上面流程類似，存在功能優化即支援使用者自定義調整配置，降低使用者操作成本
2. 效率
新冠疫情期間，騰訊會議受廣大使用者良好口碑認可，使用者爆發式增長，服務的部署效率是核心能力展現，為了助推平台能力可以快速适應使用者增長的節奏，騰訊雲從流程自動化、CI/CD、鑒權管理、彈性擴縮幾方面做了努力：
2.1 自動化
自動化主要是為了提高流程效率，具體實施流程如：建立叢集、叢集容量擴充、環境初始化、元件分發，依賴騰訊雲API，自動實施建立叢集、叢集添加node；環境初始化，核心參數調整、系統環境設定、工具安裝、檔案系統格式化、元件分發等流程，都是依賴于腳本封裝，工具化執行；中控台對各流程、工具的一體化整合，都是通過平台通道實施的，如：批量執行腳本、批量安裝，建立叢集後注冊中控台等
2.2 CI/CD
部署在TKE叢集的騰訊内部業務，基本都已打通CI/CD流程，并且支援跨多個網絡環境串聯部署，騰訊會議通過現有CI/CD模式，借助于雲原生的服務編排模式部署，實作了從開發、部署、測試、上線、及版本疊代的高效落地
2.3 鑒權管理
CMDB作為産品、業務子產品、IP的關聯關系管理模型，應用非常廣泛，在很多公司的業務場景中都有重用。CMDB Controller的實作和通用Controller邏輯基本類似，具體包括監聽apiserver的pod變更事件、根據事件回調觸發對應worker、worker查詢叢集資訊，查詢pod關聯的産品資訊、最終将關聯關系落地到CMDB服務系統。
CMDB的實時同步，為很多定制化的拓展功能落地提供了很好的輔助作用，如下面的鑒權申請流程：
如流程圖示，通過init-container模式，通過業務CMDB快速同步落地，與騰訊内部的織雲、L5等系統關聯，可以高效打通鑒權通道，使得一直讓業務頭疼鑒權申請全自動化，高效的支援業務服務部署。
2.4 彈性擴縮
為了滿足騰訊會議等關鍵業務的場景需求，除了雲原生的VPA能力外，騰訊雲基于雲原生HPA做了拓展，通過單獨抽離出HPA功能子產品以Operator方式實作，用以支援業務自定義特性設定，具體拓展能力包括多路名額，支援通過Metrics server、Promethus、業務監控等多路名額采集，更好地相容業務場景
；并行實施，多work并行檢測業務名額，實時觸發彈性伸縮，保證時效性；自定義，支援使用者自定義擴縮容門檻值、計算周期、彈性系數。其中多路名額的功能架構如下圖：
3.可控更新
騰訊會議對于使用者來說，都是用于解決使用者直面溝通難的關鍵場景，為了提供更好使用者體驗，産品營運過程中，或多或少會有功能優化、bug修複等疊代。在雲原生的模式下，如何保障更新更新的可靠、可控顯得尤為重要。騰訊雲基于雲原生能力在以下固定網絡、更新輕量化、分批更新、容量保障四個方面做了拓展優化，實作了以下幾個場景需求的能力：
3.1 固定網絡
固定網絡是指pod銷毀重建後ip依然不變，場景如：pod異常、workload版本更新等，固定網絡是騰訊自研業務非常認可的一大特性，很多業務背景服務都有基于ip的鑒權管理、白名單機制等功能依賴，相信不少公司都會有類似的場景需求。固定網絡的設計基于三大功能子產品：IPAMD Controller、TKE-ENI-AGENT、CNI：
- IPAMD Controller以operator形式運作，負責ip的配置設定管理、網絡資源的狀态更新、以及node、pod的關聯關系的記錄更新等
- TKE-ENI-AGENT以daemonset方式運作在每個node上，負責路由對賬、生成 cni 配置、設定節點政策路由和 Pod 的網絡堆棧
- CNI也是運作在node上，負責實施節點政策路由和 Pod 的網絡堆棧
固定網絡的具體實作流程如上圖：
- 使用者發起statefulset的建立
- IPAMD Controller通過list-watch機制，監聽到建立請求
- IPAMD Controller通過IP allocator去對新statefulset下所有pod配置設定IP
- IPAMD Controller為每個pod生成對應的網絡配置StaticIPConfig，然後在該statefulset以後的生命周期中，對pod與已配置設定ip的關聯關系和狀态更新進行管理
- IP allocator是IPAMD Controller的核心功能，它會根據pod資訊和statefulset的狀态去判斷目前pod是建立申請、銷毀重建預留、删除回收等流程，并生成對應配置，當statefulset建立時，allocator會配新的IP給到pod，當pod異常銷毀重建時，allocator會臨時回收保留原IP，等重建好後，重複複用，當statefulset删除時，會把所有配置設定的IP回收
- 當pod在node上建立時，會通過TKE-ENI-AGENT擷取IPAMD已經生成好的網絡配置StaticIPConfig，然後通過GRPC的方式請求IP allocator實施生效pod網絡配置
- IP allocator接收到TKE-ENI-AGENT請求後，會去擷取已經配置設定好的pod網絡配置StaticIPConfig，然後根據配置去調用騰訊雲接口建立ENI彈性網卡，最後生成CNI配置CNIInfo
- CNI根據IP allocator生成的配置CNIInfo，實施節點政策路由和 Pod 的網絡堆棧，生效pod網絡
3.2 StatefulsetPlus Operator
雲原生的Deployment、StatefulSet等workload類型，沒法很好地滿足騰訊會議等業務的使用需求如：更新輕量化、分批更新、容量保障等，是以騰訊雲基于StatefulSet開發一套Operator支援新的workload類型即StatefulsetPlus，它繼承了Kubernete内置的StatefulSet所有核心特性，主功能邏輯和StatefulSet類似，但做了細分能力拓展如支援容器（Pod）執行個體的固定IP、支援應用的多批次灰階更新，更好的相容傳統應用的釋出、Node失聯時，Pod的自動漂移、支援容器原地更新。StatefulsetPlus Operator的應用架構及功能子產品如下：
StatefulsetPlus通過CRD模式部署，和Statefulset的yaml參數有部分差異，使用方式和Statefulset基本一緻
3.3 分批更新
諸如騰訊會議等很多重點業務，在更新更新時要求絕對地可控推進，分批更新便是基于該場景拓展實作的，也可以更好的相容傳統應用的釋出，分批更新在實際使用中的演化過程如下所示：
分批更新要做到足夠可控，需要在發起更新時預先指定批次，後續每個過程都會有人工觸發，若出現更新失敗，可以修複後繼續，也可以直接走Rollback流程，相對于其他workload，StatefulsetPlus的分批更新功能帶給使用者的使用優勢是使用者可配置每個批次的執行個體集，比如使用者可根據應用服務地區，隻暫時更新對應地區的執行個體。每個批次指定執行個體進行并發更新，更新效率高。
同時，更新更安全和省心，支援每個批次完成後等待使用者确認，再觸發更新下一批執行個體，通過應用探針自動監測到更新成功後，自動觸發更新下一批執行個體。另外，支援手動伸縮容，基于基礎名額(Cpu, Mem, Network I/O)的彈性伸縮，也支援基于應用自定義監控名額的彈性伸縮。
總結
目前，全面上雲的趨勢已然清晰，騰訊會議也借助于雲計算的盛風順勢起飛，迅速基于雲原生技術完成版本的快速疊代和功能的完善更新。在各行各業雲原生改造盛況之下，容器技術在其中作用至關重要。騰訊内部在很早之前就已經研究與容器相關的技術與服務，其中很多成功的業務，例如遊戲、微信、廣告等都選擇運作在容器技術上，可以說容器技術正在支撐着數十億計的使用者。
随着雲原生技術生态蓬勃發展，作為一枚技術追随者，也希望騰訊雲容器服務TKE技術能支撐着更多業務傲然前行。