最新要闻

广告

手机

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

家电

天天快讯: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: Deploymentspec:  strategy:    rollingUpdate:       maxUnavailble: 0      maxSurge: 20%
  • 单个批次内必须先缩后扩,最大程度节省资源占用
kind: Deploymentspec:  strategy:    rollingUpdate:       maxUnavailble: 20%      maxSurge: 0
  • 单个批次内边扩遍缩,最大程度提高发布效率
kind: Deploymentspec:  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/v1alpha1kind: Rolloutmetadata:  name: rollouts-demo  namespace: default  annotations:    rollouts.kruise.io/rolling-style: partitionspec:  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.annotationsend-- 这是 nginx 灰度发布协议的标准,其它的实现也可以根据自己的实际情况调整annotations["nginx.ingress.kubernetes.io/canary"] = "true"-- nginx 的灰度发布协议变化主要是下面这些变化,为了简化多个批次间来回切换的复杂度,每次-- 都先将这些 annotations 置空annotations["nginx.ingress.kubernetes.io/canary-by-cookie"] = nilannotations["nginx.ingress.kubernetes.io/canary-by-header"] = nilannotations["nginx.ingress.kubernetes.io/canary-by-header-pattern"] = nilannotations["nginx.ingress.kubernetes.io/canary-by-header-value"] = nilannotations["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.weightend-- obj.matches 是 rollout.spec.strategy.canary.steps[x].matches(数据结构一样),-- 当没有设置时表明此step不需要进行 A/B Testing 发布,直接返回即可if ( not obj.matches )then    return annotationsend-- 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    endend-- must be return annotationsreturn 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 项目官方主页与文档

关键词: