Container Service for Kubernetes:Phased releases with Kruise Rollout (canary and A/B testing)

Step 1: Install the ack-kruise add-on

1. Log on to the ACK console. In the left navigation pane, choose Clusters.

2. On the Clusters page, click the name of the target cluster. In the left navigation pane, click Add-ons.

3. On the Add-ons page, click the Manage Applications tab. In the lower-right corner of the ack-kruise card, click Install.

4. In the dialog box, confirm the information and click OK.

The ack-kruise add-on version 1.8 or later supports the v1beta1 API. For more information, see API specifications.

Step 2: Deploy the sample application

The following steps deploy an echoserver service using a Deployment and expose it through an Ingress. This sample application is used in both use cases.

1. Create a file named echoserver.yaml with the following content.

   Expand to view the YAML content

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: echoserver
     labels:
       app: echoserver
   spec:
     replicas: 6
     selector:
       matchLabels:
         app: echoserver
     template:
       metadata:
         labels:
           app: echoserver
       spec:
         containers:
         - name: echoserver
           image: openkruise-registry.cn-shanghai.cr.aliyuncs.com/openkruise/demo:1.10.2
           imagePullPolicy: IfNotPresent
           ports:
           - containerPort: 8080
           env:
           - name: NODE_NAME
             value: version1
           - name: PORT
             value: '8080'
           - name: POD_NAME
             valueFrom:
               fieldRef:
                 fieldPath: metadata.name
           - name: POD_NAMESPACE
             valueFrom:
               fieldRef:
                 fieldPath: metadata.namespace
           - name: POD_IP
             valueFrom:
               fieldRef:
                 fieldPath: status.podIP
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: echoserver
     labels:
       app: echoserver
   spec:
     ports:
     - port: 80
       targetPort: 8080
       protocol: TCP
       name: http
     selector:
       app: echoserver

2. Apply the configuration.

   kubectl apply -f echoserver.yaml

Step 1: Install the Ingress controller and create an Ingress

Select your Ingress type and follow the corresponding instructions.

Step 2: Verify access to the application

1. Retrieve the external IP address or hostname. Nginx Ingress:

   export EXTERNAL_IP=$(kubectl get ingress echoserver -o jsonpath="{.status.loadBalancer.ingress[0].ip}")

   MSE Ingress:

   export EXTERNAL_IP=$(kubectl get ingress echoserver -o jsonpath="{.status.loadBalancer.ingress[0].hostname}")

2. Test access.

   curl http://${EXTERNAL_IP}/apis/echo

   Expected output:

   Hostname: echoserver-75d49c475c-ls2bs
   
   Pod Information:
       node name:    version1
       pod name:    echoserver-75d49c475c-ls2bs
       pod namespace:    default
   
   Server values:
       server_version=nginx: 1.13.3 - lua: 10008
   ...

Step 3: Define the Rollout resource

Create a file named rollout.yaml using the strategy that matches your use case. The trafficRoutings field links the Rollout to the echoserver Service and Ingress so that Kruise Rollout can shift traffic at each step.

apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
spec:
  objectRef:
    workloadRef:
      apiVersion: apps/v1
      kind: Deployment
      name: echoserver
  strategy:
    canary:
      steps:
      # Step 1: Route 20% of traffic to the new version (1 pod). Pause until manually approved.
      - weight: 20
        replicas: 1
        pause: {}
      # Step 2: Increase to 50% traffic and 50% pods. Auto-proceed after 60 seconds.
      - weight: 50
        replicas: 50%
        pause: {duration: 60}  # unit: seconds
      # Step 3: Full release.
      - weight: 100
        replicas: 100%
        pause: {duration: 60}  # unit: seconds
      trafficRoutings:
      - service: echoserver
        ingress:
          name: echoserver

apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
spec:
  objectRef:
    workloadRef:
      apiVersion: apps/v1
      kind: Deployment
      name: echoserver
  strategy:
    canary:
      steps:
      # Step 1: Route Android traffic to the new version (1 pod). Pause until manually approved.
      - matches:
          - headers:
              - type: Exact
                name: User-Agent
                value: Android
        pause: {}
        replicas: 1
      # Step 2: 50% of pods, still matching Android traffic. Auto-proceed after 60 seconds.
      - matches:
          - headers:
              - type: Exact
                name: User-Agent
                value: Android
        pause: {duration: 60}  # unit: seconds
        replicas: 50%
      # Step 3: Full release.
      - matches:
          - headers:
              - type: Exact
                name: User-Agent
                value: Android
        pause: {duration: 60}  # unit: seconds
        replicas: 100%
      trafficRoutings:
        - service: echoserver
          ingress:
            name: echoserver

