Higress & Kruise Rollout: 渐进式交付为应用发布保驾护航

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介: 通常在应用发布新功能阶段,我们会采用灰度发布的思想对新版本进行小流量验证,在符合预期之后再进行全量发布,这就是"渐进性交付"。在本文中开发者通过GitOps、CI/CD方式集成渐进式交付框架,让新功能交付以流水线的方式分批执行,利用A/B 测试、金丝雀发布等技术精细化控制每一批次的流量策略,充分保障应用发布的稳定性。

前言

在业务高速发展过程中,如何最大化保障功能迭代过程中业务流量无损一直是开发者比较关心的问题。通常在应用发布新功能阶段,我们会采用灰度发布的思想对新版本进行小流量验证,在符合预期之后再进行全量发布,这就是"渐进性交付"。该词最早起源于大型、复杂的工业化项目,它试图将复杂的项目进行分阶段拆解,通过持续进行小型闭环迭代降低交付成本和时间。随着云原生架构不断发展,渐进性交付被广泛应用在互联网业务应用中,开发者通过GitOps、CI/CD方式集成渐进式交付框架,让新功能交付以流水线的方式分批执行,利用A/B 测试、金丝雀发布等技术精细化控制每一批次的流量策略,充分保障应用发布的稳定性。


什么是Higress


Higress 是一款标准化、高集成、易扩展、热更新的云原生网关。


Higress 源自阿里巴巴内部电商、交易等核心生产场景的实践沉淀,遵循 Ingress/Gateway API 标准,将流量网关、微服务网关、安全网关三合一,并在此基础上扩展了服务管理插件、安全类插件和自定义插件,高度集成 K8s 和微服务生态,包括 Nacos 注册和配置、Sentinel 限流降级等能力,并支持规则变更毫秒级生效等热更新能力。

image.png


更多关于 Higress 的介绍,可以参阅Higress官网[1]


什么是Kruise Rollout


Kruise Rollout 是阿里云开源的云原生应用自动化管理套件 OpenKruise 在渐进式交付领域的新尝试,支持配合流量和实例灰度的金丝雀发布、蓝绿发布、A/B Testing 发布,以及发布过程能够基于 Prometheus Metrics 指标自动化分批与暂停,并提供旁路的无感对接、兼容已有的多种工作负载(Deployment、CloneSet、DaemonSet)。


这里,熟悉 Kubernetes 的小伙伴可以会疑惑,官方的 Deployment 工作负载不是有控制发布的策略吗?我们为什么还需要 Kruise Rollout 呢?首先,Kubernetes 官方的 Deployment 中定义发布策略严格上不符合渐进性交付的思想,它实际是滚动发布。虽然 Deployment 对于升级而言提供了 maxUnavailable 和 maxSurge 两个参数,但是本质上来讲 Deployment 它只支持流式的一次性发布,用户并不能控制分批以及精细化的流量策略。比如用户无法严格控制新老版本之间的流量比例,只能根据实际 Pod 数量占比以及调用端的负载均衡策略;用户无法做 A/B testing 策略,例如限制公司内部员工可以访问新版本。当新版本出现问题,只能重新执行一遍滚动发布切回老版本,这样不仅回滚速度慢,而且频繁线上变更本身就具有极高的不稳定因素。再者,Kubernetes 只提供了应用交付的 Deployment 控制器,以及针对流量的 Ingress、Service 抽象,但是如何将上述实现组合成开箱即用的渐进式交付方案,Kubernetes 并没有出标准的定义。出于以上问题和考量,阿里云开始发起对渐进式领域的探索,结合多年来容器化、云原生的技术沉淀,推出了无侵入、可扩展、高易用的渐进式交付框架 Kruise Rollout。


Higress & Kruise Rollout工作机制


简单介绍一下 Higress 和 Kruise Rollout 在一次应用发布过程中的工作机制。

image.png


