Argo Rollouts 体验

作者: ygqygq2 分类: 系统/运维,自动化,虚拟化/容器 发布时间: 2022-05-16 18:13

1. Argo Rollouts 简单介绍

Argo Rollouts 是一个 Kubernetes 控制器和一组 CRDs,它们提供了先进的部署功能,例如蓝绿色、金丝雀、金丝雀分析、实验和渐进式交付功能。

2. Argo Rollouts 安装

我使用 helm 安装官方 charts 仓库中的 argo-rollouts。安装过程略…

3. Argo Rollouts Kubectl 插件安装

4. Argo Rollouts 架构

详细介绍请查看官方文档:https://argoproj.github.io/argo-rollouts/architecture/

架构图

5. 官方示例体验

本文环境:
kubernetes: v1.23.4
istio: 1.13.3

我们使用官方getting-started测试。
其它请参考更详细的官方示例

6. 示例体验

6.1 基本使用

6.1.1 部署 rollout

部署一个 rollout 资源,然后查看运行情况

查看运行情况

查看资源情况

6.1.2 更新 rollout

rollout spec 模板和 deployment 一样,有内容修改即会触发一个新版本,kubectl argo rollouts 插件支持一个命令,set image 直接修改镜像:

更新镜像

达到20%流量暂停

可以看到 rollout 处理暂停状态,现在有 20% 的 POD 为新版本,其它为旧版本。这符合定义的 20% 金丝雀流量。

6.1.3 恢复 rollout

当前 rollout 是暂停状态,当暂停没有设置持续时间时,它将无限期保持暂停状态,直到恢复。手动恢复 rollout 插件提供了一个命令 promote

rollout恢复

后续更新步骤

pod 达到持续时间 rollout 执行下一步

全部步骤完成

promote 命令也支持跳过后续所有步骤和分析,参数为 --full

一旦所有步骤都成功完成,新的 ReplicaSet 将被票房为 "stable",无论何时,只要在更新期间中止部署(通过失败的canary或用户手动执行),部署 就会退回 "stable" 版本。

6.1.4 中断 rollout

接下来将演示手动中止 rollout,设置一个“红色”容器版本,然后等待部署到暂停步骤:

因为 rollout 在暂停状态,“red” 容器版本处于 “canary” 状态,abort rollout 将放大 ReplicaSet 的“稳定”版本,并缩小任何其他版本。尽管 ReplicaSet 的稳定版本可能正在运行并且是健康的,但是总体的部署仍然被认为是降级的,因为所需的版本(“red”镜像)不是实际正在运行的版本。

abort rollout

结果为降级的

为了使 rollout 再次被认为是健康的而不是降级的,有必要将所需的状态更改为以前的、稳定的版本。这通常涉及运行 kubectl apply 来应用以前的 rollout,以下我们只需使用前面的 “yellow” 镜像重新运行 set image 命令。

恢复稳定版本

可以看到,rollout 重新恢复健康,并且没有任何新的 ReplicaSet 创建。

6.1.5 小结

基本示例中的 rollout 没有使用入口控制器或服务网络来路由流量。它使用普通的 kubernetes service 网络(即 kube-proxy)来实现基于新旧副本计数最接近大致 canary 权重。为了实现理想细粒度的 canary,需要一个入口控制器或服务网格。

6.2 Argo Rollouts 配合 Istio 使用

前提:kubernetes 集群已经安装 Istio。(本文使用 istio 1.13)

当 Istio 被用作流量路由时,Rollout canary 策略必须定义以下强制字段:

以下为示例使用的 yaml 文件:

部署

资源情况

rollout状态

执行更新

更新

rollouts-demo-vsvc1、rollouts-demo-vsvc2 都有更新

更新了weight

更新了weight

当 Rollout 执行步骤时,将调整 HTTP 和/或 TLS 路由的目标权重,以匹配步骤的当前 setWeight

6.3 Argo Rollouts 配合 Nginx Ingress 使用

前提:kubernetes 集群已经安装 Nginx Ingress

当 NGINX Ingress 被用作流量路由时,Rollout 探测器策略必须定义以下强制字段:

canary.trafficRouting.nginx.stableIngress 中引用的入口必须具有一个主机规则,该规则具有一个针对 canary.stablervice 下引用的服务的后端。在我们的示例中,stable Service 命名为: rollouts-demo-stable:

以下为示例使用的 yaml 文件:

部署

资源情况

rollout状态

执行更新

变化

此时,Rollout 的探测器和稳定版本都在运行,5% 的流量指向 canary。需要注意的一点是,尽管只运行两个 pod,但是这款产品能够实现5% 的 canary 权重。这是能够实现的,因为流量分配发生在 ingrress 控制器(相对于加权副本数和 kube-proxy)。

在检查 rollout 控制器所生成的 ingress 副本时,我们看到它比原来的有以下变化:

  1. 2 个额外的 NGINX 指定 canary 注释添加到注释中。
  2. Ingress 规则将有一个规则,将后端指向 canary 服务。

随着 Rollout 在步骤中的进展,将调整 canary-weight 注释以匹配步骤的当前 setWeight。NGINX 入口控制器检查原始入口、金丝雀入口和金丝雀权重注释,以确定在两个入口之间分配的流量百分比。

7. 总结

Argo Rollouts 提供强大的发布功能,确实可以在一定程度上代替 deployment,能基本上满足各种发布需求,它做不到的一些功能也可以配合 istio 。
总之,随着 Argo 系列的产品逐渐完善,其将会在基于 kubernetes 的 CI/CD 中越发占有一席之地。



微信扫描下方的二维码阅读本文

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

发表回复

您的电子邮箱地址不会被公开。

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据