Kruise Rollout v0.2.0 release: support Gateway API, StatefulSet batch release and other capabilities

Author: Zhao Mingshan (Liheng)

foreword

Kruise Rollout [ 1] is a progressive delivery framework open sourced by the OpenKruise community. Kruise Rollout supports canary release, blue-green release, and A/B Testing release in accordance with traffic and instance grayscale, and the release process can be automatically batched and paused based on Prometheus Metrics indicators, and provides bypass insensitivity docking, compatibility with existing There are multiple workloads (Deployment, CloneSet).

Gateway API

Ingress API is an abstraction for service gateways in K8s, and it is also the most widely used gateway resource in the K8s community. The most representative one is Nginx Ingress Controller. However, there are also some problems with Ingress resources, mainly because the definition of Ingress is relatively simple, which cannot well meet some complex network requirements. In many scenarios, the Ingress controller needs to be extended by defining Annotations or CRDs. For example, Istio extends Virtual Service and DestinationRule resources.

In order to solve the above problems and promote the community to use unified standards, the SIG-NETWORK community proposed the Gateway API resource, which is a collection of API resources in Kubernetes, including GatewayClass, Gateway, HTTPRoute, TCPRoute, Service, etc. Network use case building models. At present, many community open source projects such as Istio, Nginx, and Kong have implemented this interface. As a progressive delivery framework, Kruise Rollout needs to be supported as a matter of course. The following is an example of using the Gateway API for canary release:

 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 release in batches

Kruise Rollout already supports batch release capabilities of stateless applications (Deployment and CloneSet) in v0.1.0, and stateful applications also have similar requirements. The community StatefulSet itself supports the ability to retain the number of Pods of the old version during the release process (Pods with an Order smaller than Partition retain the old version), so Kruise Rollout can also easily integrate stateful workloads (including: Advanced StatefulSet extended by Kruise) through this feature. . Here's an example of publishing in three batches:

 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

title=

Rollout batch marking capability

Kruise Rollout has considered a lot of usability issues at the beginning of its design. It can be quickly integrated with many excellent deployment solutions in the community. For example, users can use Helm to complete the rollout delivery of applications. With the increase of users and scale of Kruise Rollout, new requirements for ease of use are put forward, such as:

During the canary release process, it was found that the business monitoring was slightly abnormal. I hope to quickly filter out the first batch of released Pods to troubleshoot the problem.
The container platform product plan has a release details page, hoping to accurately display each batch of Pods, as well as the progress and process of Rollout

In order to meet the above requirements, Kruise Rollout has added the "Pod batch labeling" capability. During the Rollout process, each batch of Pods can be marked with the corresponding batch of Label [apps.kruise.io/rollout-batch-id] ={Value is the corresponding batch, such as: 1, 2, 3...}, the usage is as follows:

 apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
spec:
  ...
  # required
  rolloutID: v1

rolloutID is a release ID for each release. This field is filled in by the upper-layer PaaS platform or user, and can be any string. The two releases need to be different before and after, for example: webserver-20220728120533. Why is rolloutID necessary? The main reason is that CloneSet supports in-place upgrade. For this scenario, the release batch Label contained on the Pod may be left over from the last release, so it can be used together with rolloutID to mark any batch of this release.

title=

KubeVela realizes canary release capability based on Kruise Rollout

KubeVela [2 ] is a cloud-native application management platform based on the OAM model, with complete capabilities for application delivery, application distribution, and multi-cluster management. At present, Kruise Rollout has been integrated into KubeVela, and the canary publishing capability of Helm Charts can be easily realized through the trait method . For details, please refer to the document [ 3] at the end of the article, as follows:

 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

at last

As a bypass progressive delivery framework, Kruise Rollout can be easily integrated with excellent application delivery platforms in the community. Users basically do not need to make additional changes, only a Kruise Rollout CRD definition is required.

Everyone is welcome to apply. If you encounter any problems in the middle, you can issue an issue or communicate in the group.

Reference link:

[1] Kruise Rollout:

https://github.com/openkruise/rollouts

*[2] KubeVela*:

https://kubevela.io/

*[3] Documentation:*

https://kubevela.net/docs/end-user/traits/rollout

Github:

https://github.com/openkruise/rollouts

Official:

https://openkruise.io/