发布策略选型：ZadigX、阿里云、Argo、Spinnaker、Harness、Codefresh...-51CTO.COM

在软件开发和运维的领域中，灰度发布是一种关键的部署策略，用于逐步推送新版本给用户，以减少潜在的风险和影响范围。不同的平台在实现灰度发布时可能存在差异，因为它们需要满足各自的需求和限制。

本文将对灰度发布的不同平台进行全面比对，重点关注 ZadigX、阿里云、Harness、Spinnaker、Argo Rollouts 等主流平台。我们将深入探讨它们的使用条件、实现原理、使用流程，横向差异的比对，旨在帮助大家选择最适合自己的平台。

实现原理和使用流程

01ZadigX

ZadigX 支持蓝绿、金丝雀、分批次灰度、Istio 发布等发布策略，下面简单介绍 ZadigX 蓝绿发布原理，更多发布策略使用过程参考官方文档[1]。

使用条件

workload 需要有一个 service 与之对应，并且 workload 的 labels 包含所有 service 的 selector labels

workload 当前只支持 deployment 类型

原理

部署蓝环境，复制当前 workload，设置新的镜像，创建一个 blue service 指向它

蓝环境部署完成，执行用户的验证任务

开始执行蓝绿发布，删除 blue service

将 green service 指向新创建的 workload

删除旧的 workload

发布过程完成或者中断删除蓝环境

配置过程

界面化配置发布工作流，详细配置参见文档[1]。ZadigX 支持多服务编排蓝绿发布，内置最佳实践，配置简单易上手；结合系统的用户体系、权限管理、项目管理满足企业的个性化诉求。

使用过程

点击「执行」按钮，选择需要更新的实例及镜像。

图片

工作流按照设置的任务完成执行，执行状态如下图所示。

图片

02阿里云

阿里云支持蓝绿发布、分批发布等灰度发布策略，下面以蓝绿发布为例，简单介绍其原理和使用流程，阿里云借助 Istio 来做蓝绿发布，详细过程可参考官方文档[2]。

前提

Service/VirtualService/DestinationRule 同名
Deployment 的 labels 内包含有 Service 的全部 selector labels

原理

基于 Istio 及其 VirtualService DestinationRule 资源类型进行流量控制
蓝绿发布开始，基于当前的 Deployment 实例，在蓝环境创建一个新版本的应用 Deployment 实例
Service 与多个版本的 Deployment 实例直接通过 LabelSelector 进行关联，让 Istio 可以发现这些服务实例
更新 Istio 的 DestinationRule 资源对象，为不同版本设置子集，再更新 VirtualService 设置流量路由的规则以及权重
人工验证完成后，完成发布将所有流量切流到蓝环境，并且将原有的绿环境实例移除

配置过程

界面化配置流水线，详细配置参见文档[2]，对于多个服务的蓝绿发布场景，配置相对繁琐。

执行过程

执行流水线，触发蓝绿发布，通过 Cookie 标访问新版环境进行功能验证，验证没问题，点击「完成」，流量切到新版本；验证有问题则点击「回滚」。

图片

03Harness

Harness 支持蓝绿发布、滚动发布、金丝雀发布等发布策略，支持 Deployment 、 Statefulset 工作负载，通过 K8s 原生 Service 做流量控制，下面以蓝绿发布为例，简单介绍 Harness 蓝绿发布的执行过程，具体原理可参考官方文档[3]。

图片

原理

第一次部署：

Harness 创建两个 services，分别配置 annotationa.线上 service：annotations: harness.io/primary-service: "true"b.测试 service：annotations: harness.io/stage-service: "true"
蓝环境创建原版本的 pod 集合并配置 annotation：harness.io/color: blue
测试 service 指向蓝环境 pod，测试没问题后线上 service 也指向蓝环境 pod

第二次部署：

绿环境中创建新版本 pod，并配置 annotation，harness.io/color: green
测试 service 指向绿环境新版本 pod，并进行验证，验证通过后
线上 service 指向绿环境新版本 pod，测试 service 指向蓝环境老版本 pod

第三次部署：

蓝环境老版本 pod 升级为新版本
测试 service 指向蓝环境新版本 pod 并且验证，验证通过后
线上 service 指向蓝环境新版本 pod，测试 service 指向绿环境

配置过程

界面化配置工作流，详细配置参见文档[3]，配置项较多，有一定的学习成本。

执行过程

执行工作流触发蓝绿过程。

图片

04Codefresh

Codefresh 支持蓝绿发布、金丝雀发布，支持 Deployment 工作负载，下面简单介绍 Codefresh 实现蓝绿发过过程，更多实现原理参考官方文档[4]。

原理

部署新版本
等待 HEALTH_SECONDS 时间，任务对新版本 pod 做一些健康检查，也可以手工做一些检查
超过等待时间，没有任何错误，切换流量到新版本
如果有报错，回滚到之前版本

配置过程

在工作流中以 YAML 方式定义服务蓝绿过程的相关配置，详细配置参见文档[4]。

执行过程

执行 Codefresh 工作流触发蓝绿发布，仅支持单个服务的蓝绿发布。

图片

05Spinnaker

Spinnaker 支持蓝绿、金丝雀等灰度发布策略，仅支持 ReplicaSet 类型工作负载，下面简单介绍使用 Spinnaker 实现蓝绿发布的过程，具体原理可参考官方文档[5]。

原理

为 ReplicaSet 设置 Annotations <traffic.spinnaker.io/load-balancers: '["service my-service"]'>，Spinnaker 可以自动为其下的 Pod label 添加符合 my-service Selector 的 label。

配置过程

界面化方式配置工作流，详细配置参见文档[5]，配置项较多，有一定的学习成本。

执行过程

创建新版本镜像的 ReplicaSet，部署到蓝环境
Spinnaker 根据 Annotations 将新版本的 ReplicaSet 绑定到指定 Service 上
测试完成后通过 Disable Stage 下线原版本的 ReplicaSet

06Argo Rollouts

Argo Rollouts 支持蓝绿发布、金丝雀发布等发布策略，下面简单介绍使用 Argo Rollouts 做蓝绿发布过程，更多原理和使用流程参考官方文档[6]。

原理

使用 Rollout CRD 取代 Deployment 并在其原有能力基础上支持了多种发布策略

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 方式来定义蓝绿发布过程，详细配置参见文档[6]。

执行过程

Argo 提供功能简单的 Dashboard，缺少企业级管理能力。

图片

07Fluxcd / Flagger

Flagger 支持蓝绿发布、金丝雀等发布策略，下面简单介绍使用 Flagger 实现蓝绿发布过程，具体可参考官方文档[6]。

原理

使用其实现的 Canary 类型 CRD 管理 Deployment 从而支持了多种发布策略
引导创建服务：在启动时，Flagger 会创建三个 ClusterIP Service（app-primary，app-canary，app）以及一个名为 app-primary 的蓝版本 deployment
检测新版本：当 Flagger 检测到新版本时，它会扩展绿色版本并运行一致性测试
执行一致性测试：一致性测试应针对 app-canary ClusterIP 服务进行，以访问绿色版本
开始负载测试：如果一致性测试通过，Flagger 会开始负载测试，并使用自定义的 Prometheus 查询来验证测试结果
分析负载测试：如果负载测试分析成功，Flagger 会将新版本升级为 app-primary，并缩减绿色版本

配置过程

K8s YAML 方式配置蓝绿发布过程，详细配置参见文档[7]。

使用过程

Kubectl apply 方式执行，没有提供界面化的方式，缺乏企业级管理能力。