簡介：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。

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

三 ASI全托管運維支撐體系

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

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

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

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

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

與此同時，我們開始將這些已經非常明確的變更風險阻斷的規則實現到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管控全托管層面做的遠遠不止這些系統能力，還有非常多次的架構升級的大型線上變更，正是因為我們有如此多場景積累，才能沉淀出很多重要的系統能力。

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逐漸孵化出了組件全托管的系統能力。

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

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

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

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?

總結

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

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