Argo Rollouts 概述

Argo Rollouts 是一个 Kubernetes 控制器和一组 CRD，为 Kubernetes 提供高级部署功能，例如蓝绿、金丝雀、金丝雀分析、experimentation和渐进式交付功能。

Argo Rollouts（可选）与Ingress Controller和服务网格集成，利用其流量治理功能在更新期间逐渐将流量转移到新版本。此外，Rollouts可以查询和解释来自指标多种指标系统，以验证关键 KPI 并在更新期间推动自动升级或回滚。

Argo Rollouts 功能

1. 蓝绿更新策略
2. 金丝雀更新策略
3. 细粒度、加权流量转移
4. 自动回滚和迁移
5. 可定制的业务KPI指标查询与分析
6. Ingress Controller集成：NGINX、ALB、Apache APISIX
7. 服务网格集成：Istio、Linkerd、SMI
8. 指标系统集成：Prometheus、Wavefront、Kayenta、Web、Kubernetes Jobs、Datadog、New Relic、Graphite、InfluxDB
...

Argo Rollouts 概念

Rollout

Rollout 是 Kubernetes 工作负载资源，相当于 Kubernetes Deployment 对象。它的目的是在需要更高级的部署或渐进式交付功能的情况下替换 Deployment 对象。Rollout 提供了 Kubernetes Deployment 无法提供的以下功能：

1. 蓝绿部署
2. 金丝雀部署
3. 与Ingress Controller和服务网格集成以实现高级流量路由
4. 与蓝绿和金丝雀分析的指标系统集成
5. 根据成功或失败的指标自动升级或回滚
6. 渐进式交付

渐进式交付

渐进式交付是以受控、渐进的方式发布产品更新的过程，从而降低发布风险，通常结合自动化和指标分析来驱动更新的自动升级或回滚。

渐进式交付通常被描述为持续交付的演变，将 CI/CD 中的速度优势扩展到部署过程。这是通过将新版本的曝光限制在一小部分用户、观察和分析正确行为，然后逐步增加对越来越广泛的受众的曝光，同时不断验证正确性来实现的。

Argo Rollouts 部署策略

滚动更新

RollingUpdate 会慢慢用新版本替换旧版本。随着新版本的出现，旧版本的规模会缩小，以维持应用程序的总体数量。这是 Deployment 对象的默认策略。

重新创建

重新创建部署会在启动新版本之前删除应用程序的旧版本。因此，这可以确保应用程序的两个版本永远不会同时运行，但在部署期间会出现停机。

Blue-Green

蓝绿部署（有时称为Red-Black）同时部署应用程序的新版本和旧版本。在此期间，只有旧版本的应用程序才会收到生产流量。这允许开发人员在将实时流量切换到新版本之前对新版本运行测试。

Canary

金丝雀部署将一部分用户暴露给新版本的应用程序，同时将其余流量提供给旧版本。一旦新版本被验证正确，新版本就可以逐步替代旧版本。Ingress Controller和服务网格（例如 NGINX 和 Istio）可以为金丝雀提供比本地可用的更复杂的流量治理模式（例如，实现非常细粒度的流量分割，或基于 HTTP 标头的分割）。

Argo Rollouts 架构

Argo Rollouts 架构组件

Argo Rollout主要由Argo Rollout Controller、Rollout CRD、ReplicaSet、Ingress/Service、AnalysisTemplate/AnalysisRun、Metric providers和CLI/GUI等组件构成

Argo Rollout Controller

这是监视集群事件的主控制器，并在 Rollout 类型的资源发生更改时做出反应。控制器将读取所有详细信息，并使集群达到定义中描述的相同状态。

Rollout resource

Rollout 资源是由 Argo Rollouts 引入和管理的自定义 Kubernetes 资源。它主要与原生 Kubernetes 部署资源兼容，但具有控制高级部署方法（例如金丝雀和蓝/绿部署）的阶段、阈值和方法的额外字段

并不会对Kubernetes Deployment施加任何影响，或要使用Rollout的功能，用户需要手动将资源从Deployment迁移至Rollout。

Replica sets for old and new version

这些是标准 Kubernetes ReplicaSet 资源的实例。 Argo Rollouts 在其上添加了一些额外的元数据，以便跟踪应用程序的不同版本。

另请注意，参与 Rollout 的副本集完全由控制器以自动方式管理。不应该使用外部工具篡改它们。

Ingress/Service

这是来自实时用户的流量进入集群并重定向到适当版本的机制。 Argo Rollouts 使用标准 Kubernetes 服务资源，但需要一些额外的元数据进行管理。

针对 Canary 部署，Argo Rollouts 支持多种服务网格和Ingress解决方案，用于按特定百分比分割流量，而不是基于 Pod 数量进行简单平衡，并且可以同时使用多个路由providers。

AnalysisTemplate and AnalysisRun

Analysis是将 Rollout 连接到Metric Provider并为某些指标定义特定阈值的功能，这些阈值将决定更新是否成功。对于每项分析，您可以定义一个或多个指标查询及其预期结果。如果指标查询良好，则rollout将自行进行；如果指标显示失败，则自动回滚；如果指标无法提供成功/失败的结果，则暂停推出。

为了执行Analysis，Argo Rollouts 提供两个自定义 Kubernetes 资源：AnalysisTemplate 和 AnalysisRun。

AnalysisTemplate 包含有关要查询哪些指标的说明。附加到 Rollout 的实际结果是 AnalysisRun 自定义资源。您可以在特定 Rollout 上定义 AnalysisTemplate，也可以在集群上全局定义 AnalysisTemplate，以供多个 Rollout 共享作为 ClusterAnalysisTemplate。 AnalysisRun 资源的范围仅限于特定的部署。

Metric providers

Argo Rollouts 包括多个流行指标系统的集成，可以在分析资源中使用这些指标系统来自动升级或回滚部署。

CLI 和 UI

可以使用Argo Rollouts CLI或集成 UI查看和管理 Rollouts。

Argo Rollouts 工作机制

与Deployment相似，Argo Rollouts控制器借助于ReplicaSet完成应用的创建、缩放和删除；这些 ReplicaSet 由 Rollout 资源内的 spec.template 字段定义，该字段使用与deployment对象相同的 pod 模板。

当spec.template发生变化时，会向Argo Rollouts控制器发出信号，表明将引入新的ReplicaSet。控制器将使用spec.strategy字段中设置的策略来确定从旧ReplicaSet到新ReplicaSet的部署将如何进行。一旦新的 ReplicaSet 被扩展（并且可以选择通过分析），控制器会将其标记为“stable”。

如果在从稳定的 ReplicaSet 过渡到新的 ReplicaSet 期间，spec.template 发生另一个更改（即，您在rollout过程中更改应用程序版本），则之前的新 ReplicaSet 将缩小，控制器将尝试继续反映更新后的spec.template字段的ReplicasSet。

参考文档

https://argoproj.github.io/argo-rollouts/