25|生产稳定的秘密武器:如何实施金丝雀发布?
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了金丝雀发布的概念和架构,以及如何使用 Kubernetes 原生的 Deployment 和 Service 实施金丝雀发布。通过配置生产环境的 Ingress 策略和部署金丝雀环境,读者可以了解金丝雀发布的具体操作流程。金丝雀发布不仅可以通过不同比例分发流量进行灰度验证,还可以通过识别特定请求的方式进行精准控制,提高发布的安全性和灵活性。文章还介绍了借助 Argo Rollout 的自动金丝雀发布功能,解决了手动发布方式的低效率问题。通过创建 Rollout 对象、Service 和 Ingress 对象,以及配置自动化金丝雀发布的步骤,读者可以掌握金丝雀发布的实施方法,从而在实际生产环境中应用该发布方式,提高发布的稳定性和安全性。文章还介绍了金丝雀发布的自动化原理,以及在实际业务场景中的应用和思考题。整体而言,本文详细介绍了金丝雀发布的概念、实施方法和自动化原理,对于想要深入了解和应用金丝雀发布的读者具有很高的参考价值。
《云原生架构与 GitOps 实战》,新⼈⾸单¥59
全部留言(9)
- 最新
- 精选
- FelixFly老师,请教一个问题,若是单一链路有10个微服务,可以直接实现某一个金丝雀服务调用么?还是说这10个微服务都需要部署金丝雀
作者回复: 可以实现,需要配合 Service Mesh 做动态的路由,本质上是在请求里面带上特殊的标识。
2023-02-11归属地:安徽3 - 木杉其实流程看起来很简单,但实际上需要考虑的东西还有很多,灰度发布并不是单单在cicd一侧就可以解决的,比如按照简单的50%-50%流量区分新老版本,1个浏览器的前端请求会在2个版本上换来换去,而不是同一个浏览器的请求始终路由到同一版本,会导致1个用户在2个版本不停切来切去,引发很多问题,前端是这样,后端也如此。
作者回复: 是的,一般配合条件路由策略使用。
2023-08-01归属地:广东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才起作用,但也就都是绿色的了,没有蓝色了,这个原因大概可能是什么?
作者回复: 1. Rollout 的发布过程和创建了两个 Deployment 有点类似,你可以通过 HPA 来控制副本数,参考:https://argoproj.github.io/argo-rollouts/features/hpa-support/。 2. 可以这样做。 3. 可以通过实验验证一下,抱歉我没有留意这个细节。 4. 检查 ingress 对象中定义的注解和你实际部署 nginx-ingress 实例是否一致(kubernetes.io/ingress.class: nginx),另外 ingress-nginx 的部署版本是否大于课程部署的版本。
2023-03-23归属地:北京2 - 邵涵“在手动实施蓝绿发布的过程中,如何将金丝雀环境提升为生产环境?” 这里是说手动实施“金丝雀发布”吗?如果是的话,那么一个比较快速的方式可能是将生产环境的ingress的service改为金丝雀环境的service,并将金丝雀环境的ingress的canary-weight降为0,将原生产环境的deployment的replicas降为0。不过这样做存在的问题是下次执行金丝雀发布时,不能用完全相同的标签去创建金丝雀环境的service、deployment
作者回复: 正确,操作起来是非常麻烦的。
2023-03-23归属地:北京1 - Noel ZHANG看起来这两个service是并列的交替职责的关系,并不是demo-canary的就一定分担canary pods的流量。是这样么?
作者回复: 是的,取决于 ingress 的流量调度。
2023-03-08归属地:江苏1 - ghostwritten1. 蓝绿发布相对于金丝雀发布(灰度发布)缺点是流量将进行全量切换时无法对新环境进行小规模的流量验证。 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 秒。
作者回复: 👍🏻很棒的总结。
2023-02-20归属地:北京1 - Sophia-百鑫老师好,如果canary 发布完成后,发现prod 环境有问题,需要立即回滚版本。这时的应急处理我能想到的是 修改rollout.yaml 中image 版本和修改steps 中发布策略,setWeight:100%,其他步骤都删掉。 是这样吗?是否还有其他方法?
作者回复: 可以在 ago rollout 控制台直接回滚
2023-08-10归属地:上海 - 松老师,用你的例子在华为云集群做验证,创建并查询 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我已经创建过了
作者回复: 看这个报错可能和华为云有一些特殊机制有关,我暂时也没有排查思路。金丝雀实验不依赖云厂商的服务,你可以尝试本地的 KiND 集群来实验,另外也可以提交一个工单让云厂商帮忙排查。
2023-02-15归属地:天津 - yuer老师,原生的k8s实现金丝雀的发部方式,也可以通过写脚本完成自动化发部。
作者回复: 可以的,只是比较麻烦,而且自己写的脚本不一定能很好地支持幂等。
2023-02-13归属地:北京