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/