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

​

作者 | 仔仁、墨封、光南
來源 | 阿里技術公眾號

一 序言

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中，幫忙更好的維護使用者的Kubernetes叢集。

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

二 ASI 技術架構形態

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

​

三 ASI全託管運維支撐體系

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

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

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

​

• 元叢集（KOK架構底層K）：用於承載Kubernetes業務叢集的核心管控元件，將業務叢集管控容器化部署，能保證部署方式更加標準，部署效率也會大大提升。
• 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全託管運維體系中關鍵系統/技術能力的設計思路和具體方案進行闡述，向大家呈現我們是如何一步步將大規模Kubernetes全託管運維服務建設起來的。

1 叢集全託管運維能力

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

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

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

統一變更風險管控

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

當時我們想的是靠系統來做變更風險管控肯定是來不及的（集團業務全面上雲已經開展起來，大量新的技術方案出來、大量線上變更），只能先靠“人治”。所以我們就在整個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執行流串聯起來，完成一次節點擴容操作。

​

​

小結

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

2 元件全託管運維能力

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

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

​

​

• IaC元件模型：利用K8S宣告式的設計，來將所有ASI元件型別的變更全部改為面向終態的設計；
• 統一變更編排：元件變更最重要的是灰度，灰度最重要的是叢集/節點灰度順序，所有元件都需要變更灰度編排；

元件雲原生改造：原來節點基於天基的包變更管理改造成K8S原生Operator面向終態的設計，這樣節點元件實現基本的元件變更通道、分批、暫停等能力。由上層的Ops系統來實現元件版本管理、灰度變更編排等。

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

​

3 節點全託管運維能力

前面我也介紹了，我們在建設系統能力時不會重複造輪子，但是也不能完全依賴其他產品的能力。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左右。

4 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裡會執行各種使用者自定義的業務巡檢/探測邏輯，並在成功和失敗後通過直接回調/訊息佇列的方式通知中心端。中心端會負責告警和用例資源清理的工作。

​

對於某些需要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業務場景的能力增強。如下是我們售賣區節點自愈能力的架構設計：

​

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

四 未來展望

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

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

​