云原生架构与 GitOps 实战
王炜
前腾讯云 CODING 架构师
5442 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 44 讲
云原生架构与 GitOps 实战
15
15
1.0x
00:00/00:00
登录|注册

24|生产稳定的秘密武器:如何实施蓝绿发布?

你好,我是王炜。今天是我们 GitOps 高级发布策略的第一课。
在之前的课程里,我们通过构建 GitOps 工作流实现了自动发布。不过,我们并没有专门去关注新老版本在做更新时是如何切换流量的,这是因为 Kubernetes 的 Service 和 Pod 滚动更新机制自动帮助我们完成了这部分的工作。
在实际的生产环境中,为了提高发布的可靠性,我们通常需要借助发布策略来更加精细地控制流量切换。在几种发布策略中,蓝绿发布是较为简单且容易理解的一种,所以,我将从它开始来介绍如何在 GitOps 工作流中实施蓝绿发布。
那么,什么是蓝绿发布呢?
蓝绿发布核心思想是:为应用提供两套环境,并且可以很方便地对它们进行流量切换。
在一次实际发布过程中,新版本的应用将以“绿色”环境部署到生产环境中,但在流量切换之前它并不接收外部流量。当我们完成“绿色”环境的测试之后,可以通过流量切换的方式让“绿色”环境接收外部请求,而旧的“蓝色”环境并不会立即销毁,而是作为灾备来使用。一旦发布过程产生故障,我们就可以将流量立即切换到旧的“蓝色”环境下。
这种部署方式比较适合那些存在兼容问题,或者因为状态原因导致不能很好地使用 Kubernetes 滚动更新的应用。还有的项目希望在更新时部署一个新的版本,同时控制流量切换过程;或者是在发布出现问题时快速回滚。蓝绿发布也是不错的选择。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《云原生架构与 GitOps 实战》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(6)

  • 最新
  • 精选
  • 争光 Alan
    我理解rollout就是给deployment做了增强,增加了一种新版本创建时老版本保留的能力 我的几个疑惑 1. 一般业务会有前段,后端,数据库,微服务更多组件,这样的应用如何进行蓝绿?rollout可以对多个deployment做蓝绿吗? 2. 新老版本共存的情况下,数据库是同一个,数据库新老版本不兼容如何处理?

    作者回复: 这两个问题都非常好。 首先文章演示的蓝绿发布实际上是南北流量的蓝绿,微服务内部的东西流量灰度需要借助 istio 服务网格来实现,当业务内部发起服务间调用时,透传灰度标识,这样才能够实现全链路的灰度。 其次数据库的灰度更复杂一些,一般的实践是多实例或者扩展 istio 协议。

    归属地:上海
    4
  • zangchao
    收获很多,很感谢老师,正好最近在做服务迁移K8s,需要实现服务的灰度发布、蓝绿发布等。想问下老师当前在K8s实现灰度发布有哪些开源库选择,Argo Rollout是否为实现K8s环境下灰度发布的最优选择?之前我们用Istio做过,最近准备放弃Istio了

    作者回复: Argo Rollout 是一个不错的选择,比较轻量。此外,Netflix 开源的 Spinnaker 也可以做灰度发布,不过比较重。 如果你的业务有很多个微服务,在不侵入业务的情况下,东西流量(微服务和微服务之间的调用)的灰度还是需要借助 Service Mesh 的。

    归属地:天津
    2
    2
  • BertGeek
    请问老师,几个问题: 阿里云ack 集群,Argo Rollout实现蓝绿发布 1. 因为deployment 改为了 Rollout,导致ack 的无状态页面无法看到pod 容器,只能在控制台容器组中看到。 2. Argo Rollout 是否可以监测镜像变化,自动发布新版本 3. Argocd + Rollout ,如何与 Kustomize 集成。

    作者回复: 1. 正常现象,你可以用 Lens 一类的 UI 工具来查看 2. Rollout 似乎不能支持这种用法 3. 查看这个文档:https://github.com/argoproj/argo-rollouts/blob/master/docs/features/kustomize.md

    归属地:上海
    1
  • 林龍
    有个疑问,蓝绿发布这里案例是通过修改ingress的Deployment中的sevice修改对应的应用。自动化构建的话是通过引入Argo Rollout,请问这个自动化构建时修改Deployment的images有什么区别,它也是会通过ReplicaSet创建新的pod,同时也是新的pod创建成功后才会慢慢销毁旧的pod

    作者回复: 蓝绿发布在升级过程会保留老的环境,核心思想冗余。

    归属地:广东
    1
  • Da Vinci
    启动了dashboard,但是获取不到rollout,看stdoutput,上面报x509: “Argo CD” certificate is not trusted,这是什么原因啊

    作者回复: 我没有遇到过,不过你可以尝试看一下这个 issues:https://github.com/argoproj/argo-cd/issues/6048

    归属地:广东
  • ghostwritten
    1. 什么是蓝绿发布? 蓝绿发布呢?蓝绿发布核心思想是:为应用提供两套环境,并且可以很方便地对它们进行流量切换。在一次实际发布过程中,新版本的应用将以“绿色”环境部署到生产环境中,但在流量切换之前它并不接收外部流量。当我们完成“绿色”环境的测试之后,可以通过流量切换的方式让“绿色”环境接收外部请求,而旧的“蓝色”环境并不会立即销毁,而是作为灾备来使用。一旦发布过程产生故障,我们就可以将流量立即切换到旧的“蓝色”环境下。 2. 手动蓝绿发布 部署两套环境,镜像tag 分别为blue、green,切换操作其实是修改ingress的 service: name: blue-service # 改为green-service 这种操作 Ingress 策略不利于将蓝绿发布和 GitOps 流水线进行整合。 3. 蓝绿发布自动化 3.1 创建命名空间 kubectl create namespace argo-rollouts 3.2 安装 argo-rollouts kubectl apply -n argo-rollouts -f https://ghproxy.com/https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml 3.3 等待 kubectl wait --for=condition=Ready pods --all -n argo-rollouts --timeout=300s 3.4 创建 Rollout 对象——blue-green-rollout.yaml 重点理解:strategy 字段是用来定义部署策略的。其中,autoPromotionEnabled 字段表示自动实施蓝绿发布,activeService 用来关联蓝绿发布的 Service,也就是我们在后续要创建的 Service 名称。 3.5 创建 Service 和 Ingress kubectl apply -f blue-green-service.yaml kubectl apply -f blue-green-ingress.yaml 3.6 切换操作对象是Rollouts,是编辑 blue-green-rollout.yaml 文件的 image 字段,将 blue 修改为 green 版本,然后kubectl apply -f blue-green-rollout.yaml 流量切换过程将由 Argo Rollout 自动控制。 3.7 访问 Argo Rollout Dashboard $ brew install argoproj/tap/kubectl-argo-rollouts 检查版本 kubectl argo rollouts version 部署dashboard kubectl argo rollouts dashboard 4. 当我们需要重新回滚到蓝色环境时,Argo Rollout 只需调整蓝色环境的 ReplicaSet 副本数并且修改 Service 的选择器,就可以回滚
    归属地:北京
收起评论
显示
设置
留言
6
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部