Kruise Rollout：基于 Lua 脚本的可扩展流量调度方案

前言

Kruise Rollout[1]是 OpenKruise 社区开源的渐进式交付框架。Kruise Rollout 支持配合流量和实例灰度的金丝雀发布、蓝绿发布、A/B Testing 发布，以及发布过程能够基于 Prometheus Metrics 指标自动化分批与暂停，并提供旁路的无感对接、兼容已有的多种工作负载（Deployment、CloneSet、DaemonSet）。

目前 Kruise Rollout 新增了流量调度支持自定义资源的能力，从而更好的支持渐进式发布中的流量调度。本文将对 Kruise Rollout 所提出的方案进行介绍。

什么是渐进式发布？

渐进式发布（Progressive Delivery）是一种软件部署和发布策略，旨在逐步将新版本或功能引入生产环境，以降低风险并确保系统的稳定性。一些常见的渐进式发布形式如下：

• 金丝雀发布：在发布时会创建一个金丝雀版本的 Deployment 进行验证，当验证通过后，再进行全量的工作负载升级，并删除金丝雀版本的 Deployment。

• A/B 测试：按照一定的规则将用户流量切分成 A、B 两个不相交通路，并将导入不同版本的 Pod 实例进行处理，以此来更好地观察、对比或者灰度新版本能力。

金丝雀发布、A/B 测试和蓝绿发布都是逐步测试和评估新功能或变更的策略，它们可以根据具体的需求和场景选择适合的部署和测试策略，并结合流量灰度等技术实现逐步发布和测试新版本或功能。

为什么需要对网关资源提供支持？

Kruise Rollout 目前已经对 Gateway API 提供了支持，那么为什么还需要对不同供应商的网关资源提供支持呢？在解释这个问题之前，我们先来简单介绍一下 Gateway API。

当前社区中不同的供应商都有自己的网关资源，并提出了自己的标准，而 Kubernetes 为了提供一个统一的网关资源标准，构建标准化的，独立于供应商的 API，提出了 Gateway API。目前，尽管 Gateway API 还处于开发阶段，但已经有很多项目表示支持或计划支持 Gateway API。包括:

• Istio 是最流行的服务网格项目之一，Istio 1.9 版本计划引入实验性的 Gateway API 支持。用户可以通过 Gateway 和 HTTPRoute 资源来配置 Istio 的 Envoy 代理。
• Apache APISIX 是一个动态、实时、高性能的 API 网关，APISIX 目前支持Gateway API 规范的 v1beta1 版本，用于其 Apache APISIX Ingress Controller。
• Kong 是一个为混合云和多云环境构建的开源 API 网关，Kong 在 Kong Kubernetes Ingress Controller (KIC) 以及 Kong Gateway Operator 中支持 Gateway API。

然而由于目前 Gateway API 并不能覆盖供应商所提出网关资源的所有功能，并且仍然有大量用户使用供应商提供的网关资源，虽然用户可以通过开发 Gateway API 对网关资源进行适配，但这样的工作量较大，所以仅仅为 Gateway API 提供支持是远远不够的，尽管随着 Gateway API 特性的不断丰富，在未来，使用 Gateway API 将成为一种更加推荐的方式。因此，虽然 Kruise Rollout 目前已经提供了对 Gateway API 的支持，如何对现有供应商多种多样的网关资源提供支持仍然是一个重要的问题。

如何兼容社区多样的网关方案？

当前社区中已经存在许多广泛使用的供应商提供的网关资源，比如：Istio、Kong、Apisix 等，然而正如前文所述，这些资源的配置并没有形成统一的标准，因此无法设计出一套通用的代码对资源进行处理，这种情况给开发人员带来了一些不便和挑战。