作者：赵明山（立衡）
前言
Kruise Rollout[1]是 OpenKruise 社区开源的渐进式交付框架。Kruise Rollout 支持配合流量和实例灰度的金丝雀发布、蓝绿发布、A/B Testing 发布，以及发布过程能够基于 Prometheus Metrics 指标自动化分批与暂停，并提供旁路的无感对接、兼容已有的多种工作负载（Deployment、CloneSet）。
Gateway API
Ingress API 是 K8s 中针对服务网关的抽象，也是目前 K8s 社区中使用最为广泛的网关资源，其中最具代表性的有 Nginx Ingress Controller。但是 Ingress 资源也存在一些问题，主要是 Ingress 定义比较单一，不能很好的满足一些复杂的网络需求。很多场景下 Ingress 控制器都需要通过定义 Annotations 或者 CRD 的方式来进行扩展，比如，Istio 就扩展了 Virtual Service、DestinationRule 资源。
为了解决上述问题，推动社区使用统一的标准，SIG-NETWORK 社区提出了 Gateway API 资源，它是 Kubernetes 中的一个 API 资源集合，包括 GatewayClass、Gateway、HTTPRoute、TCPRoute、Service 等，这些资源共同为各种网络用例构建模型。目前 Istio、Nginx、Kong 等诸多社区开源项目都已经实现了该接口。而 Kruise Rollout 作为渐进式交付框架，理所当然的需要支持，如下是使用 Gateway API 进行金丝雀发布的例子：
apiVersion: gateway.networking.k8s.io/v1alpha2 kind: HTTPRoute metadata: name: echoserver spec: hostnames: - test.app.domain rules: - backendRefs: - group: "" name: echoserver port: 80 --- apiVersion: rollouts.kruise.io/v1alpha1 kind: Rollout spec: objectRef: ... strategy: canary: steps: - weight: 20 pause: {} trafficRoutings: - service: echoserver gateway: httpRouteName: echoserver
StatefulSet & Advanced StatefulSet 分批发布
Kruise Rollout 在 v0.1.0 版本已经支持了无状态应用（Deployment 和 CloneSet）的分批发布能力，而有状态的应用同样有类似的诉求。社区 StatefulSet 本身支持发布过程中保留旧版本 Pod 数量的能力（Order 小于 Partition 的 Pod 保留旧版本），所以 Kruise Rollout 通过该特性也可以非常方便的集成有状态工作负载（包括：Kruise 扩展 的 Advanced StatefulSet）。如下是一个分三批发布的例子：
apiVersion: apps/v1 kind: StatefulSet metadata: name: echoserver spec: replicas: 5 template: spec: containers: - name: echoserver image: cilium/echoserver:latest --- apiVersion: rollouts.kruise.io/v1alpha1 kind: Rollout metadata: name: rollouts-demo spec: objectRef: workloadRef: apiVersion: apps/v1 kind: StatefulSet name: echoserver strategy: canary: steps: - replicas: 1 pause: {} - replicas: 2 pause: {duration: 60} - replicas: 2
Rollout 批次打标能力
Kruise Rollout 在设计之初就考虑了很多易用性的问题，它可以与社区很多优秀部署方案快速集成，比如：用户可以使用 Helm 完成应用的 Rollout 交付。随着 Kruise Rollout 使用的用户以及规模的增大，对易用性方面又提出了新的要求，例如：
- 金丝雀发布过程中，发现业务监控有些许的异常，希望能快速的过滤出第一批发布的 Pod 排查问题
- 容器平台产品规划有发布详情页，希望能够精准的展示每次批次的 Pod，以及 Rollout 的进度、过程
为了满足上述需求，Kruise Rollout 新增了“Pod 批次打标”能力，在 Rollout 过程中能够对每一批次的 Pod 打上对应批次的 Label[apps.kruise.io/rollout-batch-id]={Value为对应的批次，如：1，2，3...}，用法如下：
apiVersion: rollouts.kruise.io/v1alpha1 kind: Rollout metadata: name: rollouts-demo spec: ... # required rolloutID: v1
- rolloutID 是针对每次发布的一个发布 ID。该字段由上层 PaaS 平台或用户填写，可以是任意的字符串，前后两次发布需要不同，例如：webserver-20220728120533。为什么一定需要 rolloutID？主要是由于 CloneSet 支持原地升级，针对这种场景 Pod 上面包含的发布批次 Label 有可能是上次发布留下的，所以与 rolloutID 共同使用可以标记此次发布的任意批次。
KubeVela 基于 Kruise Rollout 实现金丝雀发布能力
KubeVela[2]是一款基于 OAM 模型的云原生应用管理平台，具有完善的应用交付、应用分发以及多集群管理等能力。目前 Kruise Rollout 已经集成到 KubeVela 之中，通过 trait 的方式可以非常便捷的实现 Helm Charts 金丝雀发布能力，详情请参考文末文档[3]，如下：
apiVersion: core.oam.dev/v1beta1 kind: Application spec: components: - name: canary-demo type: webservice properties: image: barnett/canarydemo:v1 traits: - type: kruise-rollout properties: canary: steps: # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed - weight: 20 trafficRoutings: - type: nginx
最后
Kruise Rollout 作为一种旁路式的渐进式交付框架，能够非常方便的与社区内优秀的应用交付平台集成。用户基本上不需要做额外的改动，只需要一份 Kruise Rollout CRD 定义即可。
欢迎大家适用，如果中间遇到任何问题可以 Issue 或者群里沟通。
参考链接：
[1] Kruise Rollout：
https://github.com/openkruise/rollouts
[2] KubeVela：
[3] 文档：
https://kubevela.net/docs/end-user/traits/rollout
Github：https://github.com/openkruise/rollouts
Official：https://openkruise.io/
Slack: Channel in Kubernetes Slack
钉钉扫码加入OpenKruise 社区交流群：
戳此处，查看 OpenKruise 项目官方主页与文档！
