針對 ASI 組件多、集群多的特點(diǎn)，我們在原有 asi-deploy 功能之上進(jìn)行拓展，以組件為切入點(diǎn)，增強(qiáng)組件在多集群間的管理能力，從鏡像管理演進(jìn)成了YAML 管理。

基于 Helm Template 的能力，我們將一個組件的 YAML 抽離成模板、鏡像和配置三部分，分別表示以下幾部分信息：

模板：YAML 中在所有環(huán)境固定不變的信息，例如 apiVersion，kind 等；鏡像：YAML 中與組件鏡像相關(guān)的信息，期望在單一環(huán)境或者所有集群中保持一致的信息；配置：YAML 中與單環(huán)境、單集群綁定的信息，允許存在多樣化的內(nèi)容，不同集群中的配置可能不同；

因此，一個完整的 YAML 則由模板、鏡像和配置共同渲染而成。而 ASIOps 則再會對鏡像信息和配置信息這部分 YAML 分別進(jìn)行集群維度和時間維度（多版本）進(jìn)行管理，計算組件當(dāng)前版本信息在眾多集群眾多分布狀況以及組件在單集群中版本的一致性狀況。

針對鏡像版本，我們從系統(tǒng)上促使其版本統(tǒng)一，以保證不會因版本過低而導(dǎo)致線上問題；而針對配置版本，我們則從管理上簡化它的復(fù)雜性，防止配置錯誤發(fā)入集群。

有了組件的基礎(chǔ)原型后，我們希望發(fā)布不僅僅是“替換 workload 里的 image 字段”這樣簡單的一件事。我們當(dāng)前維護(hù)了整個 YAML 信息，包含了除了鏡像之外的其他配置內(nèi)容，需要支持除了鏡像變動外的變更內(nèi)容。因此我們嘗試以盡可能接近 kubectl apply 的方式去進(jìn)行 YAML 下發(fā)。

我們會記錄三部分的 YAML Specification 信息：

Cluster Spec：當(dāng)前集群中指定資源的狀況；Target Spec：現(xiàn)在要發(fā)布進(jìn)集群的 YAML 信息；DB Spec：上一次部署成功的 YAML 信息，與 kubectl apply 保存在 annotation 中的 last-applied-configuration 功能相同。

對于一個由鏡像、配置和模板共同構(gòu)建的 YAML，我們會采集上述三種 Spec 信息，并進(jìn)行一次 diff，從而獲得到資源 diff patch，再進(jìn)行一次 filter out，篩去不允許變更的危險的字段，最后將整體的 patch 以 strategic merge patch 或者 merge patch 的形式發(fā)送給 APIServer，觸發(fā)使得 workload 重新進(jìn)入 reconcile 過程，以改變集群中該 workload 的實際狀況。

除此之外，由于 ASI 組件之間具有較強(qiáng)的相關(guān)性，存在許多場景需要同時一次性發(fā)布多個組件。例如當(dāng)我們初始化一個集群，或者對集群做一次整體的 release 時。因此我們在單個組件部署的基礎(chǔ)上增加了 Addon Release 的概念，以組件的集合來表明整個 ASI 的 release 版本，并且根據(jù)每個組件的依賴關(guān)系自動生成部署流，保證整體發(fā)布的過程中不會出現(xiàn)循環(huán)依賴。

3. 單集群灰度能力建設(shè)

在云原生的環(huán)境下，我們以終態(tài)的形式去描述應(yīng)用的部署形態(tài)，而 Kubernetes 提供了維護(hù)各類 Workload 終態(tài)的能力，Operator 對比 workload 當(dāng)前狀態(tài)與終態(tài)的差距并進(jìn)行狀態(tài)協(xié)調(diào)。這個協(xié)調(diào)的過程，換言之 workload 發(fā)布或者回滾的過程，可以由 Operator 定義的發(fā)布策略來處理這個“面向終態(tài)場景內(nèi)的面向過程的流程”。

相比 Kubernetes 上層的應(yīng)用負(fù)載，底層的基礎(chǔ)設(shè)施組件在發(fā)布的過程中更關(guān)心組件自身的灰度發(fā)布策略和灰度暫停能力，_即不論任何類型的組件，都需要能在發(fā)布過程中具備及時停止發(fā)布的能力，以提供更多的時間進(jìn)行功能檢測、決策以及回滾_。具體而言，這些能力可以歸納為如下幾類：

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

ASI 中針對 Kubernetes 原生 workload 能力、節(jié)點(diǎn)能力都進(jìn)行了增強(qiáng)。依托于集群中 Kruise 和 KubeNode 這類 operator 的能力以及上層管控平臺 ASIOps 的共同協(xié)作，我們對 Kubernetes 基礎(chǔ)設(shè)施組件實現(xiàn)了上述灰度能力的支持。對于 Deployment / StatefulSet / DaemonSet / Dataplane 類型的組件，在單集群中發(fā)布時支持的能力如下：

后文將簡要介紹我們針對不同 Workload 類型的組件進(jìn)行灰度的實現(xiàn)，詳細(xì)的實現(xiàn)細(xì)節(jié)可以關(guān)注我們開源的項目 OpenKruise 以及后續(xù)準(zhǔn)備開源的 KubeNode。

1）Operator Platform

大多數(shù) Kubernetes 的 operator 以 Deployment 或者 StatefulSet 的方式部署，在 Operator 發(fā)布的過程中，一旦鏡像字段變動，所有 Operator 副本均會被升級。這個過程一旦新版本存在問題，則會造成不可挽回的問題。

針對此類 operator，我們將 controller-runtime 從 operator 中剝離出來，構(gòu)建一個中心化的組件 operator-manager（OpenKruise 開源實現(xiàn)中為 controller-mesh）。同時每個 operator pod 中會增加一個 operator-runtime 的 sidecar 容器，通過 gRPC 接口為組件的主容器提供 operator 的核心能力。

operator 向 APIServer 建立 Watch 連接后，監(jiān)聽到事件并被轉(zhuǎn)化為待 operator 協(xié)調(diào)處理的任務(wù)流（即 operator 的流量），operator-manager 負(fù)責(zé)中心化管控所有 operator 的流量，并根據(jù)規(guī)則進(jìn)行流量分片，分發(fā)到不同的 operator-runtime，runtime 中的 workerqueue 再觸發(fā)實際 operator 的協(xié)調(diào)任務(wù)。

在灰度過程中，operator-manager 支持按照 namespace 級別，哈希分片方式，將 operator 的流量分?jǐn)偨o新舊版本的兩個副本，從而可以從兩個副本處理的負(fù)載 workload 來驗證這次灰度發(fā)布是否存在問題。

2）Advanced DaemonSet

社區(qū)原生的 DaemonSet 支持了 RollingUpdate，但是其滾動升級的能力上僅支持 maxUnavailable 一種，這對于單集群數(shù)千上萬節(jié)點(diǎn)的 ASI 而言是無法接受的，一旦更新鏡像后所有 DaemonSet Pod 將會被升級，并且無法暫停，僅能通過 maxUnavailable 策略進(jìn)行保護(hù)。一旦 DaemonSet 發(fā)布了一個 Bug 版本，并且進(jìn)程能夠正常啟動，那么 maxUnavailable 也無法生效。

此外社區(qū)提供 onDelete 方式，可以在手動刪除 Pod 創(chuàng)建新 Pod，由發(fā)布平臺中心端控制發(fā)布順序和灰度，這種模式無法做到單集群中的自閉環(huán)，所有的壓力都上升到發(fā)布平臺上。讓上層發(fā)布平臺來進(jìn)行Pod驅(qū)逐，風(fēng)險比較大。最好的方式就是 Workload 能自閉環(huán)提供組件更新的能力。因此我們在 Kruise 中加強(qiáng)了 DaemonSet 的能力使其支持上述幾種重要的灰度能力。

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

