簡介：ASI 作為阿里集團(tuán)、阿里云基礎(chǔ)設(shè)施底座，為越來越多的云產(chǎn)品提供更多專業(yè)服務(wù)，托管底層 K8s 集群，屏蔽復(fù)雜的 K8s 門檻、透明幾乎所有的基礎(chǔ)設(shè)施復(fù)雜度，并用專業(yè)的產(chǎn)品技術(shù)能力兜底穩(wěn)定性，讓云產(chǎn)品只需要負(fù)責(zé)自己的業(yè)務(wù)，專業(yè)的平臺分工做專業(yè)的事。

作者：仔仁、墨封、光南

序言

ASI：Alibaba Serverless infrastructure，阿里巴巴針對云原生應(yīng)用設(shè)計的統(tǒng)一基礎(chǔ)設(shè)施。ASI 基于阿里云公共云容器服務(wù) ACK之上，支撐集團(tuán)應(yīng)用云原生化和云產(chǎn)品的 Serverless 化的基礎(chǔ)設(shè)施平臺。

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

• 第一次全面統(tǒng)一調(diào)度：電商、搜索、odps 離線和螞蟻業(yè)務(wù)全面上 ASI 統(tǒng)一調(diào)度架構(gòu)，整個業(yè)務(wù)核數(shù)達(dá)到了驚人的數(shù)千萬核。
• 第一次將搜索業(yè)務(wù)“無感知”平滑遷移到 ASI：近千萬核的業(yè)務(wù)，業(yè)務(wù)無感的搬到 ASI（但是我們卻經(jīng)歷了很多個不眠之夜）。
• ASI 場景的 K8s 單集群規(guī)模超過萬臺節(jié)點，數(shù)百萬核，超越 K8s 社區(qū)的 5000 臺規(guī)模，不斷優(yōu)化大規(guī)模集群的性能和穩(wěn)定性。
• 中間件服務(wù)第一次用云產(chǎn)品架構(gòu)支持集團(tuán)業(yè)務(wù)：中間件基于 ASI 公共云架構(gòu)，將中間件服務(wù)平滑遷移到云上，用云產(chǎn)品架構(gòu)支持集團(tuán)業(yè)務(wù)，實現(xiàn)“三位一體”。

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

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

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

ASI 能運維好這么多龐大 K8s 集群，一定得有“兩把刷子”。今天我會給大家詳細(xì)介紹 ASI 在為阿里集團(tuán)構(gòu)建云原生基礎(chǔ)設(shè)施，和支持阿里云云產(chǎn)品 Serverless 化方面，我們的運維體系和穩(wěn)定性工程能力。

ASI 技術(shù)架構(gòu)形態(tài)

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

針對阿里巴巴和云產(chǎn)品業(yè)務(wù)場景，在 K8s 集群功能層面我們會給用戶提供增強(qiáng)的能力，比如調(diào)度能力增強(qiáng)、Workload 能力增強(qiáng)、網(wǎng)絡(luò)能力增強(qiáng)、節(jié)點彈性能力增強(qiáng)和多租安全架構(gòu)等等；在集群運維層面，提供 Serverless 化的 No Ops 體驗，比如集群大版本升級、組件升級、節(jié)點組件升級、節(jié)點 CVE 漏洞修復(fù)、節(jié)點批量運維等，為用戶的 K8s 集群穩(wěn)定性兜底。

ASI 全托管運維支撐體系

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

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

另外一件非常重要的事情：做穩(wěn)定性的團(tuán)隊要想做好運維管控系統(tǒng)，就一定要對業(yè)務(wù)架構(gòu)有非常全面、深入的了解。穩(wěn)定性團(tuán)隊不能只做運營，也不能僅僅在架構(gòu)外面做 1-5-10 能力，這樣是很難把控整個架構(gòu)的穩(wěn)定性。ASI SRE 雖然是為 ASI 基礎(chǔ)設(shè)施穩(wěn)定性兜底的團(tuán)隊，但是很多 SRE 同學(xué)都可以獨立去對接新的業(yè)務(wù)，并能決定整個業(yè)務(wù)上 ASI 的架構(gòu)。其實很多時候，如果是 SRE 和研發(fā)配合去接的業(yè)務(wù)方，往往問題都少很多，因為兩個角色非?；パa(bǔ)：研發(fā)在技術(shù)架構(gòu)上有很好的判斷，SRE 在架構(gòu)合理性和穩(wěn)定性風(fēng)險有很好的判斷。

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

• 元集群（KOK 架構(gòu)底層 K）：用于承載 K8s 業(yè)務(wù)集群的核心管控組件，將業(yè)務(wù)集群管控容器化部署，能保證部署方式更加標(biāo)準(zhǔn)，部署效率也會大大提升。
• Control-Plane：就是業(yè)務(wù)集群核心管控 4 大件：kube-apiserver/kube-controller-manager/kube-scheduler 和 etcd 集群。
• Add-Ons：Serverless 核心功能組件，調(diào)度增強(qiáng)組件（統(tǒng)一調(diào)度器）、網(wǎng)絡(luò)組件、存儲組件、Workload 組件（OpenKruise）、coredns 和其他一些旁路組件。
• Data-Plane：節(jié)點管控組件，比如 containerd、kubelet，kata 等，還有一些其他節(jié)點上的插件。

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

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

