作者：仔仁、墨封、光南

序言

ASI：Alibaba Serverless infrastructure，阿里巴巴針對云原生應用設計的統一基礎設施。ASI 基于阿里云公共云容器服務 ACK之上，支撐集團應用云原生化和云產品的 Serverless 化的基礎設施平臺。

2021 年天貓雙十一，對于 ASI 來說又是難忘的一年，今年我們又完成了很多“第一次”：

• 第一次全面統一調度：電商、搜索、odps 離線和螞蟻業務全面上 ASI 統一調度架構，整個業務核數達到了驚人的數千萬核。
• 第一次將搜索業務“無感知”平滑遷移到 ASI：近千萬核的業務，業務無感的搬到 ASI（但是我們卻經歷了很多個不眠之夜）。
• ASI 場景的 K8s 單集群規模超過萬臺節點，數百萬核，超越 K8s 社區的 5000 臺規模，不斷優化大規模集群的性能和穩定性。
• 中間件服務第一次用云產品架構支持集團業務：中間件基于 ASI 公共云架構，將中間件服務平滑遷移到云上，用云產品架構支持集團業務，實現“三位一體”。

ASI 在大規模生產應用的錘煉下，不僅沉淀了非常多的 K8s 穩定性運維能力，更是在支持 serverless 場景下孵化了很多創新能力。如果運維過 K8s（特別是運維大規模集群）的同學一定會有很深的感觸：把 K8s 用起來很容易，想要用好 K8s 真心不容易。ASI 在使用 K8s 調度體系架構早期成長階段，也經歷過多次血的教訓，過程中我們持續成長、學習和成熟。例如：

• 一次正常的 Kubernetes 大版本升級流程，在升級 Kubelet 時把一個集群近千臺業務 POD 全部重建；
• 一次線上非標操作，將大批量的 vipserver 服務全部刪除，幸虧中間件有推空保護，才沒有對業務造成災難性影響；
• 節點證書過期，由于節點自愈組件故障情況誤判，并且風控/流控規則判斷也有誤，導致自愈組件誤將一個集群 300+ 節點上的業務全部驅逐；

以上列舉的各種故障場景，即使是專業 K8s 團隊都無法避雷，如果是對 K8s 了解很少的用戶，肯定更無法預防和規避風險。所以，給所有正在使用 K8s 服務，或者想要用 K8s 服務的用戶一個中肯建議：不要想著自己就能運維好 K8s 集群，里面有多少坑你真的想象不到，專業的人做專業的事，讓專業產品和 SRE 團隊來實現運維。在這里，我也是強烈建議用戶使用阿里云容器服務 ACK，因為我們在阿里巴巴大規模場景下沉淀能力增強、自動化運維和能力都會反哺到 ACK 中，幫忙更好的維護用戶的 K8s 集群。

ASI 能運維好這么多龐大 K8s 集群，一定得有“兩把刷子”。今天我會給大家詳細介紹 ASI 在為阿里集團構建云原生基礎設施，和支持阿里云云產品 Serverless 化方面，我們的運維體系和穩定性工程能力。

ASI 技術架構形態

在介紹 ASI 的全托管運維體系之前，我花一點篇幅來介紹一下 ASI。ASI 是基于 ACK、ACR 之上面向集團和云產品的 Serverless 化平臺，旨在支撐阿里巴巴應用云原生化和阿里云產品 Serverless 化。下面介紹容器服務家族的幾位成員：ACK、ASK、ACR。

針對阿里巴巴和云產品業務場景，在 K8s 集群功能層面我們會給用戶提供增強的能力，比如調度能力增強、Workload 能力增強、網絡能力增強、節點彈性能力增強和多租安全架構等等；在集群運維層面，提供 Serverless 化的 No Ops 體驗，比如集群大版本升級、組件升級、節點組件升級、節點 CVE 漏洞修復、節點批量運維等，為用戶的 K8s 集群穩定性兜底。

ASI 全托管運維支撐體系

ASI 為大規模 K8s 集群，提供了全托管、免運維的用戶體驗。這些能力不是 K8s 原生就具備的，而是在大量實踐和失敗過程中沉淀出來的系統穩定性加固能力。而放眼整個行業，正是阿里巴巴的規模化復雜場景，才能錘煉出大規模場景下的 K8s 運維服務體系。