apiVersion: apps.kruise.io/v1alpha1kind: DaemonSetspec: # ... updateStrategy: type: RollingUpdate rollingUpdate: maxUnavailable: 5 partition: 100 paused: false

其中 partition 意為保留老版本鏡像的 Pod 副本數(shù)，滾升級過程中一旦指定副本數(shù) Pod 升級完成，將不再對新的 Pod 進(jìn)行鏡像升級。我們在上層 ASIOps 中控制 partition 的數(shù)值來滾動升級 DaemonSet，并配合其他 UpdateStrategy 參數(shù)來保證灰度進(jìn)度，同時在新創(chuàng)建的 Pod 上進(jìn)行一些定向驗證。

3）MachineComponentSet

MachineComponentSet 是 KubeNode 體系內(nèi)的 Workload，ASI 中在 Kubernetes 之外的節(jié)點(diǎn)組件（無法用 Kubernetes 自身的 Workload 發(fā)布的組件），例如 Pouch，Containerd，Kubelet 等均是通過該 Workload 進(jìn)行發(fā)布。

節(jié)點(diǎn)組件以 Kubernetes 內(nèi)部的自定義資源 MachineComponent 進(jìn)行表示，包含一個指定版本的節(jié)點(diǎn)組件（例如 pouch-1.0.0.81）的安裝腳本，安裝環(huán)境變量等信息；而 MachineComponentSet 則是節(jié)點(diǎn)組件與節(jié)點(diǎn)集合的映射，表明該批機(jī)器需要安裝該版本的節(jié)點(diǎn)組件。而中心端的 Machine-Operator 則會去協(xié)調(diào)這個映射關(guān)系，以終態(tài)的形式，比對節(jié)點(diǎn)上的組件版本以及目標(biāo)版本的差異，并嘗試去安裝指定版本的節(jié)點(diǎn)組件。

在灰度發(fā)布這一部分，MachineComponentSet 的設(shè)計與 Advanced DaemonSet 類似，提供了包括 partition，maxUnavailable 的 RollingUpdate 特性，例如以下是一個 MachineComponentSet 的示例：

apiVersion: kubenode.alibabacloud.com/v1kind: MachineComponentSetmetadata: labels: alibabacloud.com/akubelet-component-version: 1.18.6.238-20201116190105-cluster-202011241059-d380368.conf component: akubelet name: akubelet-machine-component-setspec: componentName: akubelet selector: {} updateStrategy: maxUnavailable: 20% partition: 55 pause: false

同樣上層 ASIOps 在控制灰度升級節(jié)點(diǎn)組件時，與集群側(cè)的 Machine-Operator 進(jìn)行交互，修改指定 MachineComponentSet 的 partition 等字段進(jìn)行滾動升級。

相比于傳統(tǒng)的節(jié)點(diǎn)組件發(fā)布模式，KubeNode 體系將節(jié)點(diǎn)組件的生命周期也閉環(huán)至 Kubernetes 集群內(nèi)，并將灰度發(fā)布的控制下沉到集群側(cè)，減少中心側(cè)對節(jié)點(diǎn)元數(shù)據(jù)管理的壓力。

4. 跨集群灰度能力建設(shè)

阿里巴巴內(nèi)部針對云產(chǎn)品、基礎(chǔ)產(chǎn)品制定了變更紅線 3.0，對管控面組件、數(shù)據(jù)面組件的變更操作的分批灰度、控制間隔、可觀測、可暫停、可回滾進(jìn)行了要求。但變更對象以 region 的單元進(jìn)行灰度不滿足 ASI 的復(fù)雜場景，因此我們嘗試去細(xì)化 ASI 上管控面、數(shù)據(jù)面的變更所屬的變更單元的類型。

我們圍繞集群這一基礎(chǔ)單元向上，向下分別進(jìn)行抽象，得到以下幾個基本單元：

