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 能力。此外，也希望社区用户能够加入进来，我们一起在应用交付领域做更多的扩展。

• Github：
  https://github.com/openkruise...
• Official：
  https://openkruise.io/
• Slack:
  https://kruise-workspace.slac...

扫码加入社区交流钉钉群

戳此处，查看 OpenKruise 项目 github 主页！