发布策略选型：Zadig、阿里云、Argo、Spinnaker、Harness、Codefresh...在软件开发和运维

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

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

实现原理和使用流程

01、Zadig

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

使用条件

workload 需要有一个 service 与之对应，并且 workload 的 labels 包含所有 service 的 selector labels
workload 当前只支持 deployment 类型

原理

部署蓝环境，复制当前 workload，设置新的镜像，创建一个 blue service 指向它
蓝环境部署完成，执行用户的验证任务
开始执行蓝绿发布，删除 blue service
将 green service 指向新创建的 workload
删除旧的 workload
发布过程完成或者中断删除蓝环境

配置过程

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

使用过程

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

添加图片注释，不超过 140 字（可选）

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

添加图片注释，不超过 140 字（可选）

02、阿里云

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

前提

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

原理

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

配置过程

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

执行过程

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

添加图片注释，不超过 140 字（可选）

03、Harness

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

添加图片注释，不超过 140 字（可选）

原理

第一次部署：

Harness 创建两个 services，分别配置 annotation a.线上 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 指向绿环境

配置过程

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

执行过程

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

添加图片注释，不超过 140 字（可选）

04、Codefresh

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

原理

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

配置过程

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

执行过程

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

添加图片注释，不超过 140 字（可选）

05、Spinnaker

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

原理

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

配置过程

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

执行过程

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

06、Argo Rollouts

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

原理

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

执行过程

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

添加图片注释，不超过 140 字（可选）

07、Fluxcd / Flagger

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

原理

使用其实现的 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 方式配置蓝绿发布过程，详细配置参见文档。

使用过程

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

不同平台的差异选型比对

以上产品均涉及到的工作流的蓝绿步骤在部署新版本以后流量切换操作。

添加图片注释，不超过 140 字（可选）

通过了解不同平台的特点和优势，大家可以根据自身的需求，选择和实施灰度发布策略，提升软件交付的效率和质量。更多关于灰度发布、 Istio 发布、全链路发布方案感兴趣同学，欢迎添加 Zadig 交流群一同探讨。

立即体验 Zadig V2.0 新架构，开启高效交付之旅！🚀

添加图片注释，不超过 140 字（可选）