01 引言
2023 年 7 月，阿里雲容器服務 ACK 成爲首批通過中國信通院“雲服務穩定運行能力-容器集羣穩定性”評估的產品， 並榮獲“先進級”認證。隨着 ACK 在生產環境中的採用率越來越高，穩定性保障已成爲基本訴求。本文基於 ACK 穩定性保障實踐經驗，幫助用戶全面理解 ACK 穩定性理論和優化策略，並瞭解如何使用相應的工具和服務進行穩定性保障。
02 K8s 集羣穩定性和大規模場景下的挑戰
K8s 常見的穩定性痛點
Kubernetes 在提供豐富的技術和功能外，架構和運維具有較高的複雜性，也產生了諸多的痛點。
痛點 1：在發佈、彈性等高峯期，集羣控制面服務時斷時續，甚至完全不可用
面對大流量請求，如果控制面沒有自動彈性擴容能力，會無法對負載自適應、導致控制面服務不可用。
例如：客戶端存在高頻度持續 LIST 集羣中的大量資源，集羣 apiserver/etcd 無法自動彈性就可能聯動出現 OOM。
ACK Pro 託管版 K8s 可以對控制面組件根據負載壓力做 HPA 和 VPA，可以有效解決該痛點。
痛點 2：集羣節點批量 NotReady 導致雪崩，嚴重影響業務！
部分節點出現 NotReady，節點上 Pod 被驅逐調度到健康節點，健康節點由於壓力過大也變爲 NotReady，加劇產生了更多 NotReady 的節點，業務持續重啓。
ACK 提供了託管節點池功能，可以對出現 NotReady 的異常節點治癒，重新拉會 Ready 狀態，可以有效解決該痛點。
痛點 3：業務高峯期需快速彈性，節點上拉取 Pod 鏡像耗時長達分鐘級，影響業務
節點上 kubelet 併發拉取鏡像遇到網絡帶寬限制，需要鏡像加速功能支持。
ACR 提供了基於 DADI（Data Accelerator for Disaggregated Infrastructure）的按需鏡像加載和 P2P 鏡像加速的功能，可以加速鏡像拉取，可以有效解決該痛點。
痛點 4：Master 節點/組件運維複雜度高，包含資源配置、參數調優、升級管理等
需要大量的線上場景分析和優化、故障處理、規模壓測等，來分析、整理並落地最佳實踐和配置。
ACK Pro 託管版 K8s 在全網的規模體量上萬集羣，具有自動彈性和生命週期管理的運維管理架構，有豐富的優化、應急處理等經驗，持續將最佳實踐和參數優化對託管組件升級。
Kubernetes 集羣架構
既然有這些痛點，我們從 K8s 架構的角度來分解一下，看看哪些部分可能出現故障和問題：雲上 K8s 集羣包含控制面、數據面、以及承載控制面和數據面的的雲資源。控制面和數據面通過 SLB 和雲網絡連接。
控制面負責集羣的 API 層、調度、資源管理、雲資源管理等控制面功能，K8s 組件：apiserver/etcd/scheduler/kube-controller-manger/cloud-controller-manager。
數據面負責集羣的節點管理、Pod 生命週期管理、Service 實現等數據面功能，承載業務Pod的主體。包含：K8s 組件，kubelet/kube-proxy；系統組件，日誌、監控、安全等組件；其他組件，用戶業務組件。
控制面、數據面和雲資源是有機結合的整體！集羣的全鏈路中，任何一個組件、子鏈路成爲瓶頸，都可能影響到集羣的整體穩定性。
我們需要從 K8s 系統中發現瓶頸、治理以及優化瓶頸，最終實現 K8s 系統在給定雲資源情況下的穩定、高效的利用。
Kubernetes 穩定性體現
我們已經瞭解了 K8s 集羣架構，那麼如何評估 K8s 集羣的穩定性呢？
集羣穩定性涵蓋 Kubernetes 服務可用性、處理時延、請求 QPS 和流量吞吐、資源水位等要素。
Kubernetes 穩定性風險和挑戰
結合剛纔介紹的 K8s 的架構和穩定性體現，我們來看看 K8s 集羣的穩定性風險和挑戰，在大規模場景下穩定性風險和挑戰會更加突出。
挑戰 1：集羣內資源種類繁多，數量巨大
大規模集羣場景下常見。包含原生 K8s 資源和豐富靈活的 CRD 資源。節點是 K8s 的一種資源，節點規模大的集羣是大規模集羣的一種；從 K8s 治理的角度，集羣中某種資源數量巨大，例如 configmap、secrets 等，即便節點數不大，也可以稱爲大規模集羣。
例如：單集羣超過 1 萬節點規模、單集羣有 10W+ 的 namespace 以及 ns 下 secret/configmap 資源。
挑戰 2：控制面壓力的風險
控制面組件緩存集羣的部分或者全部資源。在大規模場景下，每個組件都會有明顯的資源壓力。超過資源 Limits 就會觸發 OOM 等問題。例如 apiserver 將 etcd 中全部資源在內存中緩存以便響應客戶端對 Cache 的 LIST 請求。
請求來源複雜。包括隨節點規模正增長的 kubelet/kube-proxy/daemonset，也包括系統組件和用戶部署的組件。
挑戰 3：數據面壓力、以及數據面與控制面同步壓力的風險
數據面節點出現壓力以及異常。節點負載壓力過高，導致 kubelet/運行時響應慢或者無響應，甚至節點狀態 NotReady。數據面與控制面同步瓶頸。
數據面與控制面網絡帶寬打滿或者網絡不通，kubelet 無法及時更新 node 狀態，導致節點狀態 NotReady，導致容器調度、service 後端流量轉發受影響。
挑戰 4：雲資源穩定性和高可用穩定性
有限的雲資源容量。例如 SLB 的連接數、帶寬，ECS 的內存、CPU 等等，存在打滿的風險。
集羣的核心雲資源和組件需要按高可用架構部署。包括跨節點、AZ 等不同高可用等級。
03 ACK 穩定性治理和優化策略
ACK K8s 穩定性概述
2023 年 7 月，ACK 成爲首批通過中國信通院“雲服務穩定運行能力-容器集羣穩定性”評估的產品，並榮獲“先進級”認證。
ACK K8s 穩定性優化，源於大規模實踐經驗沉澱，具體包括：ACK 全網管理了數萬個 K8s 集羣，對線上豐富的客戶和業務場景提供全面的支持；ACK 作爲底座承載了雙十一、618 等超大規模的電商業務，經受住了阿里巴巴電商場景的極限壓力的考驗；對社區原生 K8s 做參數、性能、架構等優化，並形成產品能力。
ACK 針對豐富的業務類型和大規模場景進行優化，例如：
- 雲上的大規模化場景，支持單集羣上萬節點
- Sark/Flink 等大數據場景
- Tensforflow/Pytorch 等 AI 場景
- ECI/Spot 等快速彈性場景
- ArgoWorkflow 等任務流場景
ACK 集羣穩定性治理關鍵點
1. 高可用架構
控制面全面按高可用架構部署。
數據面提供豐富的高可用產品能力和配置，便於用戶提升集羣的高可用性。
2. K8s 優化
包括 APIServer/Etcd/KCM/Scheduler/Kubelet/Kube-proxy 等組件的優化、參數配置等。
3. 集羣容量規劃和自動彈性
例如：規範 LIST 請求使用、優先使用 Informer 機制、優先使用 PB 協議等等。
4. 系統組件、用戶組件優化
控制面託管組件支持根據請求負載自動彈性擴縮容，控制面可觀測對用戶透出。
數據面提供豐富的集羣、節點、工作負載、Ingress 等監控告警。
5. 質量巡檢、故障演練、壓測體系
ACK 組件和集羣自動化巡檢、定期進行的故障演練和應急預案恢復驗證、高效的壓測體系。
6. 數據面優化
節點自動運維和自愈能力，鏡像加速和 P2P 傳輸。
下面針對部分優化關鍵點詳細展開說明。
高可用架構
控制面實現可用區級別高可用 全部控制面組件實現與阿里雲 ECS 的可用區能力對齊的高可用打散。
以 APIServer 爲例，多副本跨 AZ、跨節點高可用部署方式，任何一個 AZ 失效不影響服務可用性。在 3AZ 地域，ACK 託管集羣控制面的 SLA 是 99.95%。對於不具備 3AZ 的地域，ACK 託管集羣控制面 SLA 是 99.5%（不具備單可用區的故障容忍）。
控制面實現可用區級別高可用全部控制面組件實現與阿里雲 ECS 的可用區能力對齊的高可用打散。以 APIServer 爲例，多副本跨 AZ、跨節點高可用部署方式，任何一個 AZ 失效不影響服務可用性。在 3AZ 地域，ACK 託管集羣控制面的 SLA 是 99.95%。對於不具備 3AZ 的地域，ACK 託管集羣控制面 SLA 是 99.5%（不具備單可用區的故障容忍）。
數據面支持客戶配置豐富的高可用策略。
對於 Pod，支持基於節點、部署集、AZ 等不同故障域，結合 K8s 調度中的拓撲分佈約束（Topology Spread Constraints），實現不同等級的高可用策略；雲盤、負載均衡、虛機節點等雲資源均支持 K8s 場景下按多 AZ 打散配置。
在分析 APIServer 優化前，先來看一下 K8s API 請求的分析。
這裏的結論爲：不帶 ResourceVersion 的 LIST 請求，請求會擊穿到 etcd 和 apiserver，對系統壓力最大，如果使用 labelSelector/fieldSelector 只能在 apiserver 內存中過濾，不會減少對 etcd 壓力；informer 通過 LIST + WATCH 的請求組合，最大化降低對控制面 apiserver 和 etcd 的壓力，是推薦的機制。
APIServer 穩定性優化
1. APIServer 自動彈性
ACK 管控基於訪問壓力和集羣容量實現 APIServer 實例自動彈性。
2. 軟負載均衡
方法：負載不均會導致個別 APIServer 實例資源開銷大、容易觸發 OOM。Goaway 特性概率性斷開並新建 TCP 連接， 實現負載均衡的效果。作用：幫助穩定運行的集羣能解決負載不均衡問題。
3. 託管組件可觀測性透出
全部託管組件 apiserver、etcd 等監控告警對用戶透出。支持識別可能存在的非規範 LIST 請求的 Grafana 看板，幫助用戶評估組件行爲。
4. 集羣資源清理 關閉不需要功能
及時清理不使用的 Kubernetes 資源，例如 configmap、secret、pvc 等；及時清理不使用的 Kubernetes 資源，例如 configmap、secret、pvc 等。
Etcd 穩定性優化
1. Data 和 Event etcd 分拆
Data 和 Event 存放到不同的 etcd 集羣。數據和事件流量分離，消除事件流量對數據流量的影響；降低了單個 etcd 集羣中存儲的數據總量，提高了擴展性。
2. Etcd 根據資源畫像 VPA
根據 Etcd 資源使用量，動態調整 etcd Pod request/limits，減少 OOM。
3. AutoDefrag
operator 監控 etcd 集羣 db 使用情況，自動觸發 defrag 清理 db，降低 db 大小，提升查詢速度。
Scheduler/KCM/CCM 穩定性優化
QPS/Burst 參數調優。KCM/Scheduler/CCM 的 QPS/Burst 參數在規模化場景下需要提升，避免核心組件出現客戶端限流；同時觀測 APIServer 監控，避免 APIServer 對核心組件限流。
組件穩定性優化
1. 規範組件 LIST 請求
必須使用全量 LIST 時添加 resourceVersion=0，從 APIServer cache 讀取數據，避免一次請求訪問全量擊穿到 etcd；從 etcd 讀取大量數據，需要基於 limit 使用分頁訪問。加快訪問速度，降低對控制面壓力。
2. 序列化編碼方式統一
對非 CRD 資源的 API 序列化協議不使用 JSON，統一使用 Protobuf，相比於 JSON 更節省傳輸流量。
3. 優選使用 Informer 機制
大規模場景下，頻繁 LIST 大量資源會對管控面 APIServer 和 etcd 產生顯著壓力。頻繁 LIST 的組件需要切換使用 Informer 機制。基於 Informer 的 LIST+WATCH 機制優雅的訪問控制面，提升訪問速度，降低對控制面壓力。
4. 客戶端訪問資源頻度
客戶端控制訪問大規模全量資源的頻度，降低對管控的資源和帶寬壓力。
5. 對 APIServer 訪問的中繼方案
大規模場景下，對於 Daemonset、ECI pod 等對 APIServer 進行訪問的場景，可以設計可橫向擴容的中繼組件，由中繼組件統一訪問 APIServer，其他組件從中繼組件獲取數據。例如 ACK 的系統組件 poseidon 在 ECI 場景下作爲 networkpolicy 中繼使用。降低管控的資源和帶寬壓力，提升穩定性。
04 ACK 穩定性產品功能和最佳實踐器
針對剛纔提到的 K8s 穩定性風險和挑戰，我們看一下 ACK 是如何進行穩定性治理和優化的。ACK 提供了高效豐富的穩定性產品功能，這裏着重從可觀測性、故障預防與定位、自動化節點運維角度來介紹產品功能，對應的產品功能分別是：
- Prometheus for ACK Pro
- 容器 AIOps 套件
- 託管節點池
幫助客戶提升透明可觀測、風險可預測、故障可定位、運維自動化的穩定性保障。
Prometheus for ACK Pro
在透明可觀測方面，ACK 支持從應用層、APM 層、K8s 層到基礎設施層的全景可觀測。PrometheusforACKPro 結合容器服務最佳實踐經驗，提供了可以關聯分析、可交互的大盤。
例如：
- 全局資源總覽、節點總覽
- K8s核心託管組件的監控，例如 apiserver，etcd 等等
- 集羣事件分析
- 在節點層結合 eBPF 實現了無侵入式應用監測
基於 ACKPrometheusforACKPro，可以全面覆蓋數據面和控制面的可觀測性。
容器 AIOps 套件-故障預防與定位
在智能運維方面，ACK 的容器 AIOps 套件憑藉 10 年大規模容器運維經驗沉澱，自動化診斷能力能夠覆蓋 90% 的運維問題。
基於專家系統+大模型，AIOps 套件提供全棧巡檢、集羣檢查、智能診斷三大功能。
- 全棧巡檢，定位集羣風險巡檢。可以掃描集羣健康度和潛在風險，例如雲資源配額餘量、K8s 集羣關鍵資源水位，並提供修復的解決方案。
- 集羣檢查，定位運維操作前的檢查。例如企業在業務升級過程中經常遇到的K8s版本較老，基於各種顧慮不敢升級的問題，阿里雲 ACK 可以自動識別出應用是否在使用 K8s 老版本廢棄的 API、集羣資源是否足夠，幫助企業規避升級過程中遇到的風險。
- 智能診斷，定位診斷 K8s 問題。可以診斷異常的 Pod，Node，Ingress，Service，網絡和內存。
託管節點池
在節點自動化運維方面，託管節點池是 ACK 面向數據面提供的產品功能。定位是讓用戶專注上層應用部署，ACK 負責節點池基礎運維管理。
支持自升級、自愈、安全修復、極速彈性四大功能。
- 自升級是指自動升級 kubelet 和節點組件。
- 自愈是指自動修復運行時和內核問題。例如發現 NotReady 的節點，並治癒恢復爲 Ready 狀態。
- 安全修復是指支持 CVE 修復和內核加固。
- 極速彈性是基於 ContainerOS 以及通用 OS 的快速彈性。P90 統計算法下，完成 1000 節點擴容只需要 55s。
05 展望
ACK 穩定性保障建設會持續演進，會繼續爲客戶提供安全、穩定、性能、成本持續優化的產品和穩定性保障！
作者：賢維 馬建波 古九 五花 劉佳旭
本文爲阿里雲原創內容，未經允許不得轉載。