这里,假设集群中有一个 Deployment 应用A,通过 Higress 网关对外暴露提供服务。应用A由于业务发展,需要发布新功能。


  1. 用户首先在集群中添加渐进性交付策略(Rollout CRD资源),描述目标工作负载的交付策略,比如批次,每一批次的流量控制,以及关联的 Service 资源和 Ingress 资源。
  2. 应用A发布新版本,用户修改集群上中目标Deployment的Pod模板中容器镜像为新版本。
  3. Kruise Rollout通过hook方式参与到Deployment滚动发布流程,修改Deployment的Pause来暂停滚动发布过程。
  4. 执行第一次批次发布,根据Rollout CRD资源描述的交付策略,控制新版本的Pod数量,同时为正式Ingress资源生成对应的灰度Ingress资源,并配置灰度流量策略,比如流量权重比或者根据请求内容Header进行流量分发。Higress监听到Ingress资源变化,实时动态修改路由规则,满足灰度规则的流量被分发到新版本。
  5. 通过Prometheus等监控手段观察应用流量的指标信息,验证新版本是否符合预期。
  1. 如果符合预期,触发下一次批次发布,重复执行步骤4
  2. 如果不符合预期,触发回滚,新发布的Pod下线,灰度已下线的部分老版本的Pod,Ingress资源自动下线灰度规则,Higress实时修改路由规则,确保流量只访问老版本服务。


整个 Rollout 过程,自动整合Deployment、Service、Ingress一起工作,并向用户屏蔽底层资源变化。这是与现有工作负载能力的一种协同,它尽量复用工作负载的能力,又做到了非 Rollout 过程的零入侵。


实战:金丝雀发布


01:什么是金丝雀发布

金丝雀发布的思想是将少量的请求引流到新版本上,因此部署新版本服务只需极小数的机器。验证新版本符合预期后,逐步调整流量权重比例,使得流量慢慢从老版本迁移至新版本,期间可以根据设置的流量比例,对新版本服务进行扩容,同时对老版本服务进行缩容,使得底层资源得到最大化利用。


如图,某服务当前版本为v1,现在新版本v2要上线。为确保流量在服务升级过程中平稳无损,采用金丝雀发布方案,逐步将流量从老版本迁移至新版本。


image.png


02:基于Higress & Kruise Rollout实践金丝雀发布

假设集群中有一个服务demo,通过Higress网关对外提供服务。如何安装Higress,请参阅Higress快速开始[2]如何安装Kruise Rollout,请参阅安装Kruise Rollout[3]


apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 5
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: main
        image: registry.cn-hangzhou.aliyuncs.com/mse-ingress/version:v1
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: demo
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: demo
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: demo
            port:
              number: 80
        path: /version
        pathType: Exact


现在,服务demo需要发布新版本。在修改应用镜像之前,我们需要为服务demo定义金丝雀发布策略,以达到渐进式发布的效果。

apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
spec:
  objectRef:
    workloadRef:
      apiVersion: apps/v1
      kind: Deployment
      name: demo
  strategy:
    canary:
      steps:
      - weight: 10
        pause: {}
        replicas: 1
      - weight: 30
        pause: {}
        replicas: 2
      trafficRoutings:
      - service: demo
        type: nginx
        ingress:
          name: demo


  • 其中workloadRef 旁路式的选择需要 Rollout 的 Workload,此处为Deployment,支持其他Workload(如CloneSet、DaemonSet)。
  • 其中canary.Steps 定义了整个 Rollout 过程一共分为3批,其中第一批只灰度一个新版本 Pod,并且 routing 10% 流量到新版本 Pod,并且需要人工确认是否继续发布;第二批只灰度两个新版本Pod,并且routing 30%流量到新版本Pod,并且需要人工确认是否继续发布;最后一批,无需定义,即全量发布。
  • 其中trafficRoutings指向了需要感知流量规则的资源,kruise rollout会自动更新相关资源,实时反射目标流量规则。


修改服务A的Deployment中镜像为registry.cn-hangzhou.aliyuncs.com/mse-ingress/version:v2,观察相关资源变化。


查看rollout资源状态,发现当前执行完第一批发布,并且出于暂停状态,需要人工确认才能继续下一批次发布。

image.png


查看pod状态,发现新版本pod只有一个,Deployment资源没有全部滚动发布。

image.png


查看Ingress的解析IP (即Higress网关对外的公网IP地址)。

image.png


测试流量,发现有10%流量访问新版本。

image.png


继续第二批次发布,查看当前Pod状态,发现新版本Pod有两个。如何安装kubectl-kruise,请参阅安装kubectl-kruise[4]

image.png


测试流量,观察流量分配比。

image.png


发布最后一批,完成全量发布。

image.png


测试流量,发现流量全部转发至新版本。至此,我们通过小流量的方式逐步将流量从老版本迁移至新版本。

image.png


实战:A/B Testing


01:什么是A/B Testing

相比于基于权重方式的金丝雀发布,A/B测试基于用户请求的元信息将流量路由到新版本,这是一种基于请求内容匹配的灰度发布策略。只有匹配特定规则的请求才会被引流到新版本,常见的做法包括基于Http Header和Cookie。基于Http Header方式的例子,例如User-Agent的值为Android的请求 (来自安卓系统的请求)可以访问新版本,其他系统仍然访问旧版本。基于Cookie方式的例子,Cookie中通常包含具有业务语义的用户信息,例如普通用户可以访问新版本,VIP用户仍然访问旧版本。如图,某服务当前版本为v1,现在新版本v2要上线。希望安卓用户可以尝鲜新功能,其他系统用户保持不变。


image.png


通过在监控平台观察旧版本与新版本的成功率、RT对比,当新版本整体服务预期后,即可将所有请求切换到新版本v2,最后为了节省资源,可以逐步下线到旧版本v1。


image.png


02:基于Higress & Kruise Rollout实践A/B Testing

我们仍然利用上面的例子,服务A初始镜像为v1。现在,服务demo需要发布新版本。在修改应用镜像之前,我们需要为服务demo定义A/B Testing 策略,以达到渐进式发布的效果。

apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-header
spec:
  objectRef:
    workloadRef:
      apiVersion: apps/v1
      kind: Deployment
      name: demo
  strategy:
    canary:
      steps:
      - matches:
        - headers:
          - name: user-agent
            value: android
        pause: {}
        replicas: 1
      trafficRoutings:
      - service: demo
        ingress:
          classType: nginx
          name: demo


其中canary.Steps 定义了整个 Rollout 过程一共分为2批,其中第一批只灰度一个新版本 Pod,并且将带有HTTP Header user-agent: android (即安卓用户)的流量routing 到新版本 Pod,并且需要人工确认是否继续发布;最后一批,无需定义,即全量发布。


修改服务A的Deployment中镜像为registry.cn-hangzhou.aliyuncs.com/mse-ingress/version:v2,观察相关资源变化。查看rollout资源状态,发现当前执行完第一批发布,并且出于暂停状态,需要人工确认才能继续下一批次发布。

image.png


查看pod状态,发现新版本pod只有一个,Deployment资源没有全部滚动发布。

image.png


测试来自安卓的流量是否路由到新版本,非安卓的流量是否路由到老版本。

image.png


发布最后一批,完成全量发布。并测试所有流量是否路由到新版本。

image.png


总结

相比于传统人工手动方式,Higress & Kruise Rollouts提供了无侵入、自动化运维方式让应用发布丝滑般顺畅。开发者无需关注发布过程中如何调整Deployment、Ingress、Service等资源,只需声明并管理发布策略Rollouts资源即可,原生Deployment的滚动发布会自动实现为渐进式交付,让应用发布可批次、可灰度、可回滚,助力业务快速迭代发展同时,也提高了应用发布的稳定性和效率问题。


01:Higress 社区

Higress项目处于开源初期,我们在兼容好现有 Ingress 标准的基础上,会重点发力下一代的Ingress 标准 Gateway API,利用 Gateway API 带来的契机打通南北向与东西向的全域流量调度,帮助用户使用一套架构架构同时管理外部与内部流量,降低部署运维成本、提升开发及运维效率。欢迎更多的用户参与到Higress社区,贡献一份文档、提交一段代码,您就有可能成为 Higress  的第一批 Contributor 甚至 Committer。目前,我们建立了1个钉群和1个微信群,加入我们,联系群主或群管,共建云原生网关吧。


image.png


02:OpenKruise 社区

OpenKruise是阿里巴巴从容器化转向云原生化过程中,在云原生应用管理方面的最佳实践经验,除本文涉及的Kruise Rollout外,OpenKruise还提供了诸多云原生应用管理相关的能力,如:增强的工作负载、Sidecar容器管理、弹性拓扑管理等。目前OpenKruise上面托管着阿里集群上百万的Pod,包含:有状态、无状态、通用类型的Sidecar Aagent。最后,欢迎感兴趣的同学加入下面的社区钉钉群,我们大家一起讨论云原生应用管理相关的需求与技术。


image.png


相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
5月前
|
存储 监控 持续交付
利用GitOps实现持续部署:深度技术实践
【7月更文挑战第7天】利用GitOps实现持续部署是一种高效、可靠的运维模式。通过将基础设施和应用配置作为代码进行管理,并通过自动化的CI/CD流程进行部署和验证,GitOps显著提高了软件交付的效率和质量。然而,在实施GitOps的过程中也需要注意其带来的挑战,并采取相应的措施来加以应对。随着技术的不断进步和实践的深入,GitOps必将在未来发挥更加重要的作用。
|
5月前
|
Cloud Native 网络性能优化 调度
Koordinator v1.5:持续优化,进入CNCF Sandbox
介绍开源项目 Koordinator v1.5 版本的新功能特性,介绍开源社区进展,介绍开源项目入选 CNCF Sandbox 的消息。
|
存储 Prometheus Kubernetes
阿里 sealer 是如何实现整个集群一键交付的?
顾名思义,和操作系统 .iso 镜像或 Docker 镜像类似,集群镜像是用一定的技术手段把整个集群的所有文件以一定格式打成的一个资源包。
1260 0
阿里 sealer 是如何实现整个集群一键交付的?
|
Kubernetes jenkins 测试技术
【Kubernetes的DevOps自动化,Jenkins上的Pipeline实现自动化构建、测试、部署、发布以及Bookinginfo实例的部署灰度发布故障注入流量】
【Kubernetes的DevOps自动化,Jenkins上的Pipeline实现自动化构建、测试、部署、发布以及Bookinginfo实例的部署灰度发布故障注入流量】
268 1
|
运维 Kubernetes Cloud Native
Higress & Kruise Rollout: 渐进式交付为应用发布保驾护航
相比于传统人工手动方式,Higress & Kruise Rollouts提供了无侵入、自动化运维方式让应用发布丝滑般顺畅。
Higress & Kruise Rollout: 渐进式交付为应用发布保驾护航
|
存储 运维 Kubernetes
GitOps 的 12 个痛点
GitOps 的 12 个痛点
234 0
GitOps 的 12 个痛点
|
测试技术 开发者
KubeVela 对接 Istio 实现应用灰度发布实践|学习笔记(二)
快速学习 KubeVela 对接 Istio 实现应用灰度发布实践
KubeVela 对接 Istio 实现应用灰度发布实践|学习笔记(二)
|
运维 监控 Kubernetes
KubeVela 对接 Istio 实现应用灰度发布实践|学习笔记(一)
快速学习 KubeVela 对接 Istio 实现应用灰度发布实践
KubeVela 对接 Istio 实现应用灰度发布实践|学习笔记(一)
|
Prometheus Kubernetes Cloud Native
Kruise Rollout: 让所有应用负载都能使用渐进式交付
随着 Kubernetes 上面部署的应用日益增多,如何做到业务快速迭代与应用稳定性之间的平衡,是平台建设方必须要解决的问题。Kruise Rollout 是 OpenKruise 在渐进式交付领域的新探索,旨在解决应用交付领域的流量调度以及分批部署问题。
Kruise Rollout: 让所有应用负载都能使用渐进式交付
|
存储 Prometheus Kubernetes
使用 Flux+Flagger+Istio+Kubernetes 实战 GitOps 云原生渐进式(金丝雀)交付
使用 Flux+Flagger+Istio+Kubernetes 实战 GitOps 云原生渐进式(金丝雀)交付
435 0
使用 Flux+Flagger+Istio+Kubernetes 实战 GitOps 云原生渐进式(金丝雀)交付