在講 ASI 運維體系之前，我先強調一下在做系統能力建設過程的一個重要原則：不重復造輪子，但是也不能完全依賴其他系統的能力。沒有哪一款產品、系統能 cover 住所有業務的所有問題（特別是 ASI 這樣體量的業務）。依賴上下游鏈路已經建好的系統能力，但是不會完全依賴，要做好系統分層設計。如果一個系統做好了底層的運維通道，我們一定不會再去做一個運維通道，而是會基于上層運維通道做我們自己業務變更的編排；如果一個系統做好了監控、告警鏈路的能力，我們會做好監控、告警規則和路由分發的管理。

另外一件非常重要的事情：做穩定性的團隊要想做好運維管控系統，就一定要對業務架構有非常全面、深入的了解。穩定性團隊不能只做運營，也不能僅僅在架構外面做 1-5-10 能力，這樣是很難把控整個架構的穩定性。ASI SRE 雖然是為 ASI 基礎設施穩定性兜底的團隊，但是很多 SRE 同學都可以獨立去對接新的業務，并能決定整個業務上 ASI 的架構。其實很多時候，如果是 SRE 和研發配合去接的業務方，往往問題都少很多，因為兩個角色非常互補：研發在技術架構上有很好的判斷，SRE 在架構合理性和穩定性風險有很好的判斷。

如上圖是 ASI 集群部署架構，完全基于 ACK 產品 Infra 架構的 KOK（Kube On Kube）底座。整個架構分層為：

• 元集群（KOK 架構底層 K）：用于承載 K8s 業務集群的核心管控組件，將業務集群管控容器化部署，能保證部署方式更加標準，部署效率也會大大提升。
• Control-Plane：就是業務集群核心管控 4 大件：kube-apiserver/kube-controller-manager/kube-scheduler 和 etcd 集群。
• Add-Ons：Serverless 核心功能組件，調度增強組件（統一調度器）、網絡組件、存儲組件、Workload 組件（OpenKruise）、coredns 和其他一些旁路組件。
• Data-Plane：節點管控組件，比如 containerd、kubelet，kata 等，還有一些其他節點上的插件。

基于 ASI 整個架構，我們經過不斷探索、抽象，將 ASI 運維體系，抽象成核心幾大模塊，如下圖所示：

• 統一變更管控：這個是我們從 ASI 的第一天就開始建設的系統能力，因為從阿里巴巴技術發展過程中吸取的經驗教訓來看，很多重大故障都是由于變更不規范、沒評審、沒風險卡點導致；
• 集群運維管控：ACK 會提供 K8s 集群全托管的標準產品能力，但是如何/何時做規模化升級的編排、驗證、監控是我們需要考慮；并且我們還需要建設合理的備容機制，保證集群的穩定性；
• ETCD 運維管控：ETCD 也是完全基于 ACK 的提供的全托管 ETCD Serverless 產品能力，我們會和 ACK 同學一起共建 ETCD 性能優化、備容來更好的服務 ASI 的超大規模集群；
• 組件運維管控：ASI 運維體系非常核心的能力建設，Serverless 全托管服務，最核心的就是各個核心組件都要有相應的研發團隊進行功能擴展和運維支持。這樣如何定義研發同學的研發模式，確保日常運維的穩定性和效率是 ASI 產品能支持大量業務的關鍵。所以在 ASI 成立之初（2019 年支持集團業務上云）我們就建立起了 ASI 組件中心，逐漸定義和優化ASI核心組件的研發、運維模式；
• 節點全托管運維管控：這塊是非常多云產品團隊希望容器服務提供的能力，特別業務產品團隊，他們對基礎設施非常不了解，希望有團隊能幫忙將節點運維全托管掉。節點運維能力也是 ASI 在支撐阿里集團過程中非常重要的能力沉淀，我們也將這部分經驗輸出到售賣區，并繼續不斷優化。云上最大的特點就是資源彈性，ASI 在售賣區也為云產品用戶提供了節點極致彈性能力。
• 1-5-10 能力建設：云上用戶有一個非常重要的特點，對故障容忍度非常低。這也給ASI帶來了非常大的挑戰，如何及時發現、排查和恢復問題，是我們一直要不斷探索的。
• 資源運營：備容，成本優化一直都是基礎設施服務要解的問題，我們既要確保服務運行穩定（比如不 OOM，不出現 CPU 爭搶），又要降低成本，更要降低云產品的服務成本。

接下來我會針對 ASI 全托管運維體系中關鍵系統/技術能力的設計思路和具體方案進行闡述，向大家呈現我們是如何一步步將大規模 K8s 全托管運維服務建設起來的。

