作者：仔仁、墨封、光南

序言

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

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

• 第一次全面統(tǒng)一調(diào)度：電商、搜索、odps 離線和螞蟻業(yè)務(wù)全面上 ASI 統(tǒng)一調(diào)度架構(gòu)，整個(gè)業(yè)務(wù)核數(shù)達(dá)到了驚人的數(shù)千萬核。
• 第一次將搜索業(yè)務(wù)“無感知”平滑遷移到 ASI：近千萬核的業(yè)務(wù)，業(yè)務(wù)無感的搬到 ASI（但是我們卻經(jīng)歷了很多個(gè)不眠之夜）。
• ASI 場(chǎng)景的 K8s 單集群規(guī)模超過萬臺(tái)節(jié)點(diǎn)，數(shù)百萬核，超越 K8s 社區(qū)的 5000 臺(tái)規(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ù)，實(shí)現(xiàn)“三位一體”。

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

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

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

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

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

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

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

ASI 全托管運(yùn)維支撐體系

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

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

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

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

• 元集群（KOK 架構(gòu)底層 K）：用于承載 K8s 業(yè)務(wù)集群的核心管控組件，將業(yè)務(wù)集群管控容器化部署，能保證部署方式更加標(biāo)準(zhǔn)，部署效率也會(huì)大大提升。
• 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ò)組件、存儲(chǔ)組件、Workload 組件（OpenKruise）、coredns 和其他一些旁路組件。
• Data-Plane：節(jié)點(diǎn)管控組件，比如 containerd、kubelet，kata 等，還有一些其他節(jié)點(diǎn)上的插件。

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

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

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

集群全托管運(yùn)維能力

當(dāng)我們?cè)谶\(yùn)維大規(guī)模 K8s 集群的時(shí)候，最深的感受就是：規(guī)模化既會(huì)給單個(gè)運(yùn)維操作帶來很大的復(fù)雜度，也會(huì)將單個(gè)運(yùn)維操作的風(fēng)險(xiǎn)爆炸半徑大大擴(kuò)大。我們也是經(jīng)常會(huì)被下面的問題挑戰(zhàn)：

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

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

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

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

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

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

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

變更灰度能力

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

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

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

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

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

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

• 更新不及時(shí)：新增了一個(gè)集群，但是沒有通知相關(guān)同學(xué)，沒有加到對(duì)應(yīng)的 pipeline；
• 自動(dòng)適配能力不夠：ASI 新接入了一個(gè)云產(chǎn)品，需要人工新加一條 pipeline，經(jīng)常更新不及時(shí)；
• 維護(hù)成本高：隨著業(yè)務(wù)越來越多，各個(gè)研發(fā) owner 要自己維護(hù)非常多條 pipeline；
• 擴(kuò)展能力不足：pipeline 順序不能動(dòng)態(tài)調(diào)整，ASI 支持云產(chǎn)品之后，有一個(gè)非常重要的需求就是按照 GC 等級(jí)進(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)度項(xiàng)目，將集團(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è)計(jì)實(shí)現(xiàn)了 Cluster-Scheduler，將集群的各種信息整合起來，進(jìn)行打分、排序，得出一條集群 pipeline，然后提供給研發(fā)同學(xué)來進(jìn)行灰度發(fā)布。

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

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

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

集群webshell工具

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

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

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

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

變更編排能力

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

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

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

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

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

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

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

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

小結(jié)

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

組件全托管運(yùn)維能力

關(guān)于 ASI 組件全托管能力，我們之前已經(jīng)發(fā)表過一篇文章進(jìn)行詳細(xì)介紹：ASI 組件灰度體系建設(shè)，大家有興趣可以詳細(xì)看一下，確實(shí)在 ASI 如此大規(guī)模場(chǎng)景下，才會(huì)有的技術(shù)和經(jīng)驗(yàn)的沉淀。所以我這里就不做過多的技術(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)品一個(gè)非常重要的區(qū)別：ASI 會(huì)負(fù)責(zé) K8s 集群中核心組件維護(hù)工作（研發(fā)、問題排查和運(yùn)維）。這個(gè)其實(shí)也是和 ASI 起源有關(guān)，ASI 起源于集體業(yè)務(wù)全面上云時(shí)期，我們提供一個(gè)大集群+公共資源池的模式讓業(yè)務(wù)逐漸從 Sigma 架構(gòu)遷移上 ASI。對(duì)于集團(tuán)業(yè)務(wù)來說，肯定不會(huì)去維護(hù) K8s 集群以及集群里的各種組件，所以這塊就完全由 ASI 團(tuán)隊(duì)來負(fù)責(zé)，也讓 ASI 逐漸孵化出了組件全托管的系統(tǒng)能力。

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

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

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

節(jié)點(diǎn)全托管運(yùn)維能力

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

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

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

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

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

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

節(jié)點(diǎn)彈性

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

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

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

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

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

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

風(fēng)控

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

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

KubeProbe

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

1）中心架構(gòu)

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

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

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

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

自愈

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

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

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

展望未來

ASI 作為容器服務(wù) ACK 在阿里巴巴內(nèi)部持續(xù)打磨的統(tǒng)一Serverless 基礎(chǔ)設(shè)施，正在持續(xù)構(gòu)建更強(qiáng)大的全自動(dòng)駕駛 K8s 集群，提供集群、節(jié)點(diǎn)、組件的全托管能力，并一如既往地輸出更多經(jīng)驗(yàn)到整個(gè)行業(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è)的平臺(tái)分工做專業(yè)的事。

點(diǎn)擊??此處??，前往云原生子社區(qū)查看更多內(nèi)容！

總結(jié)

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

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