在軟件開發(fā)和運維的領(lǐng)域中，灰度發(fā)布是一種關(guān)鍵的部署策略，用于逐步推送新版本給用戶，以減少潛在的風(fēng)險和影響范圍。不同的平臺在實現(xiàn)灰度發(fā)布時可能存在差異，因為它們需要滿足各自的需求和限制。

本文將對灰度發(fā)布的不同平臺進行全面比對，重點關(guān)注 ZadigX、阿里云、Harness、Spinnaker、Argo Rollouts 等主流平臺。我們將深入探討它們的使用條件、實現(xiàn)原理、使用流程，橫向差異的比對，旨在幫助大家選擇最適合自己的平臺。

實現(xiàn)原理和使用流程

01ZadigX

ZadigX 支持藍(lán)綠、金絲雀、分批次灰度、Istio 發(fā)布等發(fā)布策略，下面簡單介紹 ZadigX 藍(lán)綠發(fā)布原理，更多發(fā)布策略使用過程參考官方文檔[1]。

使用條件

workload 需要有一個 service 與之對應(yīng)，并且 workload 的 labels 包含所有 service 的 selector labels

workload 當(dāng)前只支持 deployment 類型

原理

部署藍(lán)環(huán)境，復(fù)制當(dāng)前 workload，設(shè)置新的鏡像，創(chuàng)建一個 blue service 指向它

藍(lán)環(huán)境部署完成，執(zhí)行用戶的驗證任務(wù)

開始執(zhí)行藍(lán)綠發(fā)布，刪除 blue service

將 green service 指向新創(chuàng)建的 workload

刪除舊的 workload

發(fā)布過程完成或者中斷刪除藍(lán)環(huán)境

配置過程

界面化配置發(fā)布工作流，詳細(xì)配置參見文檔[1]。ZadigX 支持多服務(wù)編排藍(lán)綠發(fā)布，內(nèi)置最佳實踐，配置簡單易上手；結(jié)合系統(tǒng)的用戶體系、權(quán)限管理、項目管理滿足企業(yè)的個性化訴求。

使用過程

• 點擊「執(zhí)行」按鈕，選擇需要更新的實例及鏡像。

圖片

圖片

• 工作流按照設(shè)置的任務(wù)完成執(zhí)行，執(zhí)行狀態(tài)如下圖所示。

圖片

02阿里云

阿里云支持藍(lán)綠發(fā)布、分批發(fā)布等灰度發(fā)布策略，下面以藍(lán)綠發(fā)布為例，簡單介紹其原理和使用流程，阿里云借助 Istio 來做藍(lán)綠發(fā)布，詳細(xì)過程可參考官方文檔[2]。

前提

• Service/VirtualService/DestinationRule 同名
• Deployment 的 labels 內(nèi)包含有 Service 的全部 selector labels

原理

• 基于 Istio 及其 VirtualService DestinationRule 資源類型進行流量控制
• 藍(lán)綠發(fā)布開始，基于當(dāng)前的 Deployment 實例，在藍(lán)環(huán)境創(chuàng)建一個新版本的應(yīng)用 Deployment 實例
• Service 與多個版本的 Deployment 實例直接通過 LabelSelector 進行關(guān)聯(lián)，讓 Istio 可以發(fā)現(xiàn)這些服務(wù)實例
• 更新 Istio 的 DestinationRule 資源對象，為不同版本設(shè)置子集，再更新 VirtualService 設(shè)置流量路由的規(guī)則以及權(quán)重
• 人工驗證完成后，完成發(fā)布將所有流量切流到藍(lán)環(huán)境，并且將原有的綠環(huán)境實例移除

配置過程

界面化配置流水線，詳細(xì)配置參見文檔[2]，對于多個服務(wù)的藍(lán)綠發(fā)布場景，配置相對繁瑣。

執(zhí)行過程

執(zhí)行流水線，觸發(fā)藍(lán)綠發(fā)布，通過 Cookie 標(biāo)訪問新版環(huán)境進行功能驗證，驗證沒問題，點擊「完成」，流量切到新版本；驗證有問題則點擊「回滾」。

圖片

03Harness

Harness 支持藍(lán)綠發(fā)布、滾動發(fā)布、金絲雀發(fā)布等發(fā)布策略，支持 Deployment 、 Statefulset 工作負(fù)載，通過 K8s 原生 Service 做流量控制，下面以藍(lán)綠發(fā)布為例，簡單介紹 Harness 藍(lán)綠發(fā)布的執(zhí)行過程，具體原理可參考官方文檔[3]。

圖片

圖片

原理

第一次部署：

1. Harness 創(chuàng)建兩個 services，分別配置 annotationa.線上 service：annotations: harness.io/primary-service: "true"b.測試 service：annotations: harness.io/stage-service: "true"
2. 藍(lán)環(huán)境創(chuàng)建原版本的 pod 集合并配置 annotation：harness.io/color: blue
3. 測試 service 指向藍(lán)環(huán)境 pod，測試沒問題后線上 service 也指向藍(lán)環(huán)境 pod

第二次部署：

1. 綠環(huán)境中創(chuàng)建新版本 pod，并配置 annotation，harness.io/color: green
2. 測試 service 指向綠環(huán)境新版本 pod，并進行驗證，驗證通過后
3. 線上 service 指向綠環(huán)境新版本 pod，測試 service 指向藍(lán)環(huán)境老版本 pod

第三次部署：

