> 作者：明昼

## 前言

Kruise Rollout 是 OpenKruise 社区开源提出的一个渐进式交付框架。其设计理念是提供一组能够将流量发布与实例灰度相结合，支持金丝雀、蓝绿、A/B Testing等多样化发布形式，以及支持基于 Prometheus Metrics 等自定义 Metrics 实现发布过程自动化，无感对接、易扩展的旁路式标准 Kubernetes 发布组件。

> <https://github.com/openkruise/rollouts>

在最新发布的 Kruise Rollout 0.3.0 版本中，我们为大家带来了几个非常有趣的新特性：一是针对 Kubernetes 社区应用最为广泛的 Deployment 工作负载的发布能力进行了重磅增强；二是对流量灰度能力进行了进一步扩展；三是支持以插入 Lua 脚本的方式来支持更多网关协议的扩展：

-   **Deployment 分批发布**：Deployment 能够像 StatefulSet 或 CloneSet 一样具有分批发布 Pod 的能力。

-   **基于 Header&Cookie 南北向流量灰度**：允许用户在发布时对七层流量按照 Header&Cookie 匹配规则进行划分，并将不同流量群体导入不同版本实例，以便对新特性进行 A/B Testing 或进行更细粒度的流量调度。

-   **基于 Lua 脚本的 Ingress 流量扩展**：允许用户以配置 Lua 脚本的方式，为更多类型的流量组件制定 Kruise Rollout 插件，支持更多类型的 Ingress 扩展协议。

## 概念说明

在介绍新特性之前，让我们先一起梳理一下目前 Kubernetes 工作负载主流的发布形式：

-   **滚动升级**：原生 Deployment 自带的主流发布模式，流式滚动升级，无法设置卡点。

<!---->

-   -   优势：发布效率高；

    -   劣势：爆炸半径大，容易出现大规模发布故障。

<!---->

-   **金丝雀发布**：Flagger 和 Kruise Rollout 等组件都支持的一种针对 Deployment 的发布模式，在发布时会创建一个金丝雀版本的 Deployment 进行验证，当验证通过后，再进行全量的工作负载升级，并删除金丝雀版本的 Deployment。

<!---->

-   -   优势：回滚无需重建或重新发布 Pod，所以回滚非常快速和方便；

    -   劣势：发布时需要额外的资源消耗，并且需要重复发布新版本 Pod，发布时不能完全兼容 HPA。


*图 1：金丝雀发布方式*

-   **标准分批发布**：借助类似 StatefulSet 或 CloneSet 提供的 Partition 能力完成的标准形式的分批发布，发布时始终保持原工作负载名称等元属性不变，并且不会裂变出其他工作负载。

<!---->

-   -   优势：发布不浪费资源，可控制爆炸半径，可完全兼容 HPA 等需要 Ref 工作负载的其他组件；

    -   劣势：Deployment 很难支持此类型发布（目前仅知 Kruise Rollout 支持 Deployment 进行此类型发布）。


*图 2：标准分批发布方式*

-   **非标准分批发布**：由于 Deployment 原生逻辑无法支持分批能力，所以像 KubeVela 等社区提出的 Rollout 方案，使用的是两个 Deployment 滚动的形式进行发布。每次发布时都会创建新的 Deployment，并且对 Deployment 扩容的同时，缩容旧的 Deployment，相当于每次发布完成后 Deployment 都会被替换。

-   -   优势：发布时不需要额外资源，可控制爆炸半径；

    -   劣势：发布时会裂变多个工作负载导致缺少统一控制平面，容易造成发布和扩缩动作相冲突，难以兼容 HPA 等场景，容易造成发布卡单。


*图 3：非标准分批发布方式*

-   **A/B Testing**：按照一定的规则将用户流量切分成 A、B 两个不相交通路，并将导入不同版本的 Pod 实例进行处理，以此来更好地观察、对比或者灰度新版本能力。一般来说，A/B Testing 需要结合金丝雀发布或分批发布进行。


*图 4：A/B Testing*

## 方案对比

对于上述发布形式，除了 Deployment 自带的滚动升级“一把梭”的方式不需要依靠其他三方组件之外，其余发布方式或多或少都需要依靠其他组件或上层 PaaS 平台的能力支持。那么 Kruise Rollout 作为其中的一种解决方案，与其他方案相比，又有何优缺点？下面我们比较了开源社区目前相对较为流行的两种解决方案：Flux 社区提出的 **Flagger **[** **1]** **，以及 Argo 社区提出的 **Argo-Rollout** **[** **2]** ：


总的来说，Kruise-Rollout 的优势可以总结为以下几点：

-   **灵活性**：具备旁路式可插拔能力，即，当用户下发 Kruise Rollout 配置后，对应的 Deployment 会立刻具有标准分批发布的能力；当用户不在需要该能力时，可随时删除 Kruise Rollout 配置（甚至在发布过程中也可以删除），Deployment 立刻会恢复至原生滚动发布行为。

-   **兼容性**：完美兼容 HPA 或其他需要 Ref Workload 的三方组件;

-   **接入简便**：由于 Kruise Rollout 极具灵活性，用户只需要下发配置即可生效，**用户无需做任何 Pod 或 Workload 的迁移工作，对存量运行时容器无影响，不影响扩缩容链路，故接入相对十分简便。**

## 特性介绍

在介绍新特性之前，再啰嗦一下为什么 OpenKruise 社区要执着于做 Rollout 这件事情。

-   我们知道在 Kubernetes 中，容器生命周期与流量生命周期异步管理的设计使得 Deployment 本身无法感知流量的挂载与卸载，我们曾遇到某客户在一次 Deployment 流式滚动升级过程中，流量组件出现异常，导致流量全部挂空的事故，虽然只有短短十几分钟，但却也造成了非常大的损失。

-   业务逻辑导致的 Bug 在 Deployment 流式滚动更新的发布阶段无法感知，一旦全量上线后，可能会造成严重故障，很难控制故障的爆炸半径（因为 Deployment 滚动升级只要 Pod 可用就会全量发布）。

-   我们也经常遇到在测试环境中跑的好好的，为什么到了生产却不行了之类的问题。其实只靠环境隔离解决不了所有问题，生产发布环境最好还是不要升级“一把梭 哈”，循序渐进才能“一步一个脚印”。

上述场景如果使用分批的发布形式，其实是可以尽可能地将问题的爆炸半径控制在灰度范围之内，并且可以留下充足的灰度和观察的时间。然而，Deployment 原生逻辑并不支持分批操作，但如果使用 Argo-Rollout，还需要把所有工作负载和 Pod 进行迁移，风险太高，而且适配也太麻烦；如果使用 Flagger，仍然要迁移 Pod，并且发布时候还需要双倍资源，代价也太高。

这时候，你需要的可能是 Kruise-Rollout ！**仅需两步，就可以让你的存量 Deployment 立刻具备标准分批发布能力！**

### 新特性一：教你玩转 Deployment 标准分批发布

#### 前置步骤

存量或新建 Kubernetes 集群并要求：

-   Kubernetes version >= 1.19

> 注：该版本要求主要是 Ingress API 在 1.19 有较大变动所引起，如果你不需要复杂的流量灰度的能力（即不需要配置 TrafficRouting 字段），可以自行拉取和修改 charts，来规避该版本要求。

#### 步骤一：一键安装 Kruise-Rollout

$ helm install kruise-rollout openkruise/kruise-rollout --version 0.3.0

#### 步骤二：为你的 Deployment 绑定并下发分批发布规则

```

cat <<EOF | kubectl apply -f -

apiVersion: rollouts.kruise.io/v1alpha1

kind: Rollout

metadata:

  name: rollouts-demo

  namespace: default

  annotations:

    rollouts.kruise.io/rolling-style: partition

spec:

  objectRef:  # 绑定你的 Deployment

    workloadRef:

      apiVersion: apps/v1

      kind: Deployment

      name: echoserver

  strategy:   # 制定你的分批发布规则

    canary:

      steps:

      - replicas: 1     #第一批发一个 Pod，发布完后暂停，手动确认后进入下一批

      - replicas: 60%   #第二批发60% Pod，发布完后暂停，手动确认后进入下一批

      - replicas: 100 %  #第三批发全量 Pod，最后一批发布完后默认自动完成

EOF

```

#### 步骤三：玩转 Deployment 的分批发布

如此一来，当你后续进行发布时，Deployment 的流式滚动升级将会直接变为分批发布。下面我们以一个名为 echoserver 的 Deployment 为例，描述一次分批发布过程。

##### **1. 发布前**

检查一下 Deployment 副本数为 5，当前版本为 789b88f977：


##### **2. 开始发布第一批**

此时，我们修改容器的某个环境变量来触发发布，可以看到第一批只发布了一个 Pod，版本号为 d8db56c5b：


##### **3. 继续发布第二批**

第一批 Pod 发布完毕后，此时假设我们已经完成第一批的验证，想要继续发第二批 Pod，我们可以借助 kubectl-kruise 这个命令行工具来进行批次完成的确认操作。该工具是基于 kubectl 的拓展，目前也是由 OpenKruise 社区维护。


注：确认发下一批的命令为 kubectl-kruise rollout approve rollout/rollouts-demo

从上述过程可以看出，在该批次发布过程中且未完成时，Rollout 会进入 StepUpgrade 状态，而当该批次发布完成，会转变成 StepPaused 状态。

##### **4. 发布最后一批**

当第二批发布确认完成后，发最后一批后，Rollout 会进入 Completed 状态，表示发布完成：


特别要说明的是，在分批发布的**单个发布批次内，我们仍然会遵循流式滚动发布的规则**，也就是说你仍然可以通过调整 Deployment 的MaxUnavailable和MaxSurge来兼顾你发布时的稳定性和效率，例如在以下场景，你依然可以遵循 Deployment 的如下配置：

-   单个批次内必须**先扩后缩**，最 大程度保证**发布稳定**：

```

kind: Deployment

spec:

  strategy:

    rollingUpdate: 

      maxUnavailble: 0

      maxSurge: 20%

```

-   单个批次内必须**先缩后扩**，最 大程度**节省** **资源占用**：

```

kind: Deployment

spec:

  strategy:

    rollingUpdate: 

      maxUnavailble: 20%

      maxSurge: 0

```

-   单个批次内**边扩遍缩**，最 大程度**提高发布效率**：

 

```

kind: Deployment

spec:

  strategy:

    rollingUpdate: 

      maxUnavailble: 25%

      maxSurge: 25%

```

此外，该方案还充分考虑了各种发布场景，最 大程度地提高方案的灵活性：

-   **连续发布场景**：v1 到 v2 的发布过程中（v2 未发布完成），又发布了 v3，此时 v3 仍然会从第一批开始走标准分批发布流程；

-   **快速回滚场景**：v1 到 v2 发布到中途，回滚回 v1，则会进行快速回滚，默认不再进行分批发布。

-   **发布策略删除**：无论是在发布完成后，甚至是在发布过程中，正常删除 Rollout 资源后，相应的 Deployment 都会无缝回退至流式滚动发布场景，方便某些特殊情况下快速进行变更。

### 新特性二：基于 Header&Cookie 的流量灰度

在 Kruise-Rollout 0.3.0 之前的版本中，我们提供了基于调整流量权重 （Weight） 的流量灰度方案，但是考虑到在实际大多数场景中，各类 Ingress 等本身已经具备的载均衡能力就能满足日常流量灰度的需求，例如 10% 的 canary 副本本身就会默认打入 10% 的流量，如果不是特殊的精细化流量调整场景（ 例如 10% 的 canary 副本只导入 1% 流量），一般不需要单独配置该能力。

但是，对于一些发布敏感性业务，是可能需要 A/B Test 等这类特殊的发布形式：即在发布时，需先将特定的一批带有标记的流量，定向导入新版本 Pod，将新旧版本的流量进行隔离，比如如下场景：

-   业务新特性只对白名单用户开放，可以很大程度减少业务新特性的不确定性带来的风险；

-   将新旧两个版本进行流量隔离，方便进行对照实验，更好地观察新版本特性的有效性；

对于 Kruise-Rollout 的用户来说，可以通过以下配置来开启该能力：

```

apiVersion: rollouts.kruise.io/v1alpha1

kind: Rollout

metadata:

  name: rollouts-demo

  namespace: default

  annotations:

    rollouts.kruise.io/rolling-style: partition

spec:

  objectRef:

    workloadRef:

      apiVersion: apps/v1

      kind: Deployment

      name: echoserver

  strategy:

    canary:

      steps:

      - matches:   #设置 header&cookie 匹配规则

        - headers:

          - name: UserAgent

            type: Exact

            value: iOS

        pause: {}

        replicas: 1

      - replicas: 50%

      - replicas: 100 %

      trafficRoutings:

      - ingress:

          classType: nginx

          name: echoserver

        service: echoserver

```

上述相较于单纯的分批发布配置，多了 Header & Cookie 匹配规则的描述，以及 TrafficRouting 的引用，这里是以 Ingress-Nginx 为例进行的配置，也就是说，想要使用该能力，相应的 Ingress 控制器必须要具备该基础能力（可以理解为 Nginx 提供数据面的能力，Kruise-Rollout 提供管控面的能力）。

在该配置下，假设有副本数量为 10 的 Deployment，则其将被划分为三批进行发布，具体行为如下：

-   第一批共计有 1 个新版本 Pod，9 个旧版本Pod， 并且指定满足 UserAgent=iOS 这一匹配规则的用户流量才会打入新版本 Pod，其余流量会均匀打入剩余 9 个旧版本 Pod；

-   第二批共计有 5 个新版本 Pod，5 个旧版本Pod，并且取消流量匹配规则，流量直接全部走负载均衡策略；

-   第三批共计有 10个新版本 Pod，0 个旧版本Pod，并且取消流量匹配规则，流量直接全部走负载均衡策略；

### 新特性三：基于Lua脚本的Ingress流量扩展方案

云原生技术发展到今天，云原生网关也呈现出百花齐放的状态，除了 Kubernetes 原生提供的 Nginx Ingress 以及 Gateway API之外，也存在着非常多的 Network Provider 方案，比如阿里云 ALB、MSE、ASM；社区的 Istio、Kong、Apisix ，甚至是许多公司是自研网关方案和协议等等。Kruise Rollout 设计之初就考虑过百花齐放的云原生网关应该如何支持，常规的硬编码的方式既费时费力，也不方便不同公司的同学对接使用和维护。

最终，Kruise Rollout 选择基于Lua脚本的方式，让用户以插件化的形式支持更多类型的网关协议（此版本只支持基于 Ingress 的扩展协议，其它自定义资源协议将在下个版本支持），Kruise Rollout 完成一些通用部分的能力，而不同 NetWork Provider 的具体实现则由 Lua 脚本来解决，这样针对不同的实现，只需要编写对应的 Lua 脚本即可，可参考：**Nginx与Alb Lua脚本示例 **[** **3]** **。为了方便大家根据自己的需求编写自己的Lua脚本，下面针对 Nginx Ingress 解读一下lua脚本（对应的 Rollout 配置可以参考 新特性二），该脚本可以放置于特定目录或特定ConfigMap：


```

-- 因为 Ingress 灰度发布协议都是基于 Annotations 来实现的，所以此脚本的所有操作

-- 都是修改 Annotations 到目标状态，kruise rollout会将此 annotations patch 到

-- ingress canary 资源当中

annotations = {}

-- obj.annotations 是Ingress.Annotations 此句不需要变化，固定即可

if ( obj.annotations )

then

    annotations = obj.annotations

end

-- 这是 nginx 灰度发布协议的标准，其它的实现也可以根据自己的实际情况调整

annotations["nginx.ingress.kubernetes.io/canary"] = "true"

-- nginx 的灰度发布协议变化主要是下面这些变化，为了简化多个批次间来回切换的复杂度，每次

-- 都先将这些 annotations 置空

annotations["nginx.ingress.kubernetes.io/canary-by-cookie"] = nil

annotations["nginx.ingress.kubernetes.io/canary-by-header"] = nil

annotations["nginx.ingress.kubernetes.io/canary-by-header-pattern"] = nil

annotations["nginx.ingress.kubernetes.io/canary-by-header-value"] = nil

annotations["nginx.ingress.kubernetes.io/canary-weight"] = nil

-- obj.weight 是 rollout.spec.strategy.canary.steps[x].weight

-- 代表当前批次的灰度百分比，当不设置时为 ‘-1’(lua脚本不支持nil，所以用‘-1’表示)，

-- 所以如果不是 ‘-1’，需要将 obj.weight 设置到 annotations 中

if ( obj.weight ~= "-1" )

then

    annotations["nginx.ingress.kubernetes.io/canary-weight"] = obj.weight

end

-- obj.matches 是 rollout.spec.strategy.canary.steps[x].matches（数据结构一样），

-- 当没有设置时表明此step不需要进行 A/B Testing 发布，直接返回即可

if ( not obj.matches )

then

    return annotations

end

-- A/B Testing发布，遍历 matches ，将 matches 设置到 annotations 中

-- 注意：nginx 并不支持多个header，所以这里并不需要真正的遍历，默认只取第一个数组

for _,match in ipairs(obj.matches) do

    -- 注意 lua 脚本当中数组是从下标 ‘1’ 开始

    local header = match.headers[1]

    -- cookie

    if ( header.name == "canary-by-cookie" )

    then

        annotations["nginx.ingress.kubernetes.io/canary-by-cookie"] = header.value

    -- header

    else

        annotations["nginx.ingress.kubernetes.io/canary-by-header"] = header.name

        -- 是否是“正则”

        if ( header.type == "RegularExpression" )

        then

            annotations["nginx.ingress.kubernetes.io/canary-by-header-pattern"] = header.value

        else

            annotations["nginx.ingress.kubernetes.io/canary-by-header-value"] = header.value

        end

    end

end

-- must be return annotations

return annotations

```

**注**：此版本只针对 Ingress 资源来实现的，面对 Apisix、Kong 等其它自定义资源（CRD）将在下一个版本支持。**相关 PR **[** **4]** **已经提交 Github，欢迎大家一起讨论。

## 未来规划

-   **更多网关协议支持**：Kruise Rollout 目前是以 Lua 脚本插件化的方式支持多类型的网关协议，我们后续会重点加大这方面的投入，但面对百花齐放的协议类型，单靠社区 Maintainer 的单薄力量还远远不够，希望更多的社区小伙伴加入我们，一起来不断完善这方面的内容。

-   **更完善的发布体系**：为支撑包括灰度、告警、可观测、自动回滚、无人值守等在内的较为完整的发布体系，需要继续建设一些发布发布时的 Hook 调用与 Prometheus Metrics Analysis 等相关能力，这块我们目前正在与 KubeVela 社区紧密合作，通过 KubeVela 现有的 Workflow 体系集成来弥补目前这些能力的缺失，至于后续是否需要将这些能力做到 Kruise Rollout 之中，我们也希望聆听更多的社区意见，欢迎大家一块讨论沟通。

## 社区参与

非常欢迎你通过 Github/Slack/钉钉/微信 等方式加入我们来参与 OpenKruise 开源社区。  

你是否已经有一些希望与我们社区交流的内容呢？

可以在我们的**社区双周会 **[** **5]** **上分享你的声音，或通过以下渠道参与讨论：

-   加入社区 **Slack channel **[** **6]** **(English)

-   加入社区钉钉群：搜索群号 23330762 (Chinese)

-   加入社区微信群（新）：添加用户 openkruise 并让机器人拉你入群 (Chinese)

## 相关链接

[1] flagger

*[https://github.com/fluxcd/flagger](https://github.com/fluxcd/flagger?spm=a2c6h.13046898.0.0.53b86ffaDrvicp)*

[2] Argo-Rollout

*<https://github.com/argoproj/argo-rollouts>*

[3] Nginx与Alb Lua脚本示例*<https://github.com/openkruise/rollouts/tree/master/lua_configuration/trafficrouting_ingress>*

[4] 相关 PR

*[https://github.com/openkruise/rollouts/pull/111](https://github.com/openkruise/rollouts/pull/111?spm=a2c6h.13046898.0.0.53b86ffaDrvicp)*

[5] 社区双周会

*[https://shimo.im/docs/gXqmeQOYBehZ4vqo](https://shimo.im/docs/gXqmeQOYBehZ4vqo?spm=a2c6h.13046898.0.0.53b86ffaDrvicp)*

[6] Slack channel

*[https://kubernetes.slack.com/?redir=%2Farchives%2Fopenkruise](https://kubernetes.slack.com/?spm=a2c6h.13046898.0.0.53b86ffaDrvicp&redir=%252Farchives%252Fopenkruise)*

戳[这里](https://openkruise.io/)，查看 OpenKruise 项目官方主页与文档