集群全托管運維能力

當我們在運維大規模 K8s 集群的時候，最深的感受就是：規模化既會給單個運維操作帶來很大的復雜度，也會將單個運維操作的風險爆炸半徑大大擴大。我們也是經常會被下面的問題挑戰：

• 所有變更是不是都有變更風險管控？
• 這么多的集群，這么多的節點（ASI 單集群已經超過了上萬節點），怎么做灰度穩定性風險最小？
• 黑屏變更無法杜絕，如何把控風險？
• 單個運維動作雖然不難，但是我們經常面臨的是多個運維操作組合的復雜操作，系統如何方便的去編排這些運維操作？

帶著這四個問題，接下來我會詳細介紹，我們如何在實踐中不斷抽象和優化我們的系統能力，并沉淀出目前對 ASI 全托管服務非常重要的穩定性系統能力。

統一變更風險管控

2019 年，當我們剛成立 ASI SRE 團隊的時候，就在探索如何把控變更帶來的風險。當時的穩定性系統能力還非常弱，真的是百廢待興，新的 SRE 團隊的同學都是從阿里云自研的Sigma調度系統各個子研發團隊抽調出來的，所以大家對容器、K8s、etcd 這些技術都非常精通，但是對如何做 SRE，如何做穩定性都是一臉懵。記得剛開始，我們在 ASIOps 系統（當時還叫asi-deploy）里接入 ChangeFree 變更審批都花了 2～3 周的時間。面對新的架構（Sigma -> ASI）、新的場景（集團業務上云）和如此復雜、龐大的 K8s 業務體量，我們也沒有太多外界的經驗可以借鑒。

當時我們想的是靠系統來做變更風險管控肯定是來不及的（集團業務全面上云已經開展起來，大量新的技術方案出來、大量線上變更），只能先靠“人治”。所以我們就在整個 ASI 團隊宣導任何變更都要讓 SRE 審批，但是 SRE 并不能了解 ASI 所有技術架構細節，做完善的風險評估。為此，我們又開始組建“變更評審”會議，在評審會上邀請每一個領域的專家同學參與進行變更方案的風險評審。也是因為這個變更評審機制，幫助 ASI 在變更風險阻斷系統能力非常不足的情況下穩定的渡過了那段“艱難”的時期。ASI 的變更評審會議也一直延續到今天，沒有封網特殊時期，都會如期召開。也是那段時間，SRE 通過參加每一次線上變更的審批，也沉淀了非常多的安全生產規則：

與此同時，我們開始將這些已經非常明確的變更風險阻斷的規則實現到 ASIOps 系統中。剛開始是實現 ASI 底層系統架構層面的風險阻斷能力，后來發現很多變更只通過底層ASI的指標/探測是沒辦法發現問題的，需要有一種機制能聯動上層業務系統來觸發業務層面的一些風險阻斷規則判斷，這樣才能盡可能的確保我們的變更不會對上層業務帶來影響。所以，我們開始在 ASIOps 實現變更風險規則庫的管理，并實現了一種 webhook 的機制，來聯動上層業務方的巡檢檢測/E2E 測試。

ASI 有了這套在線變更風險阻斷系統能力之后，我們再也沒有出現過封網期私自變更，變更不做灰度、不驗證等這類觸犯變更紅線的行為。

變更灰度能力

從實際經驗來看，每一次線上變更，不管我們前期方案評審多么仔細、多么嚴格，風險阻斷做的多么完善，運維功能寫的多好。代碼上線之后，總是會出現我們“意想不到”的情況。對于已經知道的事情，我們一定會做的很好，可怕的是我們考慮不到的事情，這不是能力問題，現實架構他就是足夠復雜。

所以功能上線一定要灰度。當然，我們還要保證變更動作的確定性，不能說張三變更是這樣順序去灰度的，李四同樣的變更又是另外的一個灰度順序。ASI 變更灰度能力，我們也是經過了好多次迭代。

