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 的过程以及状态
接下来介绍一下 Kruise Rollout 的工作机制。
首先,用户基于容器平台做一次版本发布(一次发布从本质上讲就是将 K8s 资源 apply 到集群中)。
-
Kruise Rollout 包含一个 webhook 组件,它会拦截用户的发布请求,然后通过修改 workload strategy 的方式 Pause 住 workload 控制器的工作。
-
然后,就是根据用户的 Rollout 定义,动态的调整 workload 的参数,比如:partition,实现 workload 的分批发布。
-
等到批次发布完成后,又会调整 ingress、service 配置,将特定的流量导入到新版本。
-
最后,Kruise Rollout 还能够通过 prometheus 中的业务指标判断发布是否正常。比如说,对于一个 web 类 http 的服务,可以校验 http 状态码是否正常。
上面的过程,就完成了第一批次的灰度,后面的批次也是类似的。完整的 Rollout 过程结束后,kruise 会将 workload 等资源的配置恢复回来。 所以说,整个 Rollout 过程,是与现有工作负载能力的一种协同,它尽量复用工作负载的能力,又做到了非 Rollout 过程的零入侵。
Kruise Rollout 工作机制就先介绍到这里,下面我简单介绍一下 OpenKruise 社区。
最后
随着 K8s 上面部署的应用日益增多,如何做到业务快速迭代与应用稳定性之间的平衡,是平台建设方必须要解决的问题。Kruise Rollout 是 OpenKruise 在渐进式交付领域的新探索,旨在解决应用交付领域的流量调度以及分批部署问题。Kruise Rollout 目前已经正式发布 v0.2.0 版本,并且与社区 OAM KubeVela 项目进行了集成,vela 用户可以通过 Addons 快速部署与使用 Rollout 能力。此外,也希望社区用户能够加入进来,我们一起在应用交付领域做更多的扩展。
-
Official:
https://openkruise.io/
扫码加入社区交流钉钉群
戳此处,查看 OpenKruise 项目 github 主页!