1. 藍(lán)環(huán)境老版本 pod 升級為新版本
2. 測試 service 指向藍(lán)環(huán)境新版本 pod 并且驗證，驗證通過后
3. 線上 service 指向藍(lán)環(huán)境新版本 pod，測試 service 指向綠環(huán)境

配置過程

界面化配置工作流，詳細(xì)配置參見文檔[3]，配置項較多，有一定的學(xué)習(xí)成本。

執(zhí)行過程

執(zhí)行工作流觸發(fā)藍(lán)綠過程。

圖片

04Codefresh

Codefresh 支持藍(lán)綠發(fā)布、金絲雀發(fā)布，支持 Deployment 工作負(fù)載，下面簡單介紹 Codefresh 實現(xiàn)藍(lán)綠發(fā)過過程，更多實現(xiàn)原理參考官方文檔[4]。

原理

1. 部署新版本
2. 等待 HEALTH_SECONDS 時間，任務(wù)對新版本 pod 做一些健康檢查，也可以手工做一些檢查
3. 超過等待時間，沒有任何錯誤，切換流量到新版本
4. 如果有報錯，回滾到之前版本

配置過程

在工作流中以 YAML 方式定義服務(wù)藍(lán)綠過程的相關(guān)配置，詳細(xì)配置參見文檔[4]。

執(zhí)行過程

執(zhí)行 Codefresh 工作流觸發(fā)藍(lán)綠發(fā)布，僅支持單個服務(wù)的藍(lán)綠發(fā)布。

圖片

05Spinnaker

Spinnaker 支持藍(lán)綠、金絲雀等灰度發(fā)布策略，僅支持 ReplicaSet 類型工作負(fù)載，下面簡單介紹使用 Spinnaker 實現(xiàn)藍(lán)綠發(fā)布的過程，具體原理可參考官方文檔[5]。

原理

為 ReplicaSet 設(shè)置 Annotations <traffic.spinnaker.io/load-balancers: '["service my-service"]'>，Spinnaker 可以自動為其下的 Pod label 添加符合 my-service Selector 的 label。

配置過程

界面化方式配置工作流，詳細(xì)配置參見文檔[5]，配置項較多，有一定的學(xué)習(xí)成本。

執(zhí)行過程

1. 創(chuàng)建新版本鏡像的 ReplicaSet，部署到藍(lán)環(huán)境
2. Spinnaker 根據(jù) Annotations 將新版本的 ReplicaSet 綁定到指定 Service 上
3. 測試完成后通過 Disable Stage 下線原版本的 ReplicaSet

06Argo Rollouts

Argo Rollouts 支持藍(lán)綠發(fā)布、金絲雀發(fā)布等發(fā)布策略，下面簡單介紹使用 Argo Rollouts 做藍(lán)綠發(fā)布過程，更多原理和使用流程參考官方文檔[6]。

原理

• 使用 Rollout  CRD 取代 Deployment 并在其原有能力基礎(chǔ)上支持了多種發(fā)布策略

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-bluegreen
spec:
  replicas: 2
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: rollout-bluegreen
  template:
    metadata:
      labels:
        app: rollout-bluegreen
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:blue
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
  strategy:
    blueGreen: 
      # activeService specifies the service to update with the new template hash at time of promotion.
      # This field is mandatory for the blueGreen update strategy.
      activeService: rollout-bluegreen-active
      # previewService specifies the service to update with the new template hash before promotion.
      # This allows the preview stack to be reachable without serving production traffic.
      # This field is optional.
      previewService: rollout-bluegreen-preview
      # autoPromotionEnabled disables automated promotion of the new stack by pausing the rollout
      # immediately before the promotion. If omitted, the default behavior is to promote the new
      # stack as soon as the ReplicaSet are completely ready/available.
      # Rollouts can be resumed using: `kubectl argo rollouts promote ROLLOUT`
      autoPromotionEnabled: false

配置過程

需要 YAML 方式來定義藍(lán)綠發(fā)布過程，詳細(xì)配置參見文檔[6]。

執(zhí)行過程

Argo 提供功能簡單的 Dashboard，缺少企業(yè)級管理能力。

圖片

07Fluxcd / Flagger

Flagger 支持藍(lán)綠發(fā)布、金絲雀等發(fā)布策略，下面簡單介紹使用 Flagger 實現(xiàn)藍(lán)綠發(fā)布過程，具體可參考官方文檔[6]。

原理

1. 使用其實現(xiàn)的 Canary 類型 CRD 管理 Deployment 從而支持了多種發(fā)布策略
2. 引導(dǎo)創(chuàng)建服務(wù)：在啟動時，F(xiàn)lagger 會創(chuàng)建三個 ClusterIP Service（app-primary，app-canary，app）以及一個名為 app-primary 的藍(lán)版本 deployment
3. 檢測新版本：當(dāng) Flagger 檢測到新版本時，它會擴展綠色版本并運行一致性測試
4. 執(zhí)行一致性測試：一致性測試應(yīng)針對 app-canary ClusterIP 服務(wù)進行，以訪問綠色版本
5. 開始負(fù)載測試：如果一致性測試通過，F(xiàn)lagger 會開始負(fù)載測試，并使用自定義的 Prometheus 查詢來驗證測試結(jié)果
6. 分析負(fù)載測試：如果負(fù)載測試分析成功，F(xiàn)lagger 會將新版本升級為 app-primary，并縮減綠色版本

配置過程

K8s YAML 方式配置藍(lán)綠發(fā)布過程，詳細(xì)配置參見文檔[7]。

使用過程

Kubectl apply 方式執(zhí)行，沒有提供界面化的方式，缺乏企業(yè)級管理能力。