Blue–Green Deploy

Argo Rollouts 是一个 Kubernetes CRD 控制器，它通过扩展 Kubernetes 的原生 Deployment 资源，为 Kubernetes 提供了更高级的部署策略。其核心原理可以概括为：通过精细控制多个 ReplicaSet（对应不同版本的 Pod）的副本数量和流量分配，来实现可控的、自动化的应用发布流程。

1. 蓝绿部署原理

蓝绿部署的核心思想是同时存在两个完全独立的环境（蓝色和绿色），但任何时候只有一个环境承载生产流量。

工作原理

  1. 初始状态：

    • 假设当前生产环境是 蓝色 版本（v1），所有流量都指向蓝色的 ReplicaSet。
    • 绿色 环境虽然可能存在（例如，副本数为 0），但不接收任何流量。

  2. 发布新版本：

    • 当需要发布新版本（v2）时，Argo Rollouts 会创建一个与蓝色环境完全隔离的 绿色 环境 ReplicaSet，并启动全部所需的 Pod 实例。
    • 关键点：此时，用户流量仍然 100% 指向蓝色的 v1 版本。绿色 v2 版本在启动和预热期间，完全不影响线上用户。

  3. 测试与验证：

    • 运维人员或自动化脚本可以对绿色的 v2 版本进行测试，例如进行 API 调用、检查日志或运行集成测试。这个过程在生产流量不受干扰的情况下进行。

  4. 切换流量：

    • 一旦确认 v2 版本稳定，通过一个原子操作，将所有生产流量从蓝色（v1）瞬间切换到绿色（v2）。
    • 这个切换通常是通过更新 Kubernetes Service 或 Ingress 的 selector 标签来实现的。例如，将 app: my-app 的 selector 从 version: v1 改为 version: v2。

  5. 发布后：

    • 流量切换后，绿色（v2）成为新的生产环境。
    • 蓝色（v1）环境不会被立即删除，而是保留一段时间，作为快速回滚的保障。
    • 如果 v2 出现问题，只需将流量再次切回蓝色（v1）即可，回滚过程同样迅速且影响小。

原理示意图

[用户] --> [Service (selector: version=v1)] --> [蓝色 ReplicaSet (v1, 100% 流量)]
                                      |
                                      +--> [绿色 ReplicaSet (v2, 0% 流量， 待命)]

切换后：

[用户] --> [Service (selector: version=v2)] --> [绿色 ReplicaSet (v2, 100% 流量)]
                                      |
                                      +--> [蓝色 ReplicaSet (v1, 0% 流量， 备用回滚)]

优点：发布和回滚速度快、风险低、发布期间服务始终可用。 缺点：需要两倍的硬件资源，在切换瞬间可能会有短暂的流量处理问题（如连接中断）。

2. 金丝雀发布原理

金丝雀发布的核心思想是逐步将流量从旧版本迁移到新版本，而不是一次性切换。这个过程允许在影响一小部分用户的情况下，验证新版本的稳定性和性能。

工作原理

  1. 初始状态：

    • 与蓝绿部署类似，当前稳定版本（v1）的 ReplicaSet 承载 100% 的流量。

  2. 发布金丝雀版本：

    • Argo Rollouts 创建一个新版本（v2）的 ReplicaSet，但只启动少量 Pod（例如，副本数为总体的 1/10）。
    • 此时，通过 流量治理工具（如 Service Mesh：Istio, Linkerd；或 Ingress Controller：Nginx）的规则，将一小部分生产流量（例如 10%）路由到 v2 的 Pod，其余 90% 的流量仍然流向 v1。

  3. 渐进式推广：

    • 这是一个多步骤、自动化的过程。Argo Rollouts 的 Rollout CRD 可以定义一个详细的步骤清单（steps）。
    • 示例步骤：
      • setWeight: 10 - 将 10% 的流量切到 v2，持续 5 分钟。
      • pause: {duration: 5m} - 暂停发布，观察 v2 的运行指标。
      • setWeight: 40 - 如果一切正常，将流量提升到 40%。
      • pause: {duration: 10m} - 再次暂停并观察。
      • setWeight: 100 - 最终将所有流量切换到 v2。

  4. 自动化分析与回滚：

    • 这是 Argo Rollouts 最强大的功能之一。在每次暂停（pause）阶段，它会持续查询指标分析服务。
    • 指标分析服务 可以配置一系列规则（AnalysisTemplate），例如：
      • 检查 HTTP 请求错误率是否低于 1%。
      • 检查请求平均响应时间是否小于 200ms。
      • 检查自定义业务指标（如订单失败率）。
    • 如果任何一项指标不达标，Argo Rollouts 会自动中止发布并将流量全部回滚到 v1 版本，无需人工干预。

  5. 发布完成：

    • 当所有步骤顺利完成，v2 的 ReplicaSet 将接管 100% 的流量，v1 的 ReplicaSet 最终会被缩容至零。

原理示意图

[用户] --> [Istio VirtualService] -- 90% --> [v1 ReplicaSet]
                     |
                     +-- 10% --> [v2 ReplicaSet (金丝雀)]

（推广中）

[用户] --> [Istio VirtualService] -- 40% --> [v1 ReplicaSet]
                     |
                     +-- 60% --> [v2 ReplicaSet (金丝雀)]

（完成后）

[用户] --> [Istio VirtualService] -- 100% --> [v2 ReplicaSet]

优点：发布风险极低，可以基于真实流量和指标进行自动化验证，实现“无人值守”的安全发布。 缺点：发布流程更长，需要与复杂的流量治理工具集成。

总结与核心价值

特性蓝绿部署金丝雀发布
核心思想全量切换，环境隔离渐进式流量切换
流量控制100% 或 0%，原子操作精细的比例控制（1%, 5%, 50%…）
资源消耗高（需要两套完整环境）低（新旧版本 Pod 共享资源池）
发布速度快（切换迅速）慢（分多个阶段）
风险控制通过快速回滚控制风险通过小范围暴露和自动化分析控制风险
自动化相对简单，主要自动化切换高度自动化，依赖指标分析进行决策

Argo Rollouts 的核心原理价值在于：

  1. 声明式：像定义 Kubernetes Deployment 一样，通过 YAML 文件声明你的发布策略（蓝绿或金丝雀步骤）。
  2. 控制器模式：Argo Rollouts 控制器持续监听 Rollout 对象的状态，并驱动整个系统（K8s API、Service Mesh、Metrics Server）达到声明的目标状态。
  3. 扩展性：通过 CRD 和 AnalysisTemplate，它提供了极大的灵活性，可以与任何兼容的流量提供商和指标系统集成。
  4. 自动化与安全：将“人脑判断”转化为“基于数据的自动化规则”，极大地提升了发布的可靠性和效率，是实现 GitOps 和持续交付的关键一环。