![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/97f6f38f09b24e2ca7ec7333730d157f.png)

作者 | 墨封
來源 | 阿里巴巴雲原生公眾號

一週前，我們介紹了[《面對大規模 K8s 叢集，如何先於使用者發現問題》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247504516&idx=1&sn=aa88827ebb8831a7db33ddc9774a7248&chksm=fae6d94bcd91505d46de40af4cf3984f9531ff9b491c6055d511297f473b41e3a59196c48f24&scene=21#wechat_redirect)。

本篇文章，我們將繼續為大家介紹 ASI SRE（ASI，Alibaba Serverless infrastructure，阿里巴巴針對雲原生應用設計的統一基礎設施） 是如何探索在 Kubernetes 體系下，建設 ASI 自身基礎設施在大規模叢集場景下的變更灰度能力的。

# 我們面臨著什麼

ASI 誕生於阿里巴巴集團全面上雲之際，承載著集團大量基礎設施全面雲原生化的同時，自身的架構、形態也在不斷地演進。

ASI 整體上主要採用 Kube-on-Kube 的架構，底層維護了一個核心的 Kubernetes 元叢集，並在該叢集部署各個租戶叢集的 master 管控元件：apiserver、controller-manager、scheduler，以及 etcd。而在每個業務叢集中，則部署著各類 controller、webhook 等 addon 元件，共同支撐 ASI 的各項能力。而在資料面元件層面，部分 ASI 元件以 DaemonSet 的形式部署在節點上，也有另一部分採用 RPM 包的部署形式。

![1.jpg](https://ucc.alicdn.com/pic/developer-ecology/3d4d297d2ab44ddf8f15cd9ab624ca63.jpg)

同時，ASI 承載了集團、售賣區場景下數百個叢集，幾十萬的節點。即便在 ASI 建設初期，其管轄的節點也達到了數萬的級別。在 ASI 自身架構快速發展的過程中，元件及線上變更相當頻繁，早期時單日 ASI 的元件變更可以達到數百次。而 ASI 的核心基礎元件諸如 CNI 外掛、CSI 外掛、etcd、Pouch 等，無論任意之一的錯誤變更都可能會引起整個叢集級別的故障，造成上層業務不可挽回的損失。

![2.jpg](https://ucc.alicdn.com/pic/developer-ecology/e4c28256a22b4408827caa38af711ea6.jpg)

簡而言之，叢集規模大、元件數量多，變更頻繁以及業務形態複雜是在 ASI，或其他 Kubernetes 基礎設施層建設灰度能力和變更系統的幾大嚴峻挑戰。當時在阿里巴巴內部，ASI/Sigma 已有數套現有的變更系統，但都存在一定的侷限性。

- 天基：具備通用的節點發布的能力，但不包括叢集、節點集等 ASI 的後設資料資訊。
- UCP：早期 sigma 2.0 的釋出平臺，年久失修。
- sigma-deploy：sigma 3.x 的釋出平臺，以映象 patch 的形式更新 deployment/daemonset。
- asi-deploy：早期 ASI 的釋出平臺，管理了 ASI 自身的元件，僅支援映象 patch，只針對 Aone 的 CI/CD 流水線做適配，以及支援在多個不同環境間灰度，但灰度粒度較粗。

由此，我們希望借鑑前面幾代 sigma/ASI 的釋出平臺歷史，從變更時入手，以系統能力為主，再輔以流程規範，逐步構建 ASI 體系下的灰度體系，建設 Kubernetes 技術棧下的運維變更平臺，保障數以千計的大規模叢集的穩定性。

# 預設和思路

ASI 自身架構和形態的發展會極大地影響其自身的灰度體系建設方式，因此在 ASI 發展的早期，我們對 ASI 未來的形態做了如下大膽的預設：

1. **以 ACK 為底座**：ACK（阿里雲容器服務）提供了雲的各種能力，ASI 將基於複用這些雲的能力，同時將阿里巴巴集團內積累的先進經驗反哺雲。
1. **叢集規模大**：為提高叢集資源利用率，ASI 將會以大叢集的方式存在，單個叢集提供公共資源池來承載多個二方租戶。
1. **叢集數量多**：ASI 不僅按 Region 維度進行叢集劃分，還會按照業務方等維度劃分獨立的叢集。
1. **Addon 數量多**：Kubernetes 體系是一個開放架構，會衍生出非常多 operator，而這些 operator 會和 ASI 核心元件一起共同對外提供各種能力。
1. **變更場景複雜**：ASI 的元件變更場景將不止映象釋出形式，Kubernetes 宣告式的物件生命週期管理註定了變更場景的複雜性。

基於以上幾個假設，我們能夠總結在 ASI 建設初期，亟待解決的幾個問題：

1. 如何在單個大規模叢集中建設變更的灰度能力？
1. 如何在多個叢集間建立規模化的變更灰度能力？
1. 在元件數量、種類眾多的情況下，如何保證進行元件管理並保證元件每次的釋出不會影響線上環境？

![3.png](https://ucc.alicdn.com/pic/developer-ecology/8de689143f7b43fa925d4b8d22492e1b.png)

我們轉換一下視角，脫離叢集的維度，嘗試從元件的角度來解決變更的複雜性。對於每個元件，它的生命週期可以大體劃分為需求和設計階段，研發階段和釋出階段。對於每個階段我們都希望進行規範化，並解決 Kubernetes 本身的特點，將固定的規範落到系統中，以系統能力去保證灰度過程。

結合 ASI 的形態和變更場景的特殊性，我們從以下幾點思路出發去系統化建設 ASI 的灰度體系：

- 需求和設計階段
   - 方案 TechReview
   - 元件上線變更會審

- 元件研發階段
   - 標準化元件研發流程

- 元件釋出變更階段
   - 提供元件工作臺能力進行元件的規模化管理
   - 建設 ASI 後設資料，細化灰度單元
   - 建設 ASI 單叢集、跨叢集的灰度能力

# 灰度體系建設

## 1. 研發流程標準化

ASI 核心元件的研發流程可以總結為以下幾個流程：

針對 ASI 自身的核心元件，我們與質量技術團隊的同學共同建設了 ASI 元件的 e2e 測試流程。除了元件自身的單元測試、整合測試外，我們單獨搭建了單獨的 e2e 叢集，用作常態化進行的 ASI 整體的功能性驗證和 e2e 測試。

![4.jpg](https://ucc.alicdn.com/pic/developer-ecology/851bcd130beb4e52bdab07c2b713bfdd.jpg)

從單個元件視角入手，每個元件的新功能經過研發後，進行 Code Review 透過併合入 develop 分支，則立即觸發進行 e2e 流程，透過 chorus（雲原生測試平臺） 系統構建映象後，由 ASIOps（ASI 運維管控平臺） 部署到對應的 e2e 叢集，執行標準的 Kubernetes Conformance 套件測試任務，驗證 Kubernetes 範圍內的功能是否正常。僅當所有測試 case 透過，該元件的版本才可標記為可推平版本，否則後續的釋出將會受到管控限制。

然而正如上文提到，Kubernetes 開放的架構意味著它不僅僅包含管控、排程等核心元件，叢集的功能還很大程度依賴於上層的 operator 來共同實現。因此 Kubernetes 範圍內的白盒測試並不能覆蓋所有的 ASI 的適用場景。底層元件功能的改變很有大程度會影響到上層 operator 的使用，因此我們在白盒 Conformance 的基礎上增加了黑盒測試用例，它包含對各類 operator 自身的功能驗證，例如從上層 paas 發起的擴縮容，校驗釋出鏈路的 quota 驗證等能力，常態化執行在叢集中。

![5.jpg](https://ucc.alicdn.com/pic/developer-ecology/af3294feeb5a44febf85e47fb64209d1.jpg)

## 2. 元件規模化管理

針對 ASI 元件多、叢集多的特點，我們在原有 asi-deploy 功能之上進行擴充，以元件為切入點，增強元件在多叢集間的管理能力，從**映象管理**演進成了**YAML 管理**。

![6.jpg](https://ucc.alicdn.com/pic/developer-ecology/39b562f1ea0941a6b2942156db4b1338.jpg)

基於 Helm Template 的能力，我們將一個元件的 YAML 抽離成模板、映象和配置三部分，分別表示以下幾部分資訊：

- 模板：YAML 中在所有環境固定不變的資訊，例如 apiVersion，kind 等；
- 映象：YAML 中與元件映象相關的資訊，期望在單一環境或者所有叢集中保持一致的資訊；
- 配置：YAML 中與單環境、單叢集繫結的資訊，允許存在多樣化的內容，不同叢集中的配置可能不同；

因此，一個完整的 YAML 則由模板、映象和配置共同渲染而成。而 ASIOps 則再會對映象資訊和配置資訊這部分 YAML 分別進行叢集維度和時間維度（多版本）進行管理，計算元件當前版本資訊在眾多叢集眾多分佈狀況以及元件在單叢集中版本的一致性狀況。

針對映象版本，我們從系統上促使其版本統一，以保證不會因版本過低而導致線上問題；而針對配置版本，我們則從管理上簡化它的複雜性，防止配置錯誤發入叢集。

![7.jpg](https://ucc.alicdn.com/pic/developer-ecology/9e8d825ec1a84524b619c8842997c434.jpg)

有了元件的基礎原型後，我們希望釋出不僅僅是“替換 workload 裡的 image 欄位”這樣簡單的一件事。我們當前維護了整個 YAML 資訊，包含了除了映象之外的其他配置內容，需要支援除了映象變動外的變更內容。因此我們嘗試以儘可能接近 kubectl apply 的方式去進行 YAML 下發。

我們會記錄三部分的 YAML Specification 資訊：

- Cluster Spec：當前叢集中指定資源的狀況；
- Target Spec：現在要釋出進叢集的 YAML 資訊；
- DB Spec：上一次部署成功的 YAML 資訊，與 kubectl apply 儲存在 annotation 中的 last-applied-configuration 功能相同。

![8.jpg](https://ucc.alicdn.com/pic/developer-ecology/132ba0f76e4f4c9f97d4e9bb8b519d89.jpg)

對於一個由映象、配置和模板共同構建的 YAML，我們會採集上述三種 Spec 資訊，並進行一次 diff，從而獲得到資源 diff patch，再進行一次 filter out，篩去不允許變更的危險的欄位，最後將整體的 patch 以 strategic merge patch 或者 merge patch 的形式傳送給 APIServer，觸發使得 workload 重新進入 reconcile 過程，以改變叢集中該 workload 的實際狀況。

除此之外，由於 ASI 元件之間具有較強的相關性，存在許多場景需要同時一次性發布多個元件。例如當我們初始化一個叢集，或者對叢集做一次整體的 release 時。因此我們在單個元件部署的基礎上增加了 Addon Release 的概念，以元件的集合來表明整個 ASI 的 release 版本，並且根據每個元件的依賴關係自動生成部署流，保證整體釋出的過程中不會出現迴圈依賴。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/03572b09562e499c9398db4adad03c2e.png)

## 3. 單叢集灰度能力建設

在雲原生的環境下，我們以終態的形式去描述應用的部署形態，而 Kubernetes 提供了維護各類 Workload 終態的能力，Operator 對比 workload 當前狀態與終態的差距並進行狀態協調。這個協調的過程，換言之 workload 釋出或者回滾的過程，可以由 Operator 定義的釋出策略來處理這個“面向終態場景內的程式導向的流程”。

相比 Kubernetes 上層的應用負載，底層的基礎設施元件在釋出的過程中更關心元件自身的灰度釋出策略和灰度暫停能力，_即不論任何型別的元件，都需要能在釋出過程中具備及時停止釋出的能力，以提供更多的時間進行功能檢測、決策以及回滾_。具體而言，這些能力可以歸納為如下幾類：

- updateStrategy：流式升級/滾動升級
- pause/resume：暫停/恢復能力
- maxUnavailable：不可用副本數到達一定時能夠快速停止升級
- partition：升級暫停能力，單次僅升級固定數量副本數，保留一定數量的老版本副本

ASI 中針對 Kubernetes 原生 workload 能力、節點能力都進行了增強。依託於叢集中 Kruise 和 KubeNode 這類 operator 的能力以及上層管控平臺 ASIOps 的共同協作，我們對 Kubernetes 基礎設施元件實現了上述灰度能力的支援。對於 Deployment / StatefulSet / DaemonSet / Dataplane 型別的元件，在單叢集中釋出時支援的能力如下：

![10.jpg](https://ucc.alicdn.com/pic/developer-ecology/7340228bcbb04dc0a8e4beb4dd19be20.jpg)

後文將簡要介紹我們針對不同 Workload 型別的元件進行灰度的實現，詳細的實現細節可以關注我們開源的專案 OpenKruise 以及後續準備開源的 KubeNode。

### **1）Operator Platform**

大多數 Kubernetes 的 operator 以 Deployment 或者 StatefulSet 的方式部署，在 Operator 釋出的過程中，一旦映象欄位變動，所有 Operator 副本均會被升級。這個過程一旦新版本存在問題，則會造成不可挽回的問題。

針對此類 operator，我們將 controller-runtime 從 operator 中剝離出來，構建一箇中心化的元件 operator-manager（OpenKruise 開源實現中為 controller-mesh）。同時每個 operator pod 中會增加一個 operator-runtime 的 sidecar 容器，透過 gRPC 介面為元件的主容器提供 operator 的核心能力。

![11.png](https://ucc.alicdn.com/pic/developer-ecology/2ace94ff771949f1bc0fc52b5210291f.png)

operator 向 APIServer 建立 Watch 連線後，監聽到事件並被轉化為待 operator 協調處理的任務流（即 operator 的流量），operator-manager 負責中心化管控所有 operator 的流量，並根據規則進行流量分片，分發到不同的 operator-runtime，runtime 中的 workerqueue 再觸發實際 operator 的協調任務。

在灰度過程中，operator-manager 支援按照 namespace 級別，雜湊分片方式，將 operator 的流量分攤給新舊版本的兩個副本，從而可以從兩個副本處理的負載 workload 來驗證這次灰度釋出是否存在問題。

### **2）Advanced DaemonSet**

社群原生的 DaemonSet 支援了 RollingUpdate，但是其滾動升級的能力上僅支援 maxUnavailable 一種，這對於單叢集數千上萬節點的 ASI 而言是無法接受的，一旦更新映象後所有 DaemonSet Pod 將會被升級，並且無法暫停，僅能透過 maxUnavailable 策略進行保護。一旦 DaemonSet 釋出了一個 Bug 版本，並且程式能夠正常啟動，那麼 maxUnavailable 也無法生效。

此外社群提供 onDelete 方式，可以在手動刪除 Pod 建立新 Pod，由釋出平臺中心端控制釋出順序和灰度，這種模式無法做到單叢集中的自閉環，所有的壓力都上升到釋出平臺上。讓上層釋出平臺來進行Pod驅逐，風險比較大。最好的方式就是 Workload 能自閉環提供元件更新的能力。因此我們在 Kruise 中加強了 DaemonSet 的能力使其支援上述幾種重要的灰度能力。

如下是一個基本的 Kruise Advanced DaemonSet 的例子：

```
apiVersion: apps.kruise.io/v1alpha1
kind: DaemonSet
spec:
  # ...
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 5
      partition: 100
      paused: false
```

其中 partition 意為保留老版本映象的 Pod 副本數，滾升級過程中一旦指定副本數 Pod 升級完成，將不再對新的 Pod 進行映象升級。我們在上層 ASIOps 中控制 partition 的數值來滾動升級 DaemonSet，並配合其他 UpdateStrategy 引數來保證灰度進度，同時在新建立的 Pod 上進行一些定向驗證。

![12.jpg](https://ucc.alicdn.com/pic/developer-ecology/7051c986a0f745f3829af271d644052c.jpg)

### **3）MachineComponentSet**

MachineComponentSet 是 KubeNode 體系內的 Workload，ASI 中在 Kubernetes 之外的節點元件（無法用 Kubernetes 自身的 Workload 釋出的元件），例如 Pouch，Containerd，Kubelet 等均是透過該 Workload 進行釋出。

節點元件以 Kubernetes 內部的自定義資源 MachineComponent 進行表示，包含一個指定版本的節點元件（例如 pouch-1.0.0.81）的安裝指令碼，安裝環境變數等資訊；而 MachineComponentSet 則是節點元件與節點集合的對映，表明該批機器需要安裝該版本的節點元件。而中心端的 Machine-Operator 則會去協調這個對映關係，以終態的形式，比對節點上的元件版本以及目標版本的差異，並嘗試去安裝指定版本的節點元件。

![13.jpg](https://ucc.alicdn.com/pic/developer-ecology/f50a1cf616664d15b165033f51a14d0c.jpg)

在灰度釋出這一部分，MachineComponentSet 的設計與 Advanced DaemonSet 類似，提供了包括 partition，maxUnavailable 的 RollingUpdate 特性，例如以下是一個 MachineComponentSet 的示例：

```
apiVersion: kubenode.alibabacloud.com/v1
kind: MachineComponentSet
metadata:
  labels:
    alibabacloud.com/akubelet-component-version: 1.18.6.238-20201116190105-cluster-202011241059-d380368.conf
    component: akubelet
  name: akubelet-machine-component-set
spec:
  componentName: akubelet
  selector: {}
  updateStrategy:
    maxUnavailable: 20%
    partition: 55
    pause: false
```

同樣上層 ASIOps 在控制灰度升級節點元件時，與叢集側的 Machine-Operator 進行互動，修改指定 MachineComponentSet 的 partition 等欄位進行滾動升級。

相比於傳統的節點元件釋出模式，KubeNode 體系將節點元件的生命週期也閉環至 Kubernetes 叢集內，並將灰度釋出的控制下沉到叢集側，減少中心側對節點後設資料管理的壓力。

## 4. 跨叢集灰度能力建設

阿里巴巴內部針對雲產品、基礎產品制定了變更紅線 3.0，對管控面元件、資料面元件的變更操作的分批灰度、控制間隔、可觀測、可暫停、可回滾進行了要求。但變更物件以 region 的單元進行灰度不滿足 ASI 的複雜場景，因此我們嘗試去細化 ASI 上管控面、資料面的變更所屬的變更單元的型別。

我們圍繞叢集這一基礎單元向上，向下分別進行抽象，得到以下幾個基本單元：

- **叢集組**：具有共同業務方（ASI 承接的二方使用者）、網路域（售賣區/OXS/集團）、環境（e2e/測試/預發/金絲雀/小流量/生產）資訊，因此在監控、告警、巡檢、釋出等方面的配置具有共同性。
- **叢集**：ASI 叢集概念，對應一個 Kubernetes 叢集預案。
- **節點集**：一組具有共同特徵的節點集合，包括資源池、子業務池等資訊。
- **Namespace**：單個叢集中的單個 Namespace，通常 ASI 中一個上層業務對應一個 Namespace。
- **節點**：單臺宿主機節點，對應一個 Kubernetes Node。

![14.jpg](https://ucc.alicdn.com/pic/developer-ecology/9468755aa4e847c584e82e8137fa5d1a.jpg)

針對每種釋出模式（管控元件、節點元件），我們以最小爆炸半徑為原則，將他們所對應的灰度單元編排串聯在一起，以使得灰度流程能夠固化到系統中，元件開發在釋出中必須遵守流程，逐個單元進行部署。編排過程中，我們主要考慮以下幾個因素：

- 業務屬性
- 環境（測試、預發、小流量、生產）
- 網路域（集團 V、售賣區、OXS）
- 叢集規模（Pod/Node 數）
- 使用者屬性（承載使用者的 GC 等級）
- 單元/中心
- 元件特性

同時我們對每個單元進行權重打分，並對單元間的依賴關係進行編排。例如以下是一條 ASI 監控元件的釋出流水線，由於該監控元件在所有 ASI 場景都會使用同一套方案，它將推平至所有 ASI 叢集。並且在推平過程中，它首先會經過泛電商交易叢集的驗證，再進行集團 VPC 內二方的釋出，最後進行售賣區叢集的釋出。
而在每個叢集中，該元件則會按照上一節中我們討論的單叢集內的灰度方式進行 1/5/10 批次的分批，逐批進行釋出。

![15.jpg](https://ucc.alicdn.com/pic/developer-ecology/2b1a28e9055e462982f136935d1f2a77.jpg)

進行了灰度單元編排之後，我們則可以獲得到一次元件推平流水線的基礎骨架。而對於骨架上的每個灰度單元，我們嘗試去豐富它的前置檢查和後置校驗，從而能夠在每次釋出後確認灰度的成功性，並進行有效的變更阻斷。同時對於單個批次我們設定一定的靜默期去使得後置校驗能夠有足夠的時間執行完，並且提供給元件開發足夠的時間進行驗證。目前單批次前置後置校驗內容包括：

- 全域性風險規則（封網、熔斷等）
- 釋出時間視窗（ASI 試行週末禁止釋出的規則）
- KubeProbe 叢集黑盒探測
- 金絲雀任務（由諾曼底發起的 ASI 全鏈路的擴縮容任務）
- 核心監控指標大盤
- 元件日誌（元件 panic 告警等）
- 主動診斷任務（主動查詢對應的監控資訊是否在釋出過程中有大幅變化）

![16.jpg](https://ucc.alicdn.com/pic/developer-ecology/6e8edd798cf542358e8ad7cbeba173b9.jpg)

將整個多叢集 釋出的流程串聯在一起，我們可以得到一個元件從研發，測試至上線釋出，整個流程經歷的事件如下圖：

![17.jpg](https://ucc.alicdn.com/pic/developer-ecology/8878716ce6d7441db04d5a6447571676.jpg)

在流水線編排的實現方面，我們對社群已有的 tekton 和 argo 進行了選型調研，但考慮到我們在釋出流程中較多的邏輯不適合單獨放在容器中執行，同時我們在釋出過程中的需求不僅僅是 CI/CD，以及在設計初期這兩個專案在社群中並不穩定。因而我們參考了 tekton 的基礎設計（task / taskrun / pipeline / pipelinerun）進行了實現，並且保持著和社群共同的設計方向，在未來會調整與社群更接近，更雲原生的方式。

# 成果

經過近一年半的建設，ASIOps 目前承載了近百個管控叢集，近千個業務叢集（包括 ASI 叢集、Virtual Cluster 多租虛擬叢集，Sigma 2.0 虛擬叢集等），400 多個元件（包括 ASI 核心元件、二方元件等）。同時 ASIOps 上包含了近 30 餘條推平流水線，適用於 ASI 自身以及 ASI 承載的業務方的不同釋出場景。

同時每天有近 400 次的元件變更（包括映象變更和配置變更），透過流水線推平的此時達 7900+。同時為了提高發布效率，我們在前後置檢查完善的條件下開啟了單叢集內自動灰度的能力，目前該能力被大多數 ASI 資料面的元件所使用。

如下是一個元件透過 ASIOps 進行版本推平的示例：

![18.png](https://ucc.alicdn.com/pic/developer-ecology/ab61674259944269b97a12b38e6fedf1.png)

同時我們在 ASIOps 上的分批灰度以及後置檢查變更阻斷，也幫助我們攔住了一定由於元件變更引起的故障。例如 Pouch 元件在進行灰度時，由於版本不相容導致了叢集不可用，透過釋出後觸發的後置巡檢發現了這一現象，並阻斷了灰度程式。

![19.png](https://ucc.alicdn.com/pic/developer-ecology/220295594a9c41b2be12dc37ebb9f23e.png)

ASIOps 上的元件大多數都是 ASI/Kubernetes 底層的基礎設施元件，近一年半以來沒有因為由元件變更所引起的故障。我們努力將指定的規範透過系統能力固化下來，以減少和杜絕違反變更紅線的變更，從而將故障的發生逐步右移，從變更引發的低階故障逐步轉變至程式碼 Bug 自身引起的複雜故障。

# 展望

隨著 ASI 的覆蓋的場景逐步擴大，ASIOps 作為其中的管控平臺需要迎接更復雜的場景，規模更大的叢集數、元件數的挑戰。

首先我們亟待解決穩定性和效率這一權衡問題，當 ASIOps 納管的叢集數量到達一定量級後，進行一次元件推平的耗時將相當大。我們希望在建設了足夠的前後置校驗能力後，提供變更全託管的能力，由平臺自動進行釋出範圍內的元件推平，並執行有效的變更阻斷，在 Kubernetes 基礎設施這一層真正做到 CI/CD 自動化。

同時目前我們需要手動對灰度單元進行編排，確定灰度順序，在未來我們希望建設完全整個 ASI 的後設資料，並自動對每次釋出範圍內的所有單元進行過濾、打分和編排。

最後，目前 ASIOps 暫時只做到針對元件相關的變更進行灰度的能力，而 ASI 範圍內的變更遠不止元件這一點。灰度體系應該是一個通用的範疇，灰度流水線需要被賦能到注入資源運維、預案執行的其他的場景中。
此外，整個管控平臺的灰度能力沒有與阿里巴巴有任何緊耦合，完全基於 Kruise / KubeNode 等 Workload 進行打造，未來我們會探索開源整套能力輸出到社群中。

雲原生下的灰度體系建設

相關文章