Sigma 時代，集群都是跨機房/跨 Region 部署的，所以如此龐大的業務體量，Sigma 也只需要 10 個不到的集群來承載。對于研發來說，因為集群個數不多，集群做什么用的、業務類型是怎樣的，都很清楚，所以發布成本不是很高（當然，由于爆炸半徑太大，發布小問題也是不斷）。但是演進到 ASI 架構之后，集群規劃是嚴格按照 Region/機房來進行切割的，并且由于 K8s 集群本身可伸縮性問題，無法像 Sigma 集群那樣一個集群能承載十幾萬的節點，K8s 社區當時給的是單集群規模不能超過 5000 節點（雖然現在 ASI 已經優化到單集群上萬節點，但是過大的集群在穩定性與爆炸半徑方面的風險也更高）。在這種架構形態之下，ASI 集群的個數肯定會遠遠大于 Sigma 集群的個數。研發同學都還在 Sigma 后期、ASI 早期時代，很多研發習慣還是沿用 Sigma 當時的模式，發布工具還是 Sigma 時代的產物，沒辦法支持大規模 K8s 集群精細化組件發布。各個團隊的研發每次發布也都膽戰心驚，也怕出問題。

當時，在集團 ASI 集群個數還沒有增長上來之時，我們就已經意識到要去解決變更確定性的問題。ASI 這么多集群，幾十萬的節點，如果讓各個研發同學去決定如何變更肯定是要出問題的。但是，當時我們的系統能力又非常不足，也沒辦法很智能的通過綜合判斷各種條件來為研發同學的變更確定一條最佳的變更灰度順序。那怎么辦呢？系統不牛逼，但是也得要解決問題啊。所以我們提出了一個 pipeline 的概念：由 SRE 主導和核心研發TL一起確定線上核心集群的發布順序，定義為一條 pipeline，然后所有研發在做組件升級的時候，必須要綁定這條 pipeline，發布的時候，就可以按照我們規定好的集群順序來進行灰度發布了，這就是 pipeline 概念的由來。這一個“看起來很 low”的功能，在當時消耗了我們非常大的精力投入才做出一個初版。不過，當我們“滿懷信心”把 pipeline 推廣給研發同學用的時候，卻沒有收到我們想象中的“鮮花和掌聲”，而是很多“吐槽和優化建議”。所以我們改變推廣策略：逐步小范圍推廣、逐步修正、然后大范圍推廣，直到大家完全接受。現在 pipeline 已經成為了 ASI 研發同學必不可少的發布工具了。現在想起來，也覺得蠻有意思的。也讓我們明白一個道理：任何新的功能不能“閉門造車”，一定要從我們的用戶角度出發來進行設計、優化，只有用戶滿意，才能證明我們系統/產品的價值。

下圖就是我們按照測試->小流量->日常->生產這個順序，為研發定義的集團核心交易集群的發布順序：

靜態 pipeline 編排 ASI 集群順序的能力，在當時只支持集團為數不多的 ASI 集群時，問題還不大。但是當 ASI 業務擴展到了阿里云云產品之后，特別是我們和 Flink 產品一起孵化出了 ASI 硬多租 VC 架構之后，一個用戶一個小的集群，集群數量陡增，這種人工編排集群順序就暴露很多問題了：

• 更新不及時：新增了一個集群，但是沒有通知相關同學，沒有加到對應的 pipeline；
• 自動適配能力不夠：ASI 新接入了一個云產品，需要人工新加一條 pipeline，經常更新不及時；
• 維護成本高：隨著業務越來越多，各個研發 owner 要自己維護非常多條 pipeline；
• 擴展能力不足：pipeline 順序不能動態調整，ASI 支持云產品之后，有一個非常重要的需求就是按照 GC 等級進行灰度，靜態 pipeline 完全無法支持。

基于上述靜態 pipeline 總總不足，我們也是早就開始了技術方案的優化思考和探索。ASI核心是資源調度，我們的調度能力是非常強的，特別是現在集團做的統一調度項目，將集團電商業務、搜索業務、離線業務和螞蟻業務，全部用統一的調度協議上了 ASI。我就在想，ASI 統一調度器是資源 cpu、memory 的調度，集群信息、Node 數量、Pod 數量、用戶 GC 信息也都是“資源”，為什么我們不能用調度的思想去解決ASI集群灰度順序編排的問題呢？所以，我們參考了調度器的設計實現了 Cluster-Scheduler，將集群的各種信息整合起來，進行打分、排序，得出一條集群 pipeline，然后提供給研發同學來進行灰度發布。

Cluster-Scheduler 實現了一種“動態”pipeline 的能力，能很好的解決靜態 pipeline 碰到的各種問題：

• 組件灰度發布的時候，通過 Cluster-Scheduler 篩選的集群范圍肯定不會漏集群；
• 集群發布順序按照 GC 等級來進行權重設置，也能根據集群的規模數據來動態調整集群的權重；
• 研發發布的時候，不需要再維護多條靜態 pipeline，只需要選擇組件發布范圍，會自動進行集群發布順序編排。

