authors: 仔仁 墨封 光南
序言
ASI：Alibaba Serverless infrastructure，阿裡巴巴針對雲原生應用設計的統一基礎設施。ASI 基于阿裡雲公共雲容器服務 ACK之上，支撐集團應用雲原生化和雲産品的Serverless化的基礎設施平台。
2021年天貓雙十一，對于ASI來說又是“非凡”的一年，今年我們又完成了很多“第一次”的壯舉：
- 第一次全面統一排程：電商、搜尋、odps離線和螞蟻業務全面上ASI統一排程架構，整個業務核數達到了驚人的數千萬核。統一排程的更多介紹您可以閱讀： 首次！統一排程系統規模化落地，全面支撐阿裡巴巴雙 11 全業務
- 第一次将搜尋業務“無感覺”平滑遷移到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。
| 阿裡雲容器服務産品 | 産品簡介 |
| ACK/ACK Pro | 托管的Kubernetes叢集, 支援 ECS虛拟機，裸金屬，ECI執行個體等多種彈性計算資源，提供K8s的全生命周期管理能力。 |
| ASK (Serverless Kubernetes) | 托管的Serverless Kubernetes叢集, 使用者無需管理節點，極緻彈性，極簡體驗 |
| ACR | 容器鏡像服務，面向容器鏡像、Helm Chart 等符合 OCI 标準的雲原生制品安全托管及高效分發平台。 支援全球同步加速、大規模鏡像分發加速、多代碼源建構加速等能力。 |
針對阿裡巴巴和雲産品業務場景，在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全托管運維服務建設起來的。
叢集全托管運維能力
當我們在運維大規模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管控全托管層面做的遠遠不止這些系統能力，還有非常多次的架構更新的大型線上變更，正是因為我們有如此多場景積累，才能沉澱出很多重要的系統能力。
元件全托管運維能力
關于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體系下元件變更也完全統一在一個平台下，并且基于雲原生的能力也建設出了非常完善的灰階能力：
節點全托管運維能力
前面我也介紹了，我們在建設系統能力時不會重複造輪子，但是也不能完全依賴其他産品的能力。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，見
先于使用者發現問題-自研K8s巡檢/探測中心KubeProbe。KubeProbe也中了今年上海KubeCon議題，感興趣的同學，到時候也可以參加一下上海KubeCon線上會議。
中心架構
我們會有一套中心管控系統。使用者的用例會通過統一倉庫的鏡像的方式接入，使用我們通用的sdk庫，自定義巡檢和探測邏輯。我們會在中心管控系統上配置好叢集和用例的關系配置，如某用例應該執行在哪些叢集組上，并做好各種運作時配置。我們支援了周期觸發/手動觸發/事件觸發(如釋出)的用例觸發方式。用例觸發後會在叢集内建立一個執行巡檢/探測邏輯的Pod，這個pod裡會執行各種使用者自定義的業務巡檢/探測邏輯，并在成功和失敗後通過直接回調/消息隊列的方式通知中心端。中心端會負責告警和用例資源清理的工作。
常駐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基礎設施，正在持續建構更強大的全自動駕駛 Kubernetes 叢集，提供叢集、節點、元件的全托管能力，并一如既往地輸出更多經驗到整個行業。ASI 作為阿裡集團、阿裡雲基礎設施底座，為越來越多的雲産品提供更多專業服務，托管底層 Kubernetes 叢集，屏蔽複雜的 Kubernetes 門檻、透明幾乎所有的基礎設施複雜度，并用專業的産品技術能力兜底穩定性，讓雲産品隻需要負責自己的業務，專業的平台分工做專業的事。
求賢若渴
歡迎對雲原生、kubernetes、SRE、容器 有興趣的同學，您也可以加入我們，一起參與精彩的雲原生激情澎湃未來。聯系 [email protected]。