接下來我會針對 ASI 全托管運維體系中關(guān)鍵系統(tǒng)/技術(shù)能力的設(shè)計思路和具體方案進(jìn)行闡述，向大家呈現(xiàn)我們是如何一步步將大規(guī)模 K8s 全托管運維服務(wù)建設(shè)起來的。

集群全托管運維能力

當(dāng)我們在運維大規(guī)模 K8s 集群的時候，最深的感受就是：規(guī)?；葧o單個運維操作帶來很大的復(fù)雜度，也會將單個運維操作的風(fēng)險爆炸半徑大大擴(kuò)大。我們也是經(jīng)常會被下面的問題挑戰(zhàn)：

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

帶著這四個問題，接下來我會詳細(xì)介紹，我們?nèi)绾卧趯嵺`中不斷抽象和優(yōu)化我們的系統(tǒng)能力，并沉淀出目前對 ASI 全托管服務(wù)非常重要的穩(wěn)定性系統(tǒng)能力。

統(tǒng)一變更風(fēng)險管控

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

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

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

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

變更灰度能力

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

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

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

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

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

靜態(tài) pipeline 編排 ASI 集群順序的能力，在當(dāng)時只支持集團(tuán)為數(shù)不多的 ASI 集群時，問題還不大。但是當(dāng) ASI 業(yè)務(wù)擴(kuò)展到了阿里云云產(chǎn)品之后，特別是我們和 Flink 產(chǎn)品一起孵化出了 ASI 硬多租 VC 架構(gòu)之后，一個用戶一個小的集群，集群數(shù)量陡增，這種人工編排集群順序就暴露很多問題了：

• 更新不及時：新增了一個集群，但是沒有通知相關(guān)同學(xué)，沒有加到對應(yīng)的 pipeline；
• 自動適配能力不夠：ASI 新接入了一個云產(chǎn)品，需要人工新加一條 pipeline，經(jīng)常更新不及時；
• 維護(hù)成本高：隨著業(yè)務(wù)越來越多，各個研發(fā) owner 要自己維護(hù)非常多條 pipeline；
• 擴(kuò)展能力不足：pipeline 順序不能動態(tài)調(diào)整，ASI 支持云產(chǎn)品之后，有一個非常重要的需求就是按照 GC 等級進(jìn)行灰度，靜態(tài) pipeline 完全無法支持。

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

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

• 組件灰度發(fā)布的時候，通過 Cluster-Scheduler 篩選的集群范圍肯定不會漏集群；
• 集群發(fā)布順序按照 GC 等級來進(jìn)行權(quán)重設(shè)置，也能根據(jù)集群的規(guī)模數(shù)據(jù)來動態(tài)調(diào)整集群的權(quán)重；
• 研發(fā)發(fā)布的時候，不需要再維護(hù)多條靜態(tài) pipeline，只需要選擇組件發(fā)布范圍，會自動進(jìn)行集群發(fā)布順序編排。

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

集群webshell工具

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

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

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

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

變更編排能力

前面講的風(fēng)險阻斷、變更灰度和黑屏變更收斂，都是在解決 ASI 穩(wěn)定性問題。但是，誰又能幫助解決我們 SRE 同學(xué)面臨的挑戰(zhàn)呢？

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

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

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

• PipelineController：維護(hù)任務(wù)間的依賴信息
• TaskController：任務(wù)狀態(tài)信息維護(hù)
• TaskScheduler：任務(wù)調(diào)度
• Task/Worker：任務(wù)執(zhí)行

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

目前 Taskflow 這套編排引擎在 ASIOps 內(nèi)被廣泛使用，覆蓋了診斷、預(yù)案、節(jié)點導(dǎo)入導(dǎo)出、VC 集群開服、一次性運維、發(fā)布等場景，也大大提升了新的運維場景系統(tǒng)能力開發(fā)的效率。

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

小結(jié)

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

組件全托管運維能力

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

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

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

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

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

節(jié)點全托管運維能力

前面我也介紹了，我們在建設(shè)系統(tǒng)能力時不會重復(fù)造輪子，但是也不能完全依賴其他產(chǎn)品的能力。ACK 提供了節(jié)點生命周期管理的基本產(chǎn)品能力，而 ASI 作為 ACK 之上的 Serverless 平臺，需要在 ACK 基本產(chǎn)品能力之上，建設(shè)規(guī)?；\維能力。從 Sigma 時代到ASI支持集團(tuán)超大統(tǒng)一調(diào)度集群過程中，ASI 沉淀了非常多規(guī)?；\維節(jié)點的能力和經(jīng)驗。接下來介紹一下我們在售賣區(qū)如何建設(shè)節(jié)點全托管能力建設(shè)起來。

節(jié)點全生命周期定義

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

• 節(jié)點生產(chǎn)前：售賣區(qū)比較復(fù)雜的場景是每一個云產(chǎn)品都有一套或多套資源賬號，還有很多需要自定義 ECS 鏡像。這些都需要在新業(yè)務(wù)接入時進(jìn)行詳細(xì)定義；
• 節(jié)點導(dǎo)入時：集群節(jié)點導(dǎo)入時需要建設(shè)節(jié)點創(chuàng)建/擴(kuò)容/導(dǎo)入/下線等操作；
• 節(jié)點運行時：節(jié)點運行時往往是問題最多的階段，這塊也是需要重點能力建設(shè)的階段，如節(jié)點組件升級、批量執(zhí)行腳本能力、cve 漏洞修復(fù)，節(jié)點巡檢、自愈能力等等；
• 節(jié)點下線時：在節(jié)點成本優(yōu)化、內(nèi)核 cve 漏洞修復(fù)等場景下，都會需要節(jié)點騰挪、下線等規(guī)模化節(jié)點運維能力；
• 節(jié)點故障時：在節(jié)點故障時，我們需要有節(jié)點問題快速探測能力、問題診斷能力和節(jié)點自愈能力等。

節(jié)點能力建設(shè)大圖

ASI 售賣區(qū)節(jié)點托管能力建設(shè) 1 年多，已經(jīng)承載了售賣區(qū)所有上 ASI 的云產(chǎn)品，并且大部分核心能力都已經(jīng)建設(shè)比較完善，節(jié)點自愈能力我們也在不斷優(yōu)化完善中。

節(jié)點彈性

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

在節(jié)點彈性上，我們在節(jié)點整個生命周期中都進(jìn)行了性能優(yōu)化：

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

1-5-10 能力建設(shè)

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

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

風(fēng)控

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

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

KubeProbe

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

1）中心架構(gòu)

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

2）常駐 Operator 架構(gòu)

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

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

自愈

當(dāng)我們的業(yè)務(wù)規(guī)模達(dá)到一定規(guī)模，如果僅僅靠 SRE 團(tuán)隊線上 Oncall 去解決問題肯定是遠(yuǎn)遠(yuǎn)不夠的，一定需要我們系統(tǒng)具備非常強(qiáng)的自愈能力。K8s 面向終態(tài)的設(shè)計，通過 Readiness、Liveness 機(jī)制能幫忙業(yè)務(wù) Pod 快速自愈。但是當(dāng)節(jié)點故障時，我們也需要節(jié)點能快速自愈，或者能快速將節(jié)點上的業(yè)務(wù)驅(qū)逐到正常的節(jié)點上。ACK 產(chǎn)品也提供了自愈能力，ASI 在這個之上做了很多基于 ASI 業(yè)務(wù)場景的能力增強(qiáng)。如下是我們售賣區(qū)節(jié)點自愈能力的架構(gòu)設(shè)計：

隨著 ASI 業(yè)務(wù)形態(tài)的發(fā)展，未來我們將在如下場景下進(jìn)行節(jié)點自愈能力增強(qiáng)：

• 診斷、自愈規(guī)則更加豐富：目前的診斷、自愈規(guī)則很多場景下都沒有覆蓋，需要不斷優(yōu)化覆蓋，更多節(jié)點故障場景；
• 基于節(jié)點池的精細(xì)化的自愈風(fēng)控、流控：節(jié)點自愈的前提是不能讓現(xiàn)狀變的更糟，所以我們需要在做自愈時，做更加精確的判斷；
• 節(jié)點自愈能力與上層業(yè)務(wù)打通：不同業(yè)務(wù)形態(tài)，對節(jié)點自愈的要求不同。比如Flink業(yè)務(wù)都是任務(wù)類型，遇到節(jié)點問題需要我們盡快驅(qū)逐業(yè)務(wù)，觸發(fā)任務(wù)重建，最怕的就是任務(wù)“半死不活”；中間件/數(shù)據(jù)庫業(yè)務(wù)都是有狀態(tài)服務(wù)，不允許我們隨便驅(qū)逐業(yè)務(wù)，但是我們?nèi)绻炎杂芰εc上層業(yè)務(wù)邏輯打通，就可以做到將節(jié)點故障上透給業(yè)務(wù)，讓業(yè)務(wù)來決策是否要自愈，以及業(yè)務(wù)如何自愈。

展望未來

ASI 作為容器服務(wù) ACK 在阿里巴巴內(nèi)部持續(xù)打磨的統(tǒng)一Serverless 基礎(chǔ)設(shè)施，正在持續(xù)構(gòu)建更強(qiáng)大的全自動駕駛 K8s 集群，提供集群、節(jié)點、組件的全托管能力，并一如既往地輸出更多經(jīng)驗到整個行業(yè)。ASI 作為阿里集團(tuán)、阿里云基礎(chǔ)設(shè)施底座，為越來越多的云產(chǎn)品提供更多專業(yè)服務(wù)，托管底層 K8s 集群，屏蔽復(fù)雜的 K8s 門檻、透明幾乎所有的基礎(chǔ)設(shè)施復(fù)雜度，并用專業(yè)的產(chǎn)品技術(shù)能力兜底穩(wěn)定性，讓云產(chǎn)品只需要負(fù)責(zé)自己的業(yè)務(wù)，專業(yè)的平臺分工做專業(yè)的事。

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。