集群組：具有共同業(yè)務(wù)方（ASI 承接的二方用戶）、網(wǎng)絡(luò)域（售賣區(qū)/OXS/集團(tuán)）、環(huán)境（e2e/測試/預(yù)發(fā)/金絲雀/小流量/生產(chǎn)）信息，因此在監(jiān)控、告警、巡檢、發(fā)布等方面的配置具有共同性。集群：ASI 集群概念，對應(yīng)一個 Kubernetes 集群預(yù)案。節(jié)點(diǎn)集：一組具有共同特征的節(jié)點(diǎn)集合，包括資源池、子業(yè)務(wù)池等信息。Namespace：單個集群中的單個 Namespace，通常 ASI 中一個上層業(yè)務(wù)對應(yīng)一個 Namespace。節(jié)點(diǎn)：單臺宿主機(jī)節(jié)點(diǎn)，對應(yīng)一個 Kubernetes Node。

針對每種發(fā)布模式（管控組件、節(jié)點(diǎn)組件），我們以最小爆炸半徑為原則，將他們所對應(yīng)的灰度單元編排串聯(lián)在一起，以使得灰度流程能夠固化到系統(tǒng)中，組件開發(fā)在發(fā)布中必須遵守流程，逐個單元進(jìn)行部署。編排過程中，我們主要考慮以下幾個因素：

業(yè)務(wù)屬性環(huán)境（測試、預(yù)發(fā)、小流量、生產(chǎn)）網(wǎng)絡(luò)域（集團(tuán) V、售賣區(qū)、OXS）集群規(guī)模（Pod/Node 數(shù)）用戶屬性（承載用戶的 GC 等級）單元/中心組件特性

同時我們對每個單元進(jìn)行權(quán)重打分，并對單元間的依賴關(guān)系進(jìn)行編排。例如以下是一條 ASI 監(jiān)控組件的發(fā)布流水線，由于該監(jiān)控組件在所有 ASI 場景都會使用同一套方案，它將推平至所有 ASI 集群。并且在推平過程中，它首先會經(jīng)過泛電商交易集群的驗證，再進(jìn)行集團(tuán) VPC 內(nèi)二方的發(fā)布，最后進(jìn)行售賣區(qū)集群的發(fā)布。而在每個集群中，該組件則會按照上一節(jié)中我們討論的單集群內(nèi)的灰度方式進(jìn)行 1/5/10 批次的分批，逐批進(jìn)行發(fā)布。

進(jìn)行了灰度單元編排之后，我們則可以獲得到一次組件推平流水線的基礎(chǔ)骨架。而對于骨架上的每個灰度單元，我們嘗試去豐富它的前置檢查和后置校驗，從而能夠在每次發(fā)布后確認(rèn)灰度的成功性，并進(jìn)行有效的變更阻斷。同時對于單個批次我們設(shè)置一定的靜默期去使得后置校驗?zāi)軌蛴凶銐虻臅r間運(yùn)行完，并且提供給組件開發(fā)足夠的時間進(jìn)行驗證。目前單批次前置后置校驗內(nèi)容包括：

全局風(fēng)險規(guī)則（封網(wǎng)、熔斷等）發(fā)布時間窗口（ASI 試行周末禁止發(fā)布的規(guī)則）KubeProbe 集群黑盒探測金絲雀任務(wù)（由諾曼底發(fā)起的 ASI 全鏈路的擴(kuò)縮容任務(wù)）核心監(jiān)控指標(biāo)大盤組件日志（組件 panic 告警等）主動診斷任務(wù)（主動查詢對應(yīng)的監(jiān)控信息是否在發(fā)布過程中有大幅變化）

將整個多集群發(fā)布的流程串聯(lián)在一起，我們可以得到一個組件從研發(fā)，測試至上線發(fā)布，整個流程經(jīng)歷的事件如下圖：

