金丝雀、蓝绿与回退

目标

编写金丝雀和蓝绿 Rollout 清单，以及负责基于指标自动回滚的 AnalysisTemplate；同时实际部署相应的 Service 和 Deployment，亲手完成发布与回滚。

为什么重要

渐进式发布的核心有两点：‘新版本要暴露多少流量’，以及‘根据什么决定是否继续’。setWeight 回答前一个问题，analysis 回答后一个问题。没有 duration 的 pause 会把判断交给人，而 AnalysisTemplate 则把同样的判断交给指标。另一方面，回滚本身并不是 Argo Rollouts 的发明；它之所以可行，是因为 Kubernetes 会将 ReplicaSet 保留为各个修订版本。在本实验中同时操作这两个层次后，你就能分辨 Rollout 究竟在哪些方面带来了新能力。

步骤

创建 /root/capa-rollout/ 目录，并在 rollout.yaml 中填写 apiVersion argoproj.io/v1alpha1、kind Rollout、metadata.name capa-web、metadata.namespace capa-rollout、spec.replicas 4、spec.selector.matchLabels.app capa-web，容器镜像使用 nginx:1.27。
将同一文件中的 spec.strategy.canary.steps 设置为至少五个步骤：第一个步骤为 setWeight: 20，第二个为 pause: {duration: 30s}，第三个为 setWeight: 50，最后一个为 setWeight: 100。
在 /root/capa-rollout/analysistemplate.yaml 中填写 kind AnalysisTemplate、metadata.name capa-success-rate，并在 spec.metrics[0] 中填写 name success-rate、interval 30s、failureLimit 3、要求结果不低于 0.95 的 successCondition，以及 provider.prometheus.address。
将 rollout.yaml 的一个金丝雀步骤改为 analysis 步骤，使 templates[0].templateName 指向 capa-success-rate；并将 spec.strategy.canary.canaryService 指定为 capa-web-canary、stableService 指定为 capa-web-stable、trafficRouting.nginx.stableIngress 指定为 capa-web-stable。
在 /root/capa-rollout/rollout-bluegreen.yaml 中填写 kind Rollout、metadata.name capa-api，并在 spec.strategy.blueGreen 下加入 activeService capa-api-active、previewService capa-api-preview、autoPromotionEnabled false、scaleDownDelaySeconds 60。不要在此文件中同时使用 canary。
在集群中创建命名空间 capa-rollout，并在其中实际创建 Service capa-web-stable 和 capa-web-canary。两者的 type 都是 ClusterIP，spec.selector.app 都是 capa-web，端口都是 80。
在同一命名空间中实际创建 Deployment capa-web。replicas 为 4，spec.selector.matchLabels.app 为 capa-web，容器镜像为 nginx:1.27。
将 capa-web 的镜像改为一次 nginx:1.28 以创建新修订版本，然后执行回滚。最终镜像应恢复为 nginx:1.27，且修订版本号应不小于 3。

参考

使用 kubectl set image deploy/capa-web nginx=nginx:1.28 -n capa-rollout 和 kubectl rollout undo deploy/capa-web -n capa-rollout。
可以使用 kubectl rollout history deploy/capa-web -n capa-rollout 查看修订历史。
常见错误 1：以为回滚后修订版本号会减小。回滚操作本身也会被记录为一个新修订版本。
常见错误 2：在同一个 Rollout 中同时使用 canary 和 blueGreen。两种策略只能选择其一。

Rollout 基本骨架

创建 /root/capa-rollout/ 目录，并在 rollout.yaml 中填写 apiVersion argoproj.io/v1alpha1、kind Rollout、metadata.name capa-web、metadata.namespace capa-rollout、spec.replicas 4、spec.selector.matchLabels.app capa-web，容器镜像使用 nginx:1.27。

Rollout 的 spec 从 replicas、selector 到 template 都与 Deployment 几乎相同。不同之处在于 strategy 下的内容。

权重与暂停步骤

将同一文件中的 spec.strategy.canary.steps 设置为至少五个步骤：第一个步骤为 setWeight: 20，第二个为 pause: {duration: 30s}，第三个为 setWeight: 50，最后一个为 setWeight: 100。

steps 是一个数组，每个元素只包含 setWeight 或 pause 等一个键。为 pause 指定 duration 时会等待相应时长；不指定时则会无限等待，直到有人执行晋级。

编写 AnalysisTemplate

在 /root/capa-rollout/analysistemplate.yaml 中填写 kind AnalysisTemplate、metadata.name capa-success-rate，并在 spec.metrics[0] 中填写 name success-rate、interval 30s、failureLimit 3、要求结果不低于 0.95 的 successCondition，以及 provider.prometheus.address。

metrics 条目必须同时说明测量频率、成功判定标准、允许失败的次数以及数据来源。四项缺少任何一项，都无法形成完整的判断。

连接分析步骤与流量路由

将 rollout.yaml 的一个金丝雀步骤改为 analysis 步骤，使 templates[0].templateName 指向 capa-success-rate；并将 spec.strategy.canary.canaryService 指定为 capa-web-canary、stableService 指定为 capa-web-stable、trafficRouting.nginx.stableIngress 指定为 capa-web-stable。

analysis 步骤通过 templates 数组引用 AnalysisTemplate 的名称。要真正按比例分配流量，还必须把金丝雀服务和稳定服务的名称告诉控制器。

蓝绿策略

在 /root/capa-rollout/rollout-bluegreen.yaml 中填写 kind Rollout、metadata.name capa-api，并在 spec.strategy.blueGreen 下加入 activeService capa-api-active、previewService capa-api-preview、autoPromotionEnabled false、scaleDownDelaySeconds 60。不要在此文件中同时使用 canary。

蓝绿发布会先完整启动新版本，只允许通过 preview 访问，随后再切换 active。分别有一个字段用于关闭自动晋级，另一个字段用于决定旧版本保留多久。

创建稳定版与金丝雀版两个服务

在集群中创建命名空间 capa-rollout，并在其中实际创建 Service capa-web-stable 和 capa-web-canary。两者的 type 都是 ClusterIP，spec.selector.app 都是 capa-web，端口都是 80。

从这里开始操作真实集群。两个服务可以使用相同的选择器，控制器稍后会修改选择器来划分流量。

部署对应的 Deployment

在同一命名空间中实际创建 Deployment capa-web。replicas 为 4，spec.selector.matchLabels.app 为 capa-web，容器镜像为 nginx:1.27。

必须为 Pod 模板添加与服务选择器相同的标签，服务才能找到端点。副本数应与 Rollout 文件保持一致。

升级后再回滚

将 capa-web 的镜像改为一次 nginx:1.28 以创建新修订版本，然后执行回滚。最终镜像应恢复为 nginx:1.27，且修订版本号应不小于 3。

先更换一次镜像创建新修订版本，再执行回滚。请确认回滚后修订版本号不会减小，而是继续增加。