發(fā)布策略選型：ZadigX、阿里云、Argo、Spinnaker、Harness、Codefresh...

作者：帶來 ZadigX的 2023-07-27 08:03:04

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

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

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

01ZadigX

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

使用條件

workload 需要有一個(gè) service 與之對應(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é)合系統(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ā)布為例，簡單介紹其原理和使用流程，阿里云借助 Istio 來做藍(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 資源對象，為不同版本設(shè)置子集，再更新 VirtualService 設(shè)置流量路由的規(guī)則以及權(quán)重
人工驗(yàn)證完成后，完成發(fā)布將所有流量切流到藍(lán)環(huán)境，并且將原有的綠環(huán)境實(shí)例移除

配置過程

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

執(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ā)布為例，簡單介紹 Harness 藍(lán)綠發(fā)布的執(zhí)行過程，具體原理可參考官方文檔[3]。

圖片

原理

第一次部署：

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

第二次部署：

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

第三次部署：

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

配置過程

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

執(zhí)行過程

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

圖片

04Codefresh

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

原理

部署新版本
等待 HEALTH_SECONDS 時(shí)間，任務(wù)對新版本 pod 做一些健康檢查，也可以手工做一些檢查
超過等待時(shí)間，沒有任何錯(cuò)誤，切換流量到新版本
如果有報(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ù)載，下面簡單介紹使用 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í)行過程

創(chuàng)建新版本鏡像的 ReplicaSet，部署到藍(lán)環(huán)境
Spinnaker 根據(jù) Annotations 將新版本的 ReplicaSet 綁定到指定 Service 上
測試完成后通過 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 實(shí)現(xiàn)藍(lán)綠發(fā)布過程，具體可參考官方文檔[6]。

原理

使用其實(shí)現(xiàn)的 Canary 類型 CRD 管理 Deployment 從而支持了多種發(fā)布策略
引導(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
檢測新版本：當(dāng) Flagger 檢測到新版本時(shí)，它會(huì)擴(kuò)展綠色版本并運(yùn)行一致性測試
執(zhí)行一致性測試：一致性測試應(yīng)針對 app-canary ClusterIP 服務(wù)進(jìn)行，以訪問綠色版本
開始負(fù)載測試：如果一致性測試通過，F(xiàn)lagger 會(huì)開始負(fù)載測試，并使用自定義的 Prometheus 查詢來驗(yàn)證測試結(jié)果
分析負(fù)載測試：如果負(fù)載測試分析成功，F(xiàn)lagger 會(huì)將新版本升級為 app-primary，并縮減綠色版本