Kruise Rollout v0.2.0 版本发布：支持 Gateway API、StatefulSet 分批发布等能力

2年前 (2022) 程序员胖胖胖虎阿

391 0 0

作者：赵明山（立衡）

前言

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

Kruise Rollout v0.2.0 版本发布：支持 Gateway API、StatefulSet 分批发布等能力

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 共同使用可以标记此次发布的任意批次。

Kruise Rollout v0.2.0 版本发布：支持 Gateway API、StatefulSet 分批发布等能力

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