2023-07-17

发布策略选型：Zadig、阿里云、Argo、Spinnaker、Harness、Codefresh...

通过了解不同平台的特点和优势，按需选择和实施灰度发布策略，提升软件交付的效率和质量~

在软件开发和运维领域，灰度发布是一种至关重要的策略，它通过逐步向用户推送新版本来降低风险和影响范围。不同平台在实现灰度发布时存在差异，因为它们需要适应各自的需求和限制。

本文将对比分析灰度发布在 Zadig、阿里云、Harness、Spinnaker、Argo Rollouts 等主流平台上的实现方式。我们将详细探讨它们的使用条件、原理、流程，并进行横向比较，以帮助您选择最适合您需求的平台。

# 平台差异对比

平台	支持工作负载类型	现有服务使用成本	配置复杂度	易用性	是否支持审批
Zadig	Deployment、Statefulset	无需改造	简单	⭐️⭐️⭐️	支持 Zadig/ 飞书/钉钉审批
阿里云	Deployment、Statefulset	无需改造	中等	⭐️⭐️	支持
Harness	Deployment、Statefulset	无需改造	中等	⭐️⭐️⭐️	不支持
Codefresh	Deployment	无需改造	中等	⭐️⭐️⭐️	不支持
Spinnaker	ReplicaSet	需将现有服务改成 ReplicaSet 类型	困难	⭐️⭐️	支持
Fluxcd / Flagger	Deployment	需额外声明 Canary 资源	困难	⭐️	不支持
Argo Rollouts	Deployment	需额外声明 Rollout 资源	困难	⭐️	不支持

# 实现原理和使用流程

# Zadig

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

使用条件

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

原理

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

配置过程

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

使用过程

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

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

# 阿里云

阿里云支持蓝绿发布、分批发布等灰度发布策略，下面以蓝绿发布为例，简单介绍其原理和使用流程，阿里云借助 Istio 来做蓝绿发布 (opens new window)。

前提

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

原理

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

配置过程

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

执行过程

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

# Harness

Harness 支持蓝绿发布、滚动发布、金丝雀发布等发布策略，支持 Deployment 、 Statefulset 工作负载，通过 K8s 原生 Service 做流量控制，下面以蓝绿发布为例，简单介绍 Harness 蓝绿发布 (opens new window)的执行过程。

原理

第一次部署：

Harness 创建两个 services，分别配置 annotation
1. 线上 service：annotations: harness.io/primary-service: "true"
2. 测试 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 指向绿环境

配置过程

界面化配置工作流，配置项较多，有一定的学习成本。

执行过程

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

# Codefresh

Codefresh 支持蓝绿发布、金丝雀发布，支持 Deployment 工作负载，下面简单介绍 Codefresh 实现蓝绿发布 (opens new window)过程。

原理

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

配置过程

在工作流中以 YAML 方式定义服务蓝绿过程的相关配置。

执行过程

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

# Spinnaker

Spinnaker 支持蓝绿、金丝雀等灰度发布策略，仅支持 ReplicaSet 类型工作负载，下面简单介绍使用 Spinnaker 实现蓝绿发布 (opens new window)的过程。

原理

为 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

# Argo Rollouts

Argo Rollouts 支持蓝绿发布、金丝雀发布等发布策略，下面简单介绍使用 Argo Rollouts 蓝绿发布 (opens new window)过程。

原理

使用 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，缺少企业级管理能力。

# Fluxcd / Flagger

Flagger 支持蓝绿发布、金丝雀等发布策略，下面简单介绍使用 Flagger 实现蓝绿发布 (opens new window)过程。

原理

使用其实现的 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 方式执行，没有提供界面化的方式，缺乏企业级管理能力。