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

作者：仔仁、墨封、光南

序言

ASI：Alibaba Serverless infrastructure，阿里巴巴針對云原生應(yīng)用設(shè)計的統(tǒng)一基礎(chǔ)設(shè)施。ASI 基于阿里云公共云容器服務(wù) ACK之上，支撐集團應(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ù)達到了驚人的數(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)支持集團業(yè)務(wù)：中間件基于 ASI 公共云架構(gòu)，將中間件服務(wù)平滑遷移到云上，用云產(chǎn)品架構(gòu)支持集團業(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 全部重建；
• 一次線上非標操作，將大批量的 vipserver 服務(wù)全部刪除，幸虧中間件有推空保護，才沒有對業(yè)務(wù)造成災(zāi)難性影響；
• 節(jié)點證書過期，由于節(jié)點自愈組件故障情況誤判，并且風(fēng)控/流控規(guī)則判斷也有誤，導(dǎo)致自愈組件誤將一個集群 300+ 節(jié)點上的業(yè)務(wù)全部驅(qū)逐；

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

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

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

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

針對阿里巴巴和云產(chǎn)品業(yè)務(wù)場景，在 K8s 集群功能層面我們會給用戶提供增強的能力，比如調(diào)度能力增強、Workload 能力增強、網(wǎng)絡(luò)能力增強、節(jié)點彈性能力增強和多租安全架構(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 運維體系之前，我先強調(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)定性的團隊要想做好運維管控系統(tǒng)，就一定要對業(yè)務(wù)架構(gòu)有非常全面、深入的了解。穩(wěn)定性團隊不能只做運營，也不能僅僅在架構(gòu)外面做 1-5-10 能力，這樣是很難把控整個架構(gòu)的穩(wěn)定性。ASI SRE 雖然是為 ASI 基礎(chǔ)設(shè)施穩(wěn)定性兜底的團隊，但是很多 SRE 同學(xué)都可以獨立去對接新的業(yè)務(wù)，并能決定整個業(yè)務(wù)上 ASI 的架構(gòu)。其實很多時候，如果是 SRE 和研發(fā)配合去接的業(yè)務(wù)方，往往問題都少很多，因為兩個角色非常互補：研發(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ù)集群管控容器化部署，能保證部署方式更加標準，部署效率也會大大提升。
• Control-Plane：就是業(yè)務(wù)集群核心管控 4 大件：kube-apiserver/kube-controller-manager/kube-scheduler 和 etcd 集群。
• Add-Ons：Serverless 核心功能組件，調(diào)度增強組件（統(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 集群全托管的標準產(chǎn)品能力，但是如何/何時做規(guī)模化升級的編排、驗證、監(jiān)控是我們需要考慮；并且我們還需要建設(shè)合理的備容機制，保證集群的穩(wěn)定性；
• ETCD 運維管控：ETCD 也是完全基于 ACK 的提供的全托管 ETCD Serverless 產(chǎn)品能力，我們會和 ACK 同學(xué)一起共建 ETCD 性能優(yōu)化、備容來更好的服務(wù) ASI 的超大規(guī)模集群；
• 組件運維管控：ASI 運維體系非常核心的能力建設(shè)，Serverless 全托管服務(wù)，最核心的就是各個核心組件都要有相應(yīng)的研發(fā)團隊進行功能擴展和運維支持。這樣如何定義研發(fā)同學(xué)的研發(fā)模式，確保日常運維的穩(wěn)定性和效率是 ASI 產(chǎn)品能支持大量業(yè)務(wù)的關(guān)鍵。所以在 ASI 成立之初（2019 年支持集團業(yè)務(wù)上云）我們就建立起了 ASI 組件中心，逐漸定義和優(yōu)化ASI核心組件的研發(fā)、運維模式；
• 節(jié)點全托管運維管控：這塊是非常多云產(chǎn)品團隊希望容器服務(wù)提供的能力，特別業(yè)務(wù)產(chǎn)品團隊，他們對基礎(chǔ)設(shè)施非常不了解，希望有團隊能幫忙將節(jié)點運維全托管掉。節(jié)點運維能力也是 ASI 在支撐阿里集團過程中非常重要的能力沉淀，我們也將這部分經(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è)計思路和具體方案進行闡述，向大家呈現(xiàn)我們是如何一步步將大規(guī)模 K8s 全托管運維服務(wù)建設(shè)起來的。

集群全托管運維能力

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

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

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

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

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

當(dāng)時我們想的是靠系統(tǒng)來做變更風(fēng)險管控肯定是來不及的（集團業(yè)務(wù)全面上云已經(jīng)開展起來，大量新的技術(shù)方案出來、大量線上變更），只能先靠“人治”。所以我們就在整個 ASI 團隊宣導(dǎo)任何變更都要讓 SRE 審批，但是 SRE 并不能了解 ASI 所有技術(shù)架構(gòu)細節(jié)，做完善的風(fēng)險評估。為此，我們又開始組建“變更評審”會議，在評審會上邀請每一個領(lǐng)域的專家同學(xué)參與進行變更方案的風(fēng)險評審。也是因為這個變更評審機制，幫助 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的指標/探測是沒辦法發(fā)現(xiàn)問題的，需要有一種機制能聯(lián)動上層業(yè)務(wù)系統(tǒng)來觸發(fā)業(yè)務(wù)層面的一些風(fēng)險阻斷規(guī)則判斷，這樣才能盡可能的確保我們的變更不會對上層業(yè)務(wù)帶來影響。所以，我們開始在 ASIOps 實現(xiàn)變更風(fēng)險規(guī)則庫的管理，并實現(xiàn)了一種 webhook 的機制，來聯(lián)動上層業(yè)務(wù)方的巡檢檢測/E2E 測試。

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

變更灰度能力

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

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

Sigma 時代，集群都是跨機房/跨 Region 部署的，所以如此龐大的業(yè)務(wù)體量，Sigma 也只需要 10 個不到的集群來承載。對于研發(fā)來說，因為集群個數(shù)不多，集群做什么用的、業(yè)務(wù)類型是怎樣的，都很清楚，所以發(fā)布成本不是很高（當(dāng)然，由于爆炸半徑太大，發(fā)布小問題也是不斷）。但是演進到 ASI 架構(gòu)之后，集群規(guī)劃是嚴格按照 Region/機房來進行切割的，并且由于 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ù)肯定會遠遠大于 Sigma 集群的個數(shù)。研發(fā)同學(xué)都還在 Sigma 后期、ASI 早期時代，很多研發(fā)習(xí)慣還是沿用 Sigma 當(dāng)時的模式，發(fā)布工具還是 Sigma 時代的產(chǎn)物，沒辦法支持大規(guī)模 K8s 集群精細化組件發(fā)布。各個團隊的研發(fā)每次發(fā)布也都膽戰(zhàn)心驚，也怕出問題。

當(dāng)時，在集團 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ī)定好的集群順序來進行灰度發(fā)布了，這就是 pipeline 概念的由來。這一個“看起來很 low”的功能，在當(dāng)時消耗了我們非常大的精力投入才做出一個初版。不過，當(dāng)我們“滿懷信心”把 pipeline 推廣給研發(fā)同學(xué)用的時候，卻沒有收到我們想象中的“鮮花和掌聲”，而是很多“吐槽和優(yōu)化建議”。所以我們改變推廣策略：逐步小范圍推廣、逐步修正、然后大范圍推廣，直到大家完全接受。現(xiàn)在 pipeline 已經(jīng)成為了 ASI 研發(fā)同學(xué)必不可少的發(fā)布工具了。現(xiàn)在想起來，也覺得蠻有意思的。也讓我們明白一個道理：任何新的功能不能“閉門造車”，一定要從我們的用戶角度出發(fā)來進行設(shè)計、優(yōu)化，只有用戶滿意，才能證明我們系統(tǒng)/產(chǎn)品的價值。

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

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

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

基于上述靜態(tài) pipeline 總總不足，我們也是早就開始了技術(shù)方案的優(yōu)化思考和探索。ASI核心是資源調(diào)度，我們的調(diào)度能力是非常強的，特別是現(xiàn)在集團做的統(tǒng)一調(diào)度項目，將集團電商業(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，將集群的各種信息整合起來，進行打分、排序，得出一條集群 pipeline，然后提供給研發(fā)同學(xué)來進行灰度發(fā)布。

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

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

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

集群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 中去訪問集群進行相應(yīng)的運維操作。在的 webshell 中我們會將用戶的所有操作記錄下來，上傳到審計中心。

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

• 權(quán)限精細化管控：權(quán)限與用戶綁定，有效期、權(quá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 負責(zé)整個 ASIOps 運維管控平臺的建設(shè)，既要面對每天繁重的運維工作，還要建系統(tǒng)，更要命的是我們的同學(xué)都是后端開發(fā)工程師出身，Ops 系統(tǒng)需要做前端界面，寫前端是后端工程師的夢魘，經(jīng)常是一個后端功能 1h 寫完，前端頁面要畫至少一天。

SRE 團隊是一個技術(shù)服務(wù)團隊，不僅僅要讓我們的服務(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：維護任務(wù)間的依賴信息
• TaskController：任務(wù)狀態(tài)信息維護
• TaskScheduler：任務(wù)調(diào)度
• Task/Worker：任務(wù)執(zhí)行

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

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

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

小結(jié)

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

組件全托管運維能力

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

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

如上圖，ASI 整個架構(gòu)的各種層面的組件現(xiàn)在都是基于 ASIOps 進行統(tǒng)一的變更灰度編排管理。其實，在現(xiàn)在看來 ASI 的所有組件放在一個平臺來維護，并且統(tǒng)一來進行灰度能力建設(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支持集團超大統(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ù)接入時進行詳細定義；
• 節(jié)點導(dǎo)入時：集群節(jié)點導(dǎo)入時需要建設(shè)節(jié)點創(chuàng)建/擴容/導(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 資源的極致彈性，能按照分鐘級來進行 ECS 資源購買和釋放，幫忙云產(chǎn)品精細化控制資源成本。視頻云云產(chǎn)品目前就在 ASI 上重度依賴 ASI 節(jié)點彈性能力，進行資源成本控制。視頻云平均一天節(jié)點彈性 3000 多次，并且經(jīng)過不斷優(yōu)化，ASI 節(jié)點彈性能達到幾分鐘內(nèi)完全拉起視頻云業(yè)務(wù)。

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

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

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

ASI 全托管模式的服務(wù)，最重要的還是我們能為云產(chǎn)品用戶進行底層集群穩(wě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 來標識）操作某一些資源的QPS，防止訪問 apiserver 過于頻繁，影響集群穩(wěn)定性。UA 限流能力是 ACK 產(chǎn)品增強能力。
• APF 限流：考慮 apiserver 的請求優(yōu)先級和公平性，避免在請求量過大時，有一些重要控制器的被餓死。K8s 原生增強能力。

KubeProbe

KubeProbe 是 ASI 巡檢/診斷平臺，經(jīng)過不斷迭代，目前我們演進了兩種架構(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)/消息隊列的方式通知中心端。中心端會負責(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ā)布阻斷等等附加功能，同時使用了標準 Operator 的云原生架構(gòu)設(shè)計，常駐體系帶來了極大的探測頻率提升(因為去掉了創(chuàng)建巡檢 Pod 和清理數(shù)據(jù)的開銷)基本可以做到對集群的 7*24 小時無縫覆蓋，同時便于對外集成。

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

自愈

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

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

• 診斷、自愈規(guī)則更加豐富：目前的診斷、自愈規(guī)則很多場景下都沒有覆蓋，需要不斷優(yōu)化覆蓋，更多節(jié)點故障場景；
• 基于節(jié)點池的精細化的自愈風(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)建更強大的全自動駕駛 K8s 集群，提供集群、節(jié)點、組件的全托管能力，并一如既往地輸出更多經(jīng)驗到整個行業(yè)。ASI 作為阿里集團、阿里云基礎(chǔ)設(shè)施底座，為越來越多的云產(chǎn)品提供更多專業(yè)服務(wù)，托管底層 K8s 集群，屏蔽復(fù)雜的 K8s 門檻、透明幾乎所有的基礎(chǔ)設(shè)施復(fù)雜度，并用專業(yè)的產(chǎn)品技術(shù)能力兜底穩(wěn)定性，讓云產(chǎn)品只需要負責(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)容還不錯，歡迎將生活随笔推薦給好友。