在軟件開發(fā)和運(yùn)維的領(lǐng)域中，灰度發(fā)布是一種關(guān)鍵的部署策略，用于逐步推送新版本給用戶，以減少潛在的風(fēng)險(xiǎn)和影響范圍。不同的平臺(tái)在實(shí)現(xiàn)灰度發(fā)布時(shí)可能存在差異，因?yàn)樗鼈冃枰獫M足各自的需求和限制。

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

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

01ZadigX

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

使用條件

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

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

原理

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

藍(lán)環(huán)境部署完成，執(zhí)行用戶的驗(yàn)證任務(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)置最佳實(shí)踐，配置簡(jiǎn)單易上手；結(jié)合系統(tǒng)的用戶體系、權(quán)限管理、項(xiàng)目管理滿足企業(yè)的個(gè)性化訴求。

使用過程

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

圖片

圖片

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

圖片

02阿里云

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

前提

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

原理

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

配置過程

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

執(zhí)行過程

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

圖片

03Harness

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

圖片

圖片

原理

第一次部署：

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

第二次部署：

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

第三次部署：

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

配置過程

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

執(zhí)行過程

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

圖片

04Codefresh

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

原理

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

配置過程

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

執(zhí)行過程

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

圖片

05Spinnaker

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

原理

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

配置過程

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

執(zhí)行過程

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

06Argo Rollouts

Argo Rollouts 支持藍(lán)綠發(fā)布、金絲雀發(fā)布等發(fā)布策略，下面簡(jiǎn)單介紹使用 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ái)定義藍(lán)綠發(fā)布過程，詳細(xì)配置參見文檔[6]。

執(zhí)行過程

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

圖片

07Fluxcd / Flagger

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

原理

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

配置過程

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

使用過程

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