​簡介：ASI 作為阿里集團、阿里雲基礎設施底座，為越來越多的雲產品提供更多專業服務，託管底層 K8s 叢集，遮蔽複雜的 K8s 門檻、透明幾乎所有的基礎設施複雜度，並用專業的產品技術能力兜底穩定性，讓雲產品只需要負責自己的業務，專業的平臺分工做專業的事。

作者：仔仁、墨封、光南

序言

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 在架構合理性和穩定性風險有很好的判斷。

​

• 元叢集（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 通過參加每一次線上變更的審批，也沉澱了非常多的安全生產規則：

​

​

​

變更灰度能力

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

所以功能上線一定要灰度。當然，我們還要保證變更動作的確定性，不能說張三變更是這樣順序去灰度的，李四同樣的變更又是另外的一個灰度順序。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 新接入了一個雲產品，需要人工新加一條 pipeline，經常更新不及時；
• 維護成本高：隨著業務越來越多，各個研發 owner 要自己維護非常多條 pipeline；
• 擴充套件能力不足：pipeline 順序不能動態調整，ASI 支援雲產品之後，有一個非常重要的需求就是按照 GC 等級進行灰度，靜態 pipeline 完全無法支援。

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

​

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

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

叢集webshell工具

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

所以，我們在 Ops 系統裡提供了叢集登陸工具 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 執行流串聯起來，完成一次節點擴容操作。

​

經過兩年多的鍛鍊，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 逐漸孵化出了元件全託管的系統能力。

​

​

• 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 架構

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

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

​

自愈

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

​

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

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

展望未來

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

原文連結

本文為阿里雲原創內容，未經允許不得轉載。

​