在流水線編排的實現(xiàn)方面，我們對社區(qū)已有的 tekton 和 argo 進(jìn)行了選型調(diào)研，但考慮到我們在發(fā)布流程中較多的邏輯不適合單獨(dú)放在容器中執(zhí)行，同時我們在發(fā)布過程中的需求不僅僅是 CI/CD，以及在設(shè)計初期這兩個項目在社區(qū)中并不穩(wěn)定。因而我們參考了 tekton 的基礎(chǔ)設(shè)計（task / taskrun / pipeline / pipelinerun）進(jìn)行了實現(xiàn)，并且保持著和社區(qū)共同的設(shè)計方向，在未來會調(diào)整與社區(qū)更接近，更云原生的方式。

成果

經(jīng)過近一年半的建設(shè)，ASIOps 目前承載了近百個管控集群，近千個業(yè)務(wù)集群（包括 ASI 集群、Virtual Cluster 多租虛擬集群，Sigma 2.0 虛擬集群等），400 多個組件（包括 ASI 核心組件、二方組件等）。同時 ASIOps 上包含了近 30 余條推平流水線，適用于 ASI 自身以及 ASI 承載的業(yè)務(wù)方的不同發(fā)布場景。

同時每天有近 400 次的組件變更（包括鏡像變更和配置變更），通過流水線推平的此時達(dá) 7900+。同時為了提高發(fā)布效率，我們在前后置檢查完善的條件下開啟了單集群內(nèi)自動灰度的能力，目前該能力被大多數(shù) ASI 數(shù)據(jù)面的組件所使用。

如下是一個組件通過 ASIOps 進(jìn)行版本推平的示例：

同時我們在 ASIOps 上的分批灰度以及后置檢查變更阻斷，也幫助我們攔住了一定由于組件變更引起的故障。例如 Pouch 組件在進(jìn)行灰度時，由于版本不兼容導(dǎo)致了集群不可用，通過發(fā)布后觸發(fā)的后置巡檢發(fā)現(xiàn)了這一現(xiàn)象，并阻斷了灰度進(jìn)程。

ASIOps 上的組件大多數(shù)都是 ASI/Kubernetes 底層的基礎(chǔ)設(shè)施組件，近一年半以來沒有因為由組件變更所引起的故障。我們努力將指定的規(guī)范通過系統(tǒng)能力固化下來，以減少和杜絕違反變更紅線的變更，從而將故障的發(fā)生逐步右移，從變更引發(fā)的低級故障逐步轉(zhuǎn)變至代碼 Bug 自身引起的復(fù)雜故障。

展望

隨著 ASI 的覆蓋的場景逐步擴(kuò)大，ASIOps 作為其中的管控平臺需要迎接更復(fù)雜的場景，規(guī)模更大的集群數(shù)、組件數(shù)的挑戰(zhàn)。

首先我們亟待解決穩(wěn)定性和效率這一權(quán)衡問題，當(dāng) ASIOps 納管的集群數(shù)量到達(dá)一定量級后，進(jìn)行一次組件推平的耗時將相當(dāng)大。我們希望在建設(shè)了足夠的前后置校驗?zāi)芰?，提供變更全托管的能力，由平臺自動進(jìn)行發(fā)布范圍內(nèi)的組件推平，并執(zhí)行有效的變更阻斷，在 Kubernetes 基礎(chǔ)設(shè)施這一層真正做到 CI/CD 自動化。

同時目前我們需要手動對灰度單元進(jìn)行編排，確定灰度順序，在未來我們希望建設(shè)完全整個 ASI 的元數(shù)據(jù)，并自動對每次發(fā)布范圍內(nèi)的所有單元進(jìn)行過濾、打分和編排。

最后，目前 ASIOps 暫時只做到針對組件相關(guān)的變更進(jìn)行灰度的能力，而 ASI 范圍內(nèi)的變更遠(yuǎn)不止組件這一點(diǎn)?；叶润w系應(yīng)該是一個通用的范疇，灰度流水線需要被賦能到注入資源運(yùn)維、預(yù)案執(zhí)行的其他的場景中。此外，整個管控平臺的灰度能力沒有與阿里巴巴有任何緊耦合，完全基于 Kruise / KubeNode 等 Workload 進(jìn)行打造，未來我們會探索開源整套能力輸出到社區(qū)中。