當然靜態 pipeline 有一個很大的優點：集群發布順序可以自助編排，在一些新功能上線場景中，研發需要有這種自助編排能力。所以未來我們也是靜態/動態 pipeline 一起配合使用，互相補充。

集群webshell工具

SRE 在做穩定性風險把控的時候，一定是希望所有的變更都是白屏化和在線化。但是從我們運維 K8s 的實際情況來看，沒辦法將所有的運維操作都白屏化來實現。我們又不能直接將集群證書提供給研發同學：一是會存在權限泄漏安全風險，；二是研發在本地用證書操作集群，行為不可控，風險不可控。ASI 初期也出現過多次在本地用 kubectl 工具誤刪除業務 Pod 的行為。雖然我們無法將 K8s 所有運維操作都白屏化在系統上提供給研發使用，但是我們可以將 kubectl 工具在線化提供給研發來使用，然后基于在線化工具提供穩定性、安全性加固、風控等能力。

所以，我們在 Ops 系統里提供了集群登陸工具 webshell，研發可以先按“最小可用”原則申請集群資源訪問權限，然后通過 webshell 中去訪問集群進行相應的運維操作。在的 webshell 中我們會將用戶的所有操作記錄下來，上傳到審計中心。

在線 webshell，對比用戶本地證書訪問集群，我們做了非常多的安全/穩定性加固：

• 權限精細化管控：權限與用戶綁定，有效期、權限范圍嚴格管控；
• 安全：不會給用戶提供證書，所以不會出現證書泄漏的問題；
• 審計：所有操作都有審計；
• 風控：檢測危險操作，發起在線審批之后再運行操作。

變更編排能力

前面講的風險阻斷、變更灰度和黑屏變更收斂，都是在解決 ASI 穩定性問題。但是，誰又能幫助解決我們 SRE 同學面臨的挑戰呢？

做穩定性的同學都知道：只有將變更白屏化/在線化之后，我們才能對這些變更中心化管控，把控變更風險。但是對于 ASI 這種非常龐大復雜的基礎設施服務來說，變更場景繁多、復雜。我們 SRE 負責整個 ASIOps 運維管控平臺的建設，既要面對每天繁重的運維工作，還要建系統，更要命的是我們的同學都是后端開發工程師出身，Ops 系統需要做前端界面，寫前端是后端工程師的夢魘，經常是一個后端功能 1h 寫完，前端頁面要畫至少一天。

SRE 團隊是一個技術服務團隊，不僅僅要讓我們的服務方滿意，更要讓我們自己滿意。所以，我們在搞系統能力建設的過程中，一直在探索怎么降低運維系統開發的成本。大家應該也知道，運維能力和業務系統能力不同，運維操作更多是多個操作編排起來的一個綜合操作，比如解決線上 ECS 上 ENI 網卡清理的問題，完整的運維能力是：首先在節點上執行一個掃描腳本，將泄漏的 ENI 網卡掃描出來；然后是將掃描出來的泄漏的 ENI 網卡作為入參傳給清理 ENI 網卡的程序；最后 ENI 網卡清理完成，上報相應的狀態。所以，我們當時就想做一個事情：實現一套運維操作編排引擎，能快速的將多個單個獨立的運維操作編排起來實現復雜的運維邏輯。當時我們也調研了很多編排工具比如 tekton、argo 這類的開源項目。發現要么是項目 PR 的非常好，但是功能還是太基本，沒辦法滿足我們的場景；要么就是在設計上更多的是適用于業務場景，對于我們這種底層基礎設施非常不友好。

所以，我們決定取現在已有編排工具的精華，參考他們的設計，實現 ASI 自己的一套運維編排引擎工具。這就是 ASIOps 中 Taskflow 編排引擎的由來，架構設計如下圖所示：

• PipelineController：維護任務間的依賴信息
• TaskController：任務狀態信息維護
• TaskScheduler：任務調度
• Task/Worker：任務執行

舉一個節點擴容功能的例子，如果是單獨實現一套節點全生命周期管理的功能，所有的操作功能都要自己寫。但是在使用了 Taskflow 編排能力之后，只需要實現 3 個 executor（執行器）邏輯：Ess 擴容、節點初始化、節點導入。Taskflow 會將這 3 個 executor 執行流串聯起來，完成一次節點擴容操作。