kubectl apply -f rollout.yaml
kubectl get rollout

NAME            STATUS    CANARY_STEP   CANARY_STATE   MESSAGE                            AGE
rollouts-demo   Healthy   3             Completed      workload deployment is completed   7s

Step 4: Trigger the upgrade

Kruise Rollout activates automatically when the Deployment spec changes. Update the image version in echoserver.yaml to trigger a release.

# echoserver.yaml (relevant section)
spec:
  containers:
  - name: echoserver
    image: openkruise-registry.cn-shanghai.cr.aliyuncs.com/openkruise/demo:1.10.3
    env:
    - name: NODE_NAME
      value: version2  # Optional: helps identify the new version in verification output

Apply the updated Deployment. You can also use tools such as Helm and Vela to apply the Deployment configuration.

kubectl apply -f echoserver.yaml

Check the rollout status.

kubectl get rollouts rollouts-demo -n default

Expected output:

NAME            STATUS        CANARY_STEP   CANARY_STATE   MESSAGE                                                                         AGE
rollouts-demo   Progressing   1             StepPaused     Rollout is in step(1/3), and you need manually confirm to enter the next step   41m

The status fields show:

Step 5: Verify traffic distribution and proceed

Roll back if the new version is abnormal

If the new version behaves unexpectedly at any step, restore the previous Deployment configuration and reapply. No changes to the Rollout resource are required.

# echoserver.yaml (rollback version)
spec:
  containers:
  - name: echoserver
    image: openkruise-registry.cn-shanghai.cr.aliyuncs.com/openkruise/demo:1.10.2
    env:
    - name: NODE_NAME
      value: version1

kubectl apply -f echoserver.yaml

Step 1: Define and deploy the Rollout resource

The following Rollout uses the partition rolling style and releases pods in three batches: 1 pod, then 50%, then 100%. The trafficRoutings field is omitted because the microservice framework manages traffic routing.

# Save as rollout.yaml
apiVersion: rollouts.kruise.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
  annotations:
    rollouts.kruise.io/rolling-style: partition
spec:
  objectRef:
    workloadRef:
      apiVersion: apps/v1
      kind: Deployment
      name: echoserver
  strategy:
    canary:
      steps:
      # Step 1: Update 1 pod. Pause until manually approved.
      - replicas: 1
        pause: {}
      # Step 2: Update 50% of pods. Auto-proceed after 60 seconds.
      - replicas: 50%
        pause: {duration: 60}  # unit: seconds
      # Step 3: Update all pods.
      - replicas: 100%
        pause: {duration: 60}  # unit: seconds

kubectl apply -f rollout.yaml

Step 2: Trigger the upgrade

Update the image version in echoserver.yaml.

# echoserver.yaml (relevant section)
spec:
  containers:
  - name: echoserver
    image: openkruise-registry.cn-shanghai.cr.aliyuncs.com/openkruise/demo:1.10.3
    env:
    - name: NODE_NAME
      value: version2  # Optional: helps identify the new version

kubectl apply -f echoserver.yaml

Step 3: Check rollout status

kubectl get rollouts rollouts-demo -n default

Expected output:

NAME            STATUS        CANARY_STEP   CANARY_STATE   MESSAGE                                                                         AGE
rollouts-demo   Progressing   1             StepPaused     Rollout is in step(1/3), and you need manually confirm to enter the next step   41m

Step 4: Approve batches and monitor progress

Approve step 1 to move to step 2.

kubectl-kruise rollout approve rollouts/rollouts-demo -n default

Monitor the rollout as it progresses.

kubectl get rollouts rollouts-demo -n default -w

After you approve step 1, the rollout automatically advances through step 2 (50% pods, 60s pause) and step 3 (all pods, 60s pause). Key state transitions to watch for:

The rollout is complete when STATUS=Healthy and CANARY_STATE=Completed.

Roll back if the new version is abnormal

If the new version behaves unexpectedly, restore the previous Deployment configuration and reapply. No changes to the Rollout resource are required.

# echoserver.yaml (rollback version)
spec:
  containers:
  - name: echoserver
    image: openkruise-registry.cn-shanghai.cr.aliyuncs.com/openkruise/demo:1.10.2
    env:
    - name: NODE_NAME
      value: version1

kubectl apply -f echoserver.yaml