Kruise Rollout(灵活可插拔的渐进式发布框架)
作者:赵明山(立衡)
前言
Kruise Rollout 是 OpenKruise 社区开源的渐进式交付框架。Kruise Rollout 支持配合流量和实例灰度的金丝雀发布、蓝绿发布、A/B Testing 发布,以及发布过程能够基于 Prometheus Metrics 指标自动化分批与暂停,并提供旁路的无感对接、兼容已有的多种工作负载(Deployment、CloneSet、DaemonSet)。
近期也在《2022 开放原子全球开源峰会》上面做了主题分享,以下是主要内容。
什么是渐进式交付?
文章图片
渐进式发布主要区别于全量、一次性发布。它主要包含以下特点:
- 增量的发布过程:通俗讲就是我们可以将一次发布分成多个批次,并且可以控制每个批次的开始与停止。
- 实例与流量双重维度的灰度:比如社区常见的金丝雀发布、A/B Testing 发布、蓝绿发布。
- 阶段可验证性:就是发布的每个批次,可以验证发布的正确性、是否符合预期。
文章图片
假如线上是 X 版本,现在需要发布到 Y 版本。首先,会将发布分为多个批次(比如,第一批只发布十个实例);然后,灰度一定规则的流量到 Y 版本,比如:像淘宝每次重大发布,会使用 A/B Testing 的方式,只将公司员工灰度到新版本;最后,验证新版本的健康情况,验证 OK 后,可以重复上述的过程,完成剩余的批次。如果在这个过程中发现了任何异常,可以快速回滚到 X 版本。通过上面这个例子,渐进式发布与全量发布相比,增加了很多中间的验证过程,渐进式发布可以说是极大的提高了交付的稳定性,尤其是针对一些大规模的场景而言,渐进式发布是非常有必要的。
渐进式发布与 K8s 工作负载之间的关系
文章图片
K8s 当中所有的 Pod 都是由工作负载来管理的,其中最常见的两个工作负载就是 Deployment 和 statefulset。Deployment 对于升级而言提供了 maxUnavailable 和 maxSurge 两个参数,但是本质上来讲 Deployment 它只支持流式的一次性发布,用户并不能控制分批。StatefulSet 虽然支持分批,但是跟我们想要的渐进式发布的能力还有比较大的距离。
文章图片
所以渐进式发布与工作负载从能力上讲是一种包含关系,它除了基础的 Pod 发布之外,还应该包含流量发布和进度控制。既然能力上已经梳理清楚了,下面我们就要看看实现,如何去设计和实现 Rollout 能力也是非常重要的。在这我们可以考虑一个问题,从设计的角度看他们也是包含关系吗?
Rollout 方案的设计理念 准备开始做这件事情前,肯定要先调研一下社区的优秀方案,看看其他人是如何解决的。
文章图片
Argo Rollout 是 Argo 公司推出的 Workload,它的实现思路是:重新定义一个类似于 Deployment 的工作负载,在实现 Deployment 原有能力的基础上,又扩展了 Rollout 的相关能力。它的优点是工作负载内置了 Rollout 能力,配置简单、实现也会比较简单,并且目前支持的功能也非常的丰富,支持各种发布策略、流量灰度和 metrics 分析,是一个比较成熟的项目。
但是它也存在一些问题,因为它本身就是一个工作负载,所以它不能适用于社区 Deployment,尤其是针对已经用 Deployment 部署的公司,需要一次线上迁移工作负载的工作。其次呢,现在社区的很多方案是依赖 Deployment 实现的,并且很多公司已经构建了基于 Deployment 的容器管理平台,都要进行兼容适配。所以,Argo-Rollout 更加适用于定制化能力较强的、没有存量 Deployment 的公司业务。
文章图片
另一个社区项目是 Flagger,它的实现思路跟 Argo-Rollout 完全不同。它没有单独的实现一个 workload,而是在现有 Deployment 的基础之上,扩展了流量灰度、分批发布的能力。
Flagger 的优势是支持原生 Deployment 、并且与社区的 Helm、Argo-CD 等方案都是兼容的。但是也存在一些问题,首先就是发布过程中的 Double Deployment 资源的问题,因为它是先升级用户部署的 Deployment,再升级 Primary,所以在这过程中需要准备双倍的 Pod 资源。第二呢,针对一些自建的容器平台需要额外对接,因为它的实现思路是将用户部署资源都 copy 一份,且更改资源的名字以及 Label。所以,Flagger 更加适合那种规模不大、基于社区方案部署、定制化较小的公司。
文章图片
另外,百花齐放是云原生的一大特点。阿里云容器团队负责整个容器平台云原生架构的演进,在应用渐进式交付领域也有强烈的需求,因此在参考社区方案以及考虑阿里内部场景的基础上,我们在设计 Rollout 过程中有以下几个目标:
1. 无侵入性:对原生的 Workload 控制器以及用户定义的 Application Yaml 定义不进行任何修改,保证原生资源的干净、一致
2. 可扩展性:通过可扩展的方式,支持 K8s Native Workload、自定义 Workload 以及 Nginx、Isito 等多种 Traffic 调度方式
3. 易用性:对用户而言开箱即用,能够非常方便的与社区 Gitops 或自建 PaaS 结合使用
Kruise Rollout 工作机制与演进
文章图片
Kruise Rollout API 设计是非常简单的,主要包含以下四个部分:
- ObjectRef:用于表明 Kruise Rollout 所作用的工作负载,例如:Deployment Name
- Strategy:定义了 Rollout 发布的过程,如上是一个金丝雀发布的示例,第一批发布 5% 的实例,并且灰度 5% 流量到新版本,待人工确认后,再进行后续发布**
- TrafficRouting:流量灰度所需要的资源 Name,例如:Service、Ingress 或 Gateway API**
- Status:用来展示 Rollout 的过程以及状态
文章图片
首先,用户基于容器平台做一次版本发布(一次发布从本质上讲就是将 K8s 资源 apply 到集群中)。
- Kruise Rollout 包含一个 webhook 组件,它会拦截用户的发布请求,然后通过修改 workload strategy 的方式 Pause 住 workload 控制器的工作。
- 然后,就是根据用户的 Rollout 定义,动态的调整 workload 的参数,比如:partition,实现 workload 的分批发布。
- 等到批次发布完成后,又会调整 ingress、service 配置,将特定的流量导入到新版本。
- 最后,Kruise Rollout 还能够通过 prometheus 中的业务指标判断发布是否正常。比如说,对于一个 web 类 http 的服务,可以校验 http 状态码是否正常。
Kruise Rollout 工作机制就先介绍到这里,下面我简单介绍一下 OpenKruise 社区。
文章图片
最后 随着 K8s 上面部署的应用日益增多,如何做到业务快速迭代与应用稳定性之间的平衡,是平台建设方必须要解决的问题。Kruise Rollout 是 OpenKruise 在渐进式交付领域的新探索,旨在解决应用交付领域的流量调度以及分批部署问题。Kruise Rollout 目前已经正式发布 v0.2.0 版本,并且与社区 OAM KubeVela 项目进行了集成,vela 用户可以通过 Addons 快速部署与使用 Rollout 能力。此外,也希望社区用户能够加入进来,我们一起在应用交付领域做更多的扩展。
- Github:
https://github.com/openkruise... - Official:
https://openkruise.io/ - Slack:
https://kruise-workspace.slac...
文章图片
【Kruise Rollout(灵活可插拔的渐进式发布框架)】戳此处,查看 OpenKruise 项目 github 主页!
推荐阅读
- 汽车出行|功能全面且操控灵活的大号暖男,试驾AITO问界M7
- 《原则》读书笔记17|《原则》读书笔记17 第二部分 生活原则(如果你拥有灵活性并自我归责,那么几乎没有什么能阻止你成功20180317)
- 资源协作服务上线,帮你实现更灵活的权限配置与资源共享
- 写出个灵活的系统竟然可以如此简单!小白也能写出高级的Java业务!
- 灵活运用WinRAR与7zip打开zip格式文件
- Win10系统灵活运用PowerShell大局部新建文件夹
- Go语言开发的灵活管理资源的开源CMDB
- win7系统技巧 电脑公司Win7纯净版系统的灵活应用技巧
- 更强大更灵活更全面丨一文搞懂DolphinDB窗口计算
- 灵活运用组策略关闭Win7系统中的Windows Update搜索驱动程序