👉騰小云導讀
2022 年 10 月，騰訊自研業務產品全面完成雲原生上雲。自研業務產品雲上規模已突破 5000w CPU，藉助雲原生的技術優勢，全面提升了騰訊自研業務產品的運營效率，在此過程中我們也對騰訊雲產品進行了打磨和驗證。無論是在業務場景、穩定性要求、運維效率等多個方面，大規模容器化過程中都面臨不少的技術挑戰。本篇將進行分享，希望可以給廣大開發愛好者帶來靈感。
👉看目錄，點收藏
1 項目背景
1.1 騰訊自研業務產品雲原生上雲歷程簡介
1.2 騰訊有狀態服務的共性
2 騰訊大規模業務容器化面臨的幾個挑戰
2.1 容器快速升級
2.2 容器原地熱升級
2.3 面向業務產品的全局快速擴縮容
2.4 對應用屏蔽多樣的底層機型，提升資源池利用率
2.5 從面向集羣到面向應用的調度編排
3 總結
騰訊自研業務產品歷經三年，包括 QQ、微信、王者榮耀、騰訊會議等億級用戶規模的業務產品，都已全面上雲。自研業務產品雲上的資源規模已突破 5000 萬核，打造了國內最大規模的雲原生實踐典範。各位讀者點👉這裏👈進入頁面，右邊掃碼關注騰訊雲開發者公衆號，回覆「雲原生」可下載鵝廠7w字大規模雲原生技術實踐案例集、騰訊雲技術實踐精選文集。
在這個過程中，騰訊做了大量的技術優化和突破，包括優化 K8s 集羣、全局的資源管理調度，實現了 65%的 CPU 利用率、提升容器應用鏈路上各層的穩定性等等。
3 年時間，騰訊最終達成了全面雲原生上雲的目標。在容器應用管理上，有幾個事情非常關鍵：
-
最早期需要雲原生理念的佈道。讓所有業務產品”認識“到雲原生上雲所帶來的業務價值。幾年前，騰訊內部的 K8s Oteam 聯合騰訊學堂推出了第一個面向全公司的 K8s 系列課程。
-
提供易用性和穩定性的容器管理平臺。這解決不同的業務場景容器化上雲的痛點並沉澱了產品的能力，讓所有騰訊業務產品都真實感受到雲原生上雲的價值。
-
資源調度編排能力。底層海量的資源規模，需要打造極好的資源調度編排能力，提升全局的資源利用率，從集團層面達成上雲後的降本增效目的。
-
度量機制。「各個業務產品雲原生上雲做的怎麼樣」需要有一套度量機制。例如騰訊的雲原生成熟度模型，有效幫助各個業務提升了業務產品的雲原生成熟度。
下面將主要介紹開發過程中我們遇到的部分技術挑戰和解決方案，各位將能看到我們在此過程中是如何一步步去夯實產品能力的。
01、項目背景
1.1 騰訊自研業務產品雲原生上雲歷程簡介
騰訊自研業務產品容器化上雲始終以騰訊雲產品爲底座，整個過程分爲兩個階段，雲原生上雲 1.0 和 2.0 階段。2022 年前主要是 1.0 階段，技術中心在「離線混部、在線混部」場景中，業務產品的容器化形態主要經歷了富容器和微容器 2 個形態。
經過大規模自研業務產品的容器化，團隊沉澱了各種業務場景下容器化上雲的最佳實踐方案和產品所需的能力，例如容器調度（單集羣和多集羣）、彈性伸縮、有狀態服務容器化、大規模資源管理、穩定性提升、業務運維效率提升等。
上雲階段不僅僅是把業務產品容器化上雲，更重要的是要給業務產品帶來實際的價值。**這裏有騰訊雲原生的成熟度規則，來考覈騰訊自研業務產品和其對應的容器平臺。**主要從四個維度考覈：
最大的權重維度是資源利用率，指業務產品容器利用率、平臺資源利用率。還有彈性伸縮能力、容器可調度能力以及申請的 Pod 資源是不是小核心的資源。通過這些核心指標來規範和評估業務產品雲原生上雲的過程和效果。
1.2 騰訊有狀態服務的共性
-
使用 IPC 共享內存時，可能有超 GB 的有狀態本地數據，升級時不能丟失，而且只允許 ms 級的用戶無感知抖動。
-
部分模塊的開發框架需要支持熱升級：在容器升級時支持熱升級。
-
海內外多地域部署，單個模塊最多的實例數超過 1 萬，整個產品的 Workload 十萬級，分佈在上百個集羣中。
-
底層使用的資源有各代的老舊機型，也有相對較新的機型，但業務產品基本上不篩選機型。
這些業務產品特性使其在 TKE 管理上面臨巨大挑戰，既要儘量兼容這些業務產品特性，也要保持其使用鏡像發佈和升級的雲原生準則。TKEx 應用管理平臺抽象出了這些特性背後的需求，研發了多集羣統一灰度發佈、多地域多集羣工作負載管理、面向應用的多集羣協同擴縮容、容器快速升級、容器熱升級等通用的平臺能力。
02、騰訊大規模業務容器化面臨的幾個挑戰
2.1 容器快速升級
針對「使用 IPC 共享內存，可能有超 GB 的有狀態本地數據，升級時不能丟失，而且只允許 ms 級的用戶無感知抖動」 這個業務產品特性，TKEx 應用管理平臺開發團隊設計研發了使容器快速升級的產品能力，提供像進程重啓一樣的 ms 級業務抖動體驗，這也是騰訊會議容器化上雲很有挑戰性的點。
容器原地升級，也是一種針對有狀態服務進行升級的有效手段。實現在 Pod 不重建的情況下，Pod 內某個 Container 進行重建，保持了 IPC 共享內存，本地有狀態數據不丟失。但是原地升級過程中，雖然容器網絡和存儲不再需要重新分配和掛載，但是仍然需要 ReCreate Container，就會存在 Image Pull 和 Container 銷燬和啓動的過程。
因此原地升級的整個流程耗費時間一定是秒級的，這會造成服務的秒級不可用。結合 ReadinessGateway 能做到按需添加/剔除路由，實現過程中請求無損。但是用戶的有狀態數據是在本地的，請求表面無損，而實際上用戶對應的長鏈接服務已經無法正常提供服務了。這會導致會議秒級中斷，是不可行的。
Pod 裏有 3 個關鍵容器，它們的職責分別如下:
接下來，此處我們以業務從版本 V1 升級到版本 V2 爲例，闡述升級流程。
-
用戶第一次部署業務，如上最左邊的 Pod, 一共有 3 個容器。biz-sidecar，biz-container（配置環境變量版本號爲 1）以及 biz-pause（配置環境變量版本號爲 1）。所有容器啓動後會分別將 version1, version2 文件的內容更新爲 1，biz-sidecar 此時爲 Ready。
-
更新 Pod 前的 biz-pause 容器爲業務 V2 版本的鏡像，同時環境變量版本號爲 2，等該容器原地升級後把 version2 文件的內容更新爲 2， 之後開始等待文件鎖。此時 biz-sidecar 探針轉爲 notReady 狀態。
-
StatefulSet-Operator Watch 待 biz-sidecar 爲 notReady 後，再將之前的v1 版本的業務鏡像替換成 biz-pause 鏡像，同時環境變量版本號爲 2。等 pause 鏡像容器原地重啓後，會將之前 v1 業務鏡像所佔文件鎖釋放，同時version1 內容更新爲 2。此時 sidecar 探針爲 Ready, 整個升級結束。
值得注意的是，原生 K8s apiserver 允許修改 Pod 的 image 等，不支持修改 resource 以及環境變量等，所以該方案需要修改 K8s apiserver 的相關代碼。另外爲了保證 Pod request 資源以及其 Pod qos 不變，StatefulSetPlus-Operator 在升級時需要對各階段容器進行 Resource 調整。
最後，基於這個技術原理，我們封裝成 TKEx 應用管理平臺所需能力的產品，提供簡單好用的操作體驗。用戶按規則編譯好鏡像後，只需升級時勾選「快速升級」，即可完成整個過程。
通過佔位容器、狀態機 Sidecar 容器、原地升級、共享 volume、文件鎖機制，實現容器升級時業務進程的快速切換。
保持鏡像發佈的雲原生體驗，實現方式完全是 K8s 原生，拒絕把容器當虛擬機使用。
2.2 容器原地熱升級
部分模塊發佈需要保持共享內存數據不變，並且業務自身要有熱重啓能力，容器化如何提供業務熱升級的能力？ 是雲直播等業務模塊能否順利容器化的關鍵。針對 「部分模塊的開發框架支持熱升級，需要在容器升級時支持原地熱升級」這一業務訴求，TKEx 應用管理平臺基於 Kubernetes 原地升級、共享 volume、Probe 和佔位容器的關鍵技術，完成並實現了原生的業務容器原地熱升級的技術方案和平臺能力。
方案說明：
- 將業務鏡像按職責一拆爲二，一個負責業務 bin 文件更新，一個負責業務運行環境。
- 通過佔位容器、原地升級、共享 Volume、探針機制的基礎功能，實現容器熱升級。
其中，佔位容器負責將業務新版本鏡像中的新版本業務 bin 複製到共享 volume。業務容器 watch 共享 volume 中相關內容的變化，並可以進行進程 reload 熱升級。
而業務容器的探針 Readiness 要負責感知原地熱升級的狀態，從而支持原地熱升級的時候仍然能進行容器流量管理。但實際上，因爲原地熱升級通常是 ms 級的，通常沒有必要去在這 ms 級時間範圍內做路由的剔除和添加。
此過程中，需始終保持以鏡像發佈的雲原生體驗，實現方式完全 k8s 原生，拒絕把容器當作虛擬機用的方式去做業務進程升級。遺憾的是目前還沒有將這些技術原理封裝成平臺能力，所以業務要做原地熱升級的知識門檻仍然較高。
2.3 面向業務產品的全局快速擴縮容
因接入需求和容災、多活的需求，有些頭部業務產品海內外多地域部署單個模塊最多的實例數超過 1 萬。整個產品的 Workload 萬級，分佈在上百個集羣，和其類似的自研業務產品其實不少。這種業務產品有一個特點，通常對一段時間的「PCU（同時最大在線人數）」的預估來提前進行擴縮容的決策。
例如當前業務產品的 PCU 是 2kw, 需要擴容到 3kw，核心鏈路上的大部分模塊都需要在當前規模的基礎上擴容 50%。在如此複雜的業務分佈拓撲中，要提前進行大規模擴縮容會面臨很多困難：
- 因爲 Workload 數量萬級，如果直接對面向 Kubernetes 集羣的 Workload 進行操作，需要投入非常多的運維人力共同參與。
- 因爲擴容規模較大，會出現某些集羣的資源不足的問題，包括集羣內的計算資源、存儲資源、網絡資源等。過程中若頻繁遇到這類問題，會導致擴容效率極低，溝通成本極高。
- 在擴縮容失敗中遇到的各種問題，很容易被遺漏，缺少自動化收集和聚合整個擴縮容動作出現的所有關鍵事件和日誌的能力。
爲此，平臺進行了基於業務自建拓撲的全局快速擴縮容產品能力建設，通過任務的形式管理全局擴縮容，核心能力如下：
第一，用戶選擇一批跨業務、跨集羣的 Workload，組成一個全局的業務拓撲 Set，作爲業務產品維度的擴縮容任務設計的對象，設置全局擴縮容參數，完成擴縮容下發動作。當前支持「基於步長」和「基於等比例」兩種擴縮容策略，支持配置 HPA 的 Workload 和未配置 HPA 的 Workload 的提前全局擴縮容。這裏有 2 種情況：
- 對於配置了 HPA 的 Workload 的全局擴縮容，主要根據步長或比例調整 HPA 對象的 minReplicas 和 maxReplicas；
- 對於未配置 HPA 的 Workload 的全局擴縮容，主要根據步長或比例調整 Workload Spec 的 Replicas。
第二， 在配置好全局擴容後，資源概覽頁支持按照「計算資源」、「IP 資源」、「配額」三個維度展示資源需求、資源庫存和詳細資源缺口等數據，方便按需補充對應資源。
第三，基於業務大盤視圖展示的整個擴縮容任務的所有 Workload 和 Pod 實時狀態信息，可以快速找出異常 Pod（狀態異常、實時利用率異常），快速掌握整體業務服務擴縮容狀態。
第四，提供業務產品的全局 Workload 擴縮容狀態視圖。支持按照業務、集羣、地域等維度聚合查看整個擴縮容任務中所有 Workload 的擴縮容進展，並有完整的 Workload 列表頁展示各 Workload 運行中副本數量、目標副本數量、庫存副本數和異常信息。
方案說明： 在 TKEx 應用管理平臺中，基於 Clusternet 構建的多集羣管理方案，業務產品全局快速擴縮容的核心組件 Global Scaler Operator部署在 Clusternet Hub Cluster 中，用戶在平臺前端構建生成 ScalerJob CR 後，會自動生成ScalerTemplate。
Global Scaler Operator 核心管理着 2 個 CRD，分別是前面提到的擴縮容任務 ScalerJob 和擴縮容模板 ScalerTemplate 。
| CRD | 解析 |
|---|---|
| ScalerJob | 定義全局擴縮容配置，並關聯擴縮容模板 ScalerTemplate，爲整個全局擴縮容提供按指定策略觸發運行、回滾、終止等核心能力的定義和狀態管理。 |
| ScalerTemplate | 定義要擴縮容的 Workloads 對象及其 Scale 參數，也提供全局擴縮容回滾模板的能力。 |
全局快速擴縮容策略：前面提了 2 個業務產品全局擴縮容策略，這裏舉個例子做簡單說明。假如業務產品X有 3 個 Workload，分佈在廣州、上海、北京，副本數分別是10, 20, 30，當前支持的 PCU 是 10w，需要新增擴容支持 5w PCU。
2.4 對應用屏蔽多樣的底層機型，提升資源池利用率
底層使用的資源有各代的老舊機型，也有新代機型。如何讓業務能無差異的使用這些資源，是提升整個資源池利用率必須要解決的問題。例如 Application X 的實例分佈在北上廣 3 個地域，調度在多個集羣中使用了騰訊雲 S3、S4、S5、S6 多種機型資源。如果不做各個實例的路由權重上的差異化處理，那麼必定會出現每個實例的負載不一致。這就容易出現老舊代機型高負載，新代機型低負載的情況。並且平均負載並不高，不能觸發原生 HPA，從而導致業務服務質量出現下降。
如果使用的服務路由系統具備「根據實例負載或者自定義指標動態調整服務權重」的能力，這一問題將得到大幅緩解。
爲了解決這個問題，目前有 2 個解決方案，分別應用在不同的業務場景中：
【方案1】
引入機型族的概念。基於計算、存儲、網絡等方面的關鍵性能指標，構建綜合性模型，將性能接近的機型放入同一個機型族（普通性能機型族、高性能機型族、指定機型），從而大幅收斂原本暴露給用戶的底層機型。調度上保證同一個 Workload 都使用一個機型族，最終使得各個業務實例在請求量一致的情況下負載基本均衡。這樣業務的平均負載就與各個實例的負載方差很小，HPA 也能正常工作，以保證業務的服務質量。
這種方案主要適用於批量計算型業務，也適用於業務對機型性能有一定要求的業務，或者必須指定某個具體機型的通用計算場景，但是可能會面臨一些資源調度上的風險，例如業務指定機型或機型族的資源不足等問題。這個方案本質上是在緩解這類對資源有性能要求的業務問題。機型族應用越多，該方案對提升底層各種好差料的效果就越好。 
【方案2】
將底層算力標準化、產品化。平臺將底層的所有機型算力都按照預設的模型折算到標準算力，平臺從底層資源池中按需調度算力組合成業務需要的標準算力需求。應用在部署和擴縮容時需要的資源，都以標準算力爲單位，不用再關注任何機型信息。
例如，應用X需要在廣州任意 2 個可用區等比例算力部署，共需要 32c200g (c* 表示標準 cpu 單位，g* 表示標準內存單位)。假設底層資源池中一共有 3 種機型，機型 A 的算力爲標準算力的 50%，機型 B 的算力爲標準算力的200%，機型 C 的算力正好是標準算力，則應用X可能的部署拓撲如下。 
這裏還有一個重要的工作，就是需要根據各種底層組合的機型的算力，動態調整對應的服務路由權重。因此 TKEx 應用管理平臺聯合北極星 Polaris，將各個機型的算力動態折算成路由權重動，實現了基於機型算力的業務全局動態路由權重能力，最終使得同一個 Workload 下不同機型的負載基本保持平衡。
2.5 從面向集羣到面向應用的調度編排
前幾年大家更多關注的是怎樣給用戶提供直接面向 K8s 集羣的業務管理能力。在小規模業務場景下，這種方式沒有痛點。但隨着業務規模的增加，這裏的業務管理痛點就逐漸暴露。用戶要感知底層大量的可用區和集羣，對應大量的 Workload、ConfigMap、Service、Ingress 對象的管理。因此這裏要轉換思路，由面向集羣到面向應用的調度編排，這意味着用戶不用再關注集羣，不用關注底層資源，不用關注每個集羣中的 K8s 對象管理，只需關注應用本身。
舉個例子，某個業務產品在全網有上萬個 Workloads 和 Pods ，分佈在全球十幾個地域、近百個集羣。要對這個業務某個模塊做一次全網升級變更，按照以前面向集羣的方式實現效率較低，當然藉助上層 的 DevOps 流水線可以提升一些效率。所以要抽象出面嚮應用的管理能力，簡化業務產品在部署、擴縮容、升級變更、配置管理、流量管理、業務看板等方面的操作體驗和效率。
要實現這一目標，核心的底層能力建設就在多集羣編排調度上，可以基於Clusternet 的多集羣管理能力來實現。例如，應用想部署同城多活的場景，TKEx 應用管理平臺直接提供這種部署策略，不用去指定 Region 去找合適的集羣單獨部署，直接指定 Region 後，Clusternet 動態拆分調度器 i ，自動根據集羣容量、位置拓撲等信息來做調度決策，選擇合適的集羣並做好最佳的副本分佈決策。
再例如，配置應用彈性伸縮時，不需要再面向集羣配置 HPA。會有一個全局的多集羣 HPA Coordinator Controller 做多集羣 HPA 協同，可以根據集羣容量、集羣的可用性做 HPA 參數的動態調整和協同，保證業務擴容時不會因爲某個集羣的資源不足無法擴容，會自動在其他可用集羣中擴容。
還有很多重要業務場景，需要在多集羣編排中解決。例如面向應用灰度升級時，應用對應的 Workloads 分佈在底層多個集羣中，如何做好多集羣的應用灰度發佈？ConfigMap 的多集羣灰度發佈也是一樣的道理。另外，給用戶提供的大盤視圖、監控告警能力等等都不再是面向集羣維度的，而是面向應用的多集羣聚合維度的。
03、總結
騰訊擁有國內最大規模的雲原生實踐案例，過程中大量的技術和產品能力服務了大量業務場景，包括音視頻、遊戲、電子商務、社交、辦公協同、出行等。我們正在將這裏積累的各種業務場景的最佳實踐經驗，例如應用的標準化檢測、業務的 QoS 定義、應用多集羣灰度發佈、應用多集羣自愈等等，都輸出到雲原生應用管理平臺這個公有云產品中。
用同樣的應用管理平臺同時服務好騰訊內部和外部客戶，與開發者們一起邁入雲原生 2.0 時代。以上是本次分享全部內容，歡迎大家在 [公衆號] 點👉這裏👈進入開發者社區，右邊掃碼即可進入公衆號）評論區分享交流。如果覺得內容有用，歡迎分享轉發～
-End-
原創作者｜王濤
技術責編｜王濤
你怎麼看待雲原生？雲原生未來的發展趨勢是什麼？ 歡迎在 [公衆號] 點👉這裏👈進入開發者社區，右邊掃碼即可進入公衆號）評論區討論。我們將選取1則最有創意的分享，送出騰訊雲開發者-文化衫1個（見下圖）。5月17日中午12點開獎。
點👉這裏👈進入頁面，右邊掃碼關注騰訊雲開發者公衆號，回覆「雲原生」查看鵝廠離線學習包：
7w字騰訊大規模雲原生技術實踐案例集
騰訊雲技術實踐精選集