目前 Taskflow 這套編排引擎在 ASIOps 內被廣泛使用，覆蓋了診斷、預案、節點導入導出、VC 集群開服、一次性運維、發布等場景，也大大提升了新的運維場景系統能力開發的效率。

經過兩年多的鍛煉，SRE 團隊的核心研發同學基本都是“全棧工程師”（精通前、后端研發）。特別是前端界面研發，現在不僅沒有成為我們團隊的負擔，相反成為了我們團隊的優勢。很多系統能力都需要前端界面暴露給用戶來使用，而在 ASI 這個絕大部分研發都是后端工程師的團隊，SRE 團隊前端開發資源成為了我們非常重要的“競爭力”。也充分證明了：技多不壓身。

小結

關于 ASI 集群全托管運維能力，我這邊核心介紹了在系統能力實現上是如何做變更風險阻斷、變更編排、變更灰度和收斂黑屏變更。當然，我們在 ASI 管控全托管層面做的遠遠不止這些系統能力，還有非常多次的架構升級的大型線上變更，正是因為我們有如此多場景積累，才能沉淀出很多重要的系統能力。

組件全托管運維能力

關于 ASI 組件全托管能力，我們之前已經發表過一篇文章進行詳細介紹：ASI 組件灰度體系建設，大家有興趣可以詳細看一下，確實在 ASI 如此大規模場景下，才會有的技術和經驗的沉淀。所以我這里就不做過多的技術方案的介紹，更多是介紹我們技術演進的過程。ASI 在組件灰度能力建設的分享，也入選了 2020 年 KubeCon topic：《How we Manage our Widely Varied Kubernetes Infrastructures in Alibaba》，感興趣的同學可以去找一下相關的視頻。

ASI 全托管模式下組件全托管能力是和目前半托管容器服務云產品一個非常重要的區別：ASI 會負責 K8s 集群中核心組件維護工作（研發、問題排查和運維）。這個其實也是和 ASI 起源有關，ASI 起源于集體業務全面上云時期，我們提供一個大集群+公共資源池的模式讓業務逐漸從 Sigma 架構遷移上 ASI。對于集團業務來說，肯定不會去維護 K8s 集群以及集群里的各種組件，所以這塊就完全由 ASI 團隊來負責，也讓 ASI 逐漸孵化出了組件全托管的系統能力。

如上圖，ASI 整個架構的各種層面的組件現在都是基于 ASIOps 進行統一的變更灰度編排管理。其實，在現在看來 ASI 的所有組件放在一個平臺來維護，并且統一來進行灰度能力建設是非常理所當然的事情。但是，在當時我們也是經過了非常長時間的“斗爭”，才讓今天的架構變得如此合理。在多次激烈的探討和各種來自穩定性的壓力背景下，我們終于探索出了一個比較符合目前 K8s 架構的頂層設計：

• IaC 組件模型：利用 K8s 聲明式的設計，來將所有 ASI 組件類型的變更全部改為面向終態的設計；
• 統一變更編排：組件變更最重要的是灰度，灰度最重要的是集群/節點灰度順序，所有組件都需要變更灰度編排；
• 組件云原生改造：原來節點基于天基的包變更管理改造成 K8s 原生 Operator 面向終態的設計，這樣節點組件實現基本的組件變更通道、分批、暫停等能力。由上層的 Ops 系統來實現組件版本管理、灰度變更編排等。

經過兩年多的發展，ASI 體系下組件變更也完全統一在一個平臺下，并且基于云原生的能力也建設出了非常完善的灰度能力：

節點全托管運維能力

前面我也介紹了，我們在建設系統能力時不會重復造輪子，但是也不能完全依賴其他產品的能力。ACK 提供了節點生命周期管理的基本產品能力，而 ASI 作為 ACK 之上的 Serverless 平臺，需要在 ACK 基本產品能力之上，建設規模化運維能力。從 Sigma 時代到ASI支持集團超大統一調度集群過程中，ASI 沉淀了非常多規模化運維節點的能力和經驗。接下來介紹一下我們在售賣區如何建設節點全托管能力建設起來。

節點全生命周期定義

要建設比較完善的節點全托管運維能力，我們首先要梳理清楚節點全生命周期的每一個階段需要做哪些事情，如下圖我們將節點全生命周期大致分為 5 個階段：

• 節點生產前：售賣區比較復雜的場景是每一個云產品都有一套或多套資源賬號，還有很多需要自定義 ECS 鏡像。這些都需要在新業務接入時進行詳細定義；
• 節點導入時：集群節點導入時需要建設節點創建/擴容/導入/下線等操作；
• 節點運行時：節點運行時往往是問題最多的階段，這塊也是需要重點能力建設的階段，如節點組件升級、批量執行腳本能力、cve 漏洞修復，節點巡檢、自愈能力等等；
• 節點下線時：在節點成本優化、內核 cve 漏洞修復等場景下，都會需要節點騰挪、下線等規模化節點運維能力；
• 節點故障時：在節點故障時，我們需要有節點問題快速探測能力、問題診斷能力和節點自愈能力等。

節點能力建設大圖

ASI 售賣區節點托管能力建設 1 年多，已經承載了售賣區所有上 ASI 的云產品，并且大部分核心能力都已經建設比較完善，節點自愈能力我們也在不斷優化完善中。

節點彈性

在云上一個最大的特點就是資源彈性，節點彈性能力也是售賣區 ASI 給云產品用戶提供的一個非常重要的能力。ASI 的節點彈性能力依靠 ECS 資源的極致彈性，能按照分鐘級來進行 ECS 資源購買和釋放，幫忙云產品精細化控制資源成本。視頻云云產品目前就在 ASI 上重度依賴 ASI 節點彈性能力，進行資源成本控制。視頻云平均一天節點彈性 3000 多次，并且經過不斷優化，ASI 節點彈性能達到幾分鐘內完全拉起視頻云業務。

在節點彈性上，我們在節點整個生命周期中都進行了性能優化：

• 管控層面：通過控制并發度，可以快速完成幾百臺 ECS 的彈性任務處理；
• 組件部署優化：
• • daemonset 組件全部修改為走 Region vpc 內部地址拉取；
  • rpm 組件采用 ECS 鏡像內預裝模式，并進行節點組件部署序編排來提升節點組件安裝速度；
  • 最后就是 yum 源帶寬優化，從原來走共享帶寬轉為獨占帶寬模式，避免被其他 rpm 下載任務影響我們節點初始化。
• 業務初始化：引入 dadi 鏡像預熱技術，節點導入過程中可以快速預熱業務鏡像，目前能達到 10g 大小鏡像的業務拉起只需要 3min 左右。

1-5-10 能力建設

ASI 全托管模式的服務，最重要的還是我們能為云產品用戶進行底層集群穩定性問題進行兜底。這個對 ASI 的 1-5-10 能力要求就非常高，接下來主要給大家介紹 3 個核心穩定性能力：

• 風控：在任何場景下，ASI 都應該具備踩剎車的能力；
• KubeProbe：快速探測集群核心鏈路穩定性問題；
• 自愈：龐大的節點規模，非常依賴節點自愈能力。

風控

在任何時刻，ASI 一定要有“踩剎車”的能力，不管是我們自己同學誤操作，還是上層業務方誤操作，系統必須有及時止損的能力。在文章開頭，我也介紹了 ASI 曾經發生過的大規模重啟、誤刪 pod 的事故。正因為之前血淚教訓，才造就了我們很多風控能力的誕生。

• KubeDefender 限流：對一些核心資源，比如 pod、service、node，的操作（特別是 Delete 操作）按照 1m、5m、1h 和 24h 這樣的時間維度設置操作令牌。如果令牌消耗完就會觸發熔斷。
• UA 限流：按時間維度設置某一些服務（UserAgent 來標識）操作某一些資源的QPS，防止訪問 apiserver 過于頻繁，影響集群穩定性。UA 限流能力是 ACK 產品增強能力。
• APF 限流：考慮 apiserver 的請求優先級和公平性，避免在請求量過大時，有一些重要控制器的被餓死。K8s 原生增強能力。

KubeProbe

KubeProbe 是 ASI 巡檢/診斷平臺，經過不斷迭代，目前我們演進了兩種架構：中心架構和 Operator 常駐架構。KubeProbe 也中了今年上海 KubeCon 議題，感興趣的同學，到時候也可以參加一下上海 KubeCon 線上會議。

1）中心架構

我們會有一套中心管控系統。用戶的用例會通過統一倉庫的鏡像的方式接入，使用我們通用的 sdk 庫，自定義巡檢和探測邏輯。我們會在中心管控系統上配置好集群和用例的關系配置，如某用例應該執行在哪些集群組上，并做好各種運行時配置。我們支持了周期觸發/手動觸發/事件觸發(如發布)的用例觸發方式。用例觸發后會在集群內創建一個執行巡檢/探測邏輯的 Pod，這個 Pod 里會執行各種用戶自定義的業務巡檢/探測邏輯，并在成功和失敗后通過直接回調/消息隊列的方式通知中心端。中心端會負責告警和用例資源清理的工作。

2）常駐 Operator 架構

對于某些需要 724 小時不間斷的高頻短周期探測用例，我們還實現了另外一套常駐分布式架構，這套架構使用一個集群內的 ProbeOperator 監聽 probe config cr 變化，在探測pod中周而復始的執行探測邏輯。這套架構，完美復用了 KubeProbe 中心端提供的告警/根因分析/發布阻斷等等附加功能，同時使用了標準 Operator 的云原生架構設計，常駐體系帶來了極大的探測頻率提升(因為去掉了創建巡檢 Pod 和清理數據的開銷)基本可以做到對集群的 724 小時無縫覆蓋，同時便于對外集成。

另外還有一個必須要提的非常重要的點，那就是平臺只是提供了一個平臺層的能力支持，真正這個東西要起作用，還是要看在這個平臺上構建的用例是否豐富，能不能方便的讓更多人進來寫各種巡檢和探測用例。就像測試平臺很重要，但測試用例更重要這個道理一樣。一些通用的 workload 探測，組件探測，固然能發現很多管控鏈路上的問題，但是更多的問題，甚至業務層的問題暴露，依賴于基礎設施和業務層同學的共同努力。從我們的實踐上來說，測試同學和業務同學貢獻了很多相關的檢查用例，比如 ACK&ASK 的創建刪除全鏈路探測巡檢，金絲雀業務全鏈路擴容用例，比如本地生活同學的 PaaS 平臺應用檢查等等，也得到了很多穩定性上的結果和收益。目前巡檢/探測用例有數十個，明年有機會破百，巡檢/探測次數近 3000 萬次，明年可能會過億。可以提前發現 99% 以上的集群管控問題和隱患，效果非常好的。

自愈

當我們的業務規模達到一定規模，如果僅僅靠 SRE 團隊線上 Oncall 去解決問題肯定是遠遠不夠的，一定需要我們系統具備非常強的自愈能力。K8s 面向終態的設計，通過 Readiness、Liveness 機制能幫忙業務 Pod 快速自愈。但是當節點故障時，我們也需要節點能快速自愈，或者能快速將節點上的業務驅逐到正常的節點上。ACK 產品也提供了自愈能力，ASI 在這個之上做了很多基于 ASI 業務場景的能力增強。如下是我們售賣區節點自愈能力的架構設計：

隨著 ASI 業務形態的發展，未來我們將在如下場景下進行節點自愈能力增強：

• 診斷、自愈規則更加豐富：目前的診斷、自愈規則很多場景下都沒有覆蓋，需要不斷優化覆蓋，更多節點故障場景；
• 基于節點池的精細化的自愈風控、流控：節點自愈的前提是不能讓現狀變的更糟，所以我們需要在做自愈時，做更加精確的判斷；
• 節點自愈能力與上層業務打通：不同業務形態，對節點自愈的要求不同。比如Flink業務都是任務類型，遇到節點問題需要我們盡快驅逐業務，觸發任務重建，最怕的就是任務“半死不活”；中間件/數據庫業務都是有狀態服務，不允許我們隨便驅逐業務，但是我們如果把自愈能力與上層業務邏輯打通，就可以做到將節點故障上透給業務，讓業務來決策是否要自愈，以及業務如何自愈。

展望未來

ASI 作為容器服務 ACK 在阿里巴巴內部持續打磨的統一Serverless 基礎設施，正在持續構建更強大的全自動駕駛 K8s 集群，提供集群、節點、組件的全托管能力，并一如既往地輸出更多經驗到整個行業。ASI 作為阿里集團、阿里云基礎設施底座，為越來越多的云產品提供更多專業服務，托管底層 K8s 集群，屏蔽復雜的 K8s 門檻、透明幾乎所有的基礎設施復雜度，并用專業的產品技術能力兜底穩定性，讓云產品只需要負責自己的業務，專業的平臺分工做專業的事。

點擊??此處??，前往云原生子社區查看更多內容！

總結

以上是生活随笔為你收集整理的阿里巴巴超大规模 Kubernetes 基础设施运维体系的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。