25｜生产稳定的秘密武器：如何实施金丝雀发布？

老师，请教一个问题，若是单一链路有10个微服务，可以直接实现某一个金丝雀服务调用么？还是说这10个微服务都需要部署金丝雀

其实流程看起来很简单，但实际上需要考虑的东西还有很多，灰度发布并不是单单在cicd一侧就可以解决的，比如按照简单的50%-50%流量区分新老版本，1个浏览器的前端请求会在2个版本上换来换去，而不是同一个浏览器的请求始终路由到同一版本，会导致1个用户在2个版本不停切来切去，引发很多问题，前端是这样，后端也如此。

几个问题： 1. 使用Rollout的自动化金丝雀发布流程中，金丝雀环境里的pod数量也是和生产环境中的pod一样多？如果是，那有没有让生产环境pod数量递减、金丝雀环境pod递增的方式？就像deployment本身的更新那样渐进式更新pod、pod总量几乎不变 2. 如果只使用header的转发规则，不使用百分比权重的方式，那在strategy.canary.steps下，是就只定义pause就可以了？ 3. 自动化金丝雀发布过程中，Argo Rollout自动为金丝雀环境创建的ingress，在其nginx.ingress.kubernetes.io/canary-weight将为0之后，会被删除吗？还是留给下次金丝雀发布复用？ 4. 对于手动金丝雀发布的例子，我实验的结果是后创建的金丝雀环境的ingress不起作用，一直都是蓝色的，只有删掉生产环境的ingress，金丝雀环境的ingress才起作用，但也就都是绿色的了，没有蓝色了，这个原因大概可能是什么？

“在手动实施蓝绿发布的过程中，如何将金丝雀环境提升为生产环境？” 这里是说手动实施“金丝雀发布”吗？如果是的话，那么一个比较快速的方式可能是将生产环境的ingress的service改为金丝雀环境的service，并将金丝雀环境的ingress的canary-weight降为0，将原生产环境的deployment的replicas降为0。不过这样做存在的问题是下次执行金丝雀发布时，不能用完全相同的标签去创建金丝雀环境的service、deployment

看起来这两个service是并列的交替职责的关系，并不是demo-canary的就一定分担canary pods的流量。是这样么？

1. 蓝绿发布相对于金丝雀发布（灰度发布）缺点是流量将进行全量切换时无法对新环境进行小规模的流量验证。 2. 手动进行金丝雀发布部署对象是deployment，重点是在Ingress配置策略。 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: canary-ingress-canary annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "20" nginx.ingress.kubernetes.io/canary-by-header: "X-Canary" 3. 自动化金丝雀发布重点是crd——Rollout 对象。可以自定义配置发布策略。 strategy: canary: canaryService: canary-demo-canary stableService: canary-demo canaryMetadata: labels: deployment: canary stableMetadata: labels: deployment: stable trafficRouting: nginx: stableIngress: canary-demo additionalIngressAnnotations: canary-by-header: X-Canary steps: - setWeight: 20 - pause: {} - setWeight: 50 - pause: duration: 30s - setWeight: 70 - pause: duration: 30s 4. 重点金丝雀配置理解： canaryService 表示金丝雀 Service 的名称，我们会在稍后创建它。 stableService 表示生产环境 Service 的名称，同样也需要在稍后创建。 canaryMetadata 和 stableMetadata 字段表示在金丝雀发布时，会将额外的标签增加到 Pod 中，它可以区分不同环境的 Pod。 trafficRouting.nginx 字段表示使用 Ingress-Nginx 来管理流量 trafficRouting.nginx.stableIngress 字段用来指定 Ingress 名称，这个 Ingress 需要我们提前创建。trafficRouting.nginx.additionalIngressAnnotations 字段用来配置特定的金丝雀流量识别策略，这里的含义是当请求头出现 X-Canary 时，就将流量转发到金丝雀环境中。 此外，还有一项重要的配置：canary.steps，它是用来描述如何进行自动化金丝雀发布。在这个例子中，自动化金丝雀的配置如下。 将金丝雀环境的流量比例配置为 20%。 暂停金丝雀发布，直到手动批准。 将金丝雀环境的流量比例配置为 50%，并持续 30 秒 。将金丝雀环境的流量比例配置为 70%，并持续 30 秒。

老师好，如果canary 发布完成后，发现prod 环境有问题，需要立即回滚版本。这时的应急处理我能想到的是 修改rollout.yaml 中image 版本和修改steps 中发布策略，setWeight：100%，其他步骤都删掉。 是这样吗？是否还有其他方法？

老师，用你的例子在华为云集群做验证，创建并查询 rollout 时报error creating canary ingress `canary-demo-canary-demo-canary`: ingresses.extensions "canary-demo-canary-demo-canary" is forbidden: service "canary-demo-canary" not found，能否提供一下些排查思路？canary-demo-canary我已经创建过了

老师，原生的k8s实现金丝雀的发部方式，也可以通过写脚本完成自动化发部。