Kruise Rollout v0.3.0：教你玩转 Deployment 分批发布和流量灰度

作者：明昼

前言

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 <

 
 步骤三：玩转 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 
 [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 
 [5] 社区双周会 
 https://shimo.im/docs/gXqmeQOYBehZ4vqo 
 [6] Slack channel 
 https://kubernetes.slack.com/?redir=%2Farchives%2Fopenkruise 
 戳这里，查看 OpenKruise 项目官方主页与文档