Master Progressive Delivery with Higress and Kruise Rollout: Canary & A/B Testing Guide

Introduction

During rapid business growth, developers need to protect traffic while iterating features. Progressive delivery—originating from large‑scale industrial projects—splits releases into small, controlled batches, using GitOps and CI/CD pipelines, A/B testing, and canary strategies to ensure stable, cost‑effective rollouts.

What is Higress

Higress is a standardized, highly integrated, hot‑updatable cloud‑native gateway. It follows the Ingress/Gateway API, combines traffic, service, and security gateways, and extends them with plugins for service management, rate limiting (Sentinel), and configuration (Nacos). It tightly integrates with Kubernetes and supports millisecond‑level rule updates.

What is Kruise Rollout

Kruise Rollout, part of Alibaba Cloud’s OpenKruise suite, adds progressive delivery capabilities to Kubernetes. It supports canary, blue‑green, and A/B testing releases, works with multiple workloads (Deployment, CloneSet, DaemonSet), and can automate batch progression based on Prometheus metrics.

Unlike the native Deployment controller, which only provides rolling updates with maxUnavailable and maxSurge, Kruise Rollout enables fine‑grained traffic control, batch pauses, and custom routing, allowing true progressive delivery.

Working Mechanism of Higress & Kruise Rollout

The workflow typically follows these steps:

Add a Rollout custom resource (CRD) describing the target workload, batch sizes, traffic routing, and associated Service and Ingress resources.

Update the Deployment image to the new version.

Kruise Rollout injects a pause hook into the Deployment, halting the native rolling update.

For each batch, Rollout creates a gray‑scale Ingress that routes a defined traffic weight (or header‑based routing) to the new Pods. Higress watches the Ingress changes and dynamically updates routing rules.

Monitor metrics (e.g., via Prometheus) to verify the new version’s behavior.

If metrics meet expectations, trigger the next batch; otherwise, roll back by scaling down new Pods, removing gray Ingress rules, and letting Higress revert traffic to the old version.

Practical Example – Canary Release

Assume a Deployment demo exposed through Higress. The following YAML snippets illustrate the resources.

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

Define the canary Rollout:

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

The first step routes 10 % of traffic to a single new Pod; after manual confirmation, the second step routes 30 % to two new Pods. Once all batches succeed, the rollout completes with full traffic shift.

Practical Example – A/B Testing

A/B testing routes traffic based on request metadata (e.g., HTTP header). The following Rollout routes only Android user‑agent requests to the new version.

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

Only requests with the header user-agent: android are routed to the new Pods; other traffic continues to the stable version. After validation, the rollout proceeds to full release.

Summary

Higress and Kruise Rollout together provide a non‑intrusive, automated progressive delivery solution. Developers declare a Rollout resource, and the system automatically coordinates Deployment, Service, and Ingress changes, enabling batch, gray, and rollback capabilities without manual intervention, thereby improving release stability and development velocity.