亲眼看金丝雀真的滚起来

本实验运行在真正的 Argo Rollouts 上

VM 中实际运行着 Rollouts 控制器。Pod 会真正启动，分析会创建 Job 来作出判定，并在失败时真正回滚。

前一模块的 Rollouts 实验运行在模拟集群中。由于 Pod 不会启动，无法观察金丝雀占多少比例；更重要的是，分析根本不会运行—— 分析需要创建 Job 并根据其结果作出判定，而 Job 无法运行，也就无从判定。 自动回滚是 CAPA 的核心，但此前的实验完全缺少这一环。

首次启动大约需要 3 分钟。

已准备的环境

네임스페이스   demo
컨트롤러       argo-rollouts 네임스페이스
CLI            kubectl argo rollouts
미리 받은 이미지 argoproj/rollouts-demo 의 blue · yellow · red, busybox:1.36

目标

从金丝雀发布到自动回滚，都通过实际运行来验证。

步骤

创建 Rollout，并将首次发布的不同之处记录到 /root/capa/first.txt。
更换镜像，并将金丝雀以实际 Pod 数量呈现的结果记录到 /root/capa/canary.txt。
继续已暂停的发布，并将过程记录到 /root/capa/promote.txt。
添加成功的分析，并将通过结果记录到 /root/capa/analysis.txt。
通过失败的分析触发自动回滚，并将结果记录到 /root/capa/rollback.txt。
将 abort 与 undo 的区别记录到 /root/capa/abort.txt。
使用蓝绿发布让两个版本同时运行，并将结果记录到 /root/capa/bluegreen.txt。
在 /root/capa/report.md 中写入 canary_pods=、auto_rollback=yes、bluegreen_paused=yes 三行及相关说明。

参考

使用 kubectl argo rollouts -n demo get rollout <이름> 查看状态。仅用 kubectl get rollout 几乎看不到有用信息。
使用 kubectl argo rollouts -n demo set image <이름> demo=<이미지> 更换镜像。
每个步骤有 90 秒时间。将 pause 设为无限期，再用 promote 继续，可以节省等待时间。
常见错误：期待首次发布也执行金丝雀步骤。由于没有可供比较的稳定版本，系统会跳过这些步骤。
常见错误：认为回滚后 spec 也会恢复。规范仍保持不变。

首次发布会跳过金丝雀步骤

创建 Rollout，并将首次发布的不同之处记录到 /root/capa/first.txt。

如果没有可供比较的稳定版本，也就没有可以拆分的流量。

25% 对应多少个 Pod

更换镜像，并将金丝雀以实际 Pod 数量呈现的结果记录到 /root/capa/canary.txt。

权重表示流量比例，但没有流量路由时，会用 Pod 数量近似。

继续已暂停的发布

继续已暂停的发布，并将过程记录到 /root/capa/promote.txt。

promote 推进一个步骤，promote --full 则推进所有剩余步骤。

让系统代替人工作出判定

添加成功的分析，并将通过结果记录到 /root/capa/analysis.txt。

AnalysisTemplate 的 job 提供程序会创建 Job，并根据退出代码作出判定。

失败时自动回滚

通过失败的分析触发自动回滚，并将结果记录到 /root/capa/rollback.txt。

分析失败后，Rollout 会变为 Degraded 并回到稳定版本。规范仍保持不变。

abort 与 undo 并不相同

将 abort 与 undo 的区别记录到 /root/capa/abort.txt。

一个只恢复流量，另一个连规范也一起回滚。

两个版本同时运行

使用蓝绿发布让两个版本同时运行，并将结果记录到 /root/capa/bluegreen.txt。

创建 activeService 和 previewService 后，控制器会代为调整选择器。

回顾所学内容

在 /root/capa/report.md 中写入 canary_pods=、auto_rollback=yes、bluegreen_paused=yes 三行及相关说明。

写入 canary_pods=、auto_rollback=yes、bluegreen_paused=yes 三行及相关说明。