diff --git a/docs/end-user/traits/rollout.md b/docs/end-user/traits/rollout.md
new file mode 100644
index 00000000..475f8637
--- /dev/null
+++ b/docs/end-user/traits/rollout.md
@@ -0,0 +1,265 @@
+---
+title: Canary rollout
+---
+
+In this section, we will introduce how to canary rollout a container service.
+
+## Before starting
+
+1. Enable `kruise-rollout` addon.
+
+```shell
+% vela addon enable kruise-rollout
+Addon: kruise-rollout enabled Successfully.
+```
+
+
+2. Please make sure one of the [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) is available in your Kubernetes cluster.
+   If not yet, you can install one in your cluster by enable the [ingress-nginx](../../reference/addons/nginx-ingress-controller) addon:
+
+```shell
+vela addon enable ingress-nginx
+```
+
+Please refer [this](../../reference/addons/nginx-ingress-controller) to get the gateway's access address.
+
+3. Please make sure the version of  Vela-cli `>=1.5.0-alpha.1`.
+
+## First Deployment
+
+When you want to use the canary rollout, you need to add the `kruise-rollout` trait at the first time, this configuration will take effect in the process of next release. Deploy the application with traits like below:
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+  annotations:
+    app.oam.dev/publishVersion: v1
+spec:
+  components:
+  - name: canary-demo
+    type: webservice
+    properties:
+      image: barnett/canarydemo:v1
+      ports:
+      - port: 8090
+    traits:
+    - type: scaler
+      properties:
+        replicas: 5
+    - type: gateway
+      properties:
+        domain: canary-demo.com
+        http:
+          "/version": 8090
+    - 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
+          # The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
+          - weight: 90
+          trafficRoutings:
+            - type: nginx
+EOF
+```
+
+Then check the status of application will find out the application is running.
+
+```shell
+$ vela status canary-demo
+About:
+
+  Name:         canary-demo                  
+  Namespace:    default                      
+  Created at:   2022-06-09 16:43:10 +0800 CST
+  Status:       running                      
+
+Workflow:
+
+  mode: DAG
+  finished: true
+  Suspend: false
+  Terminated: false
+  Steps
+  - id:x6rnat7iby
+    name:canary-demo
+    type:apply-component
+    phase:succeeded 
+    message:
+
+Services:
+
+  - Name: canary-demo  
+    Cluster: local  Namespace: default
+    Type: webservice
+    Healthy Ready:5/5
+    Traits:
+      ✅ scaler      ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
+      ✅ kruise-rollout: rollout is healthy
+
+```
+
+If you have enabled [velaux](../../reference/addons/velaux) addon you can view the application topology graph , then you will see all `v1` pods are ready now.
+
+![image](../../resources/kruise-rollout-v1.jpg)
+
+Access the gateway endpoint with the specific host.
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+``` 
+
+
+## Canary Release
+Modify the webservice image tag, from v1 to v2, as follows:
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+  annotations:
+    app.oam.dev/publishVersion: v2
+spec:
+  components:
+  - name: canary-demo
+    type: webservice
+    properties:
+      image: barnett/canarydemo:v2
+      ports:
+      - port: 8090
+    traits:
+    - type: scaler
+      properties:
+        replicas: 5
+    - type: gateway
+      properties:
+        domain: canary-demo.com
+        http:
+          "/version": 8090
+    - type: kruise-rollout
+      properties:
+        canary:
+          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
+          steps:
+          - weight: 20
+          - weight: 90
+          trafficRoutings:
+          - type: nginx
+EOF
+```
+
+The configuration strategy of kruise-rollout trait means: The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed.
+
+Check the status of applciation:
+```shell
+$ vela status canary-demo
+About:
+
+  Name:         canary-demo                  
+  Namespace:    default                      
+  Created at:   2022-06-09 16:43:10 +0800 CST
+  Status:       runningWorkflow              
+
+Workflow:
+
+  mode: DAG
+  finished: false
+  Suspend: false
+  Terminated: false
+  Steps
+  - id:8adxa11wku
+    name:canary-demo
+    type:apply-component
+    phase:running 
+    message:wait healthy
+
+Services:
+
+  - Name: canary-demo  
+    Cluster: local  Namespace: default
+    Type: webservice
+    Unhealthy Ready:5/5
+    Traits:
+      ✅ scaler      ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
+      ❌ kruise-rollout: Rollout is in step(1/1), and you need manually confirm to enter the next step
+
+```
+
+The application's status is `runningWorkflow` that means the application's rollout process has not finished yet.
+
+View topology graph again, you will see `kruise-rollout` trait created a `v2` pod, and this pod will serve the canary traffic. Meanwhile, the pods of `v1` are still running and server non-canary traffic.
+
+![image](../../resources/kruise-rollout-v2.jpg)
+
+Access the gateway endpoint again. You will find out there is about 20% chance to meet `Demo: v2` result.
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V2
+```
+
+## Continue rollout process
+
+After verify the success of the canary version through business-related metrics, such as logs, metrics, and other means, you can resume the workflow to continue the process of rollout.
+
+```shell
+vela workflow resume canary-demo
+```
+
+Access the gateway endpoint again multi times. You will find out the chance to meet result `Demo: v2` is highly increased, almost 90%.
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V2
+```
+
+## Canary validation successful, full release
+
+In the end, you can resume again to finish the rollout process.
+
+```shell
+vela workflow resume canary-demo
+```
+
+Access the gateway endpoint again multi times. You will find out the result always is `Demo: v2`.
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V2
+```
+
+## Canary verification failed, rollback
+
+If you want to cancel the rollout process and rollback the application to the latest version, after manually check. You can rollback the rollout workflow:
+
+You should suspend the workflow before rollback:
+```shell
+$ vela workflow suspend canary-demo
+Rollout default/canary-demo in cluster  suspended.
+Successfully suspend workflow: canary-demo
+```
+
+Then rollback:
+```shell
+$ vela workflow rollback canary-demo
+Application spec rollback successfully.
+Application status rollback successfully.
+Rollout default/canary-demo in cluster  rollback.
+Successfully rollback rolloutApplication outdated revision cleaned up.
+```
+
+Access the gateway endpoint again. You can see the result always is `Demo: V1`.
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+```
+
+Please notice: rollback operation in middle of a runningWorkflow will rollback to latest succeed revision which is `v1` in this case.
+Image a scenario, you deploy a successful `v1` and canary rollout to `v2`, but you find some error in this version, then you continue to rollout to `v3` directly. Error still exists, application is unhealthy then you decide to rollback.
+When you execute rollback workload will let application rollback to version `v1`.
\ No newline at end of file
diff --git a/docs/reference/addons/kruise-rollout.md b/docs/reference/addons/kruise-rollout.md
new file mode 100644
index 00000000..6f7f3ffc
--- /dev/null
+++ b/docs/reference/addons/kruise-rollout.md
@@ -0,0 +1,103 @@
+---
+title: kruise-rollout
+---
+
+Kruise Rollout addon provides canary release capabilities for Kubernetes Deployment, Statefulset and OpenKruise CloneSet.
+For more details, please refer to: [Kruise Rollout](https://github.com/openkruise/rollouts/blob/master/docs/getting_started/introduction.md).
+
+
+## Installation
+
+```shell
+$ vela addon enable kruise-rollout
+Addon: kruise-rollout enabled Successfully.
+```
+
+## Uninstallation
+
+```shell
+$ vela addon disable kruise-rollout
+```
+
+## Usage
+
+Kurise rollout addon help to canary rollout your workload no matter defined with [webservice](../../end-user/components/cue/webservice) or contained in a [helm](../../tutorials/helm).
+
+If your workload is in a helm chart please refer to [doc](../../tutorials/helm-rollout) for more usage info, otherwise please refer to usage of webservice [component](../../end-user/traits/rollout).
+
+### Properties
+
+Name | Description | Type | Required | Default
+ ------------ | ------------- | ------------- | ------------- | -------------
+canary| Configuration for canary rollout strategy| [Canary](#Canary)| true|
+workloadType| Specify the target worklaod type| [WorkloadType](#WorkloadType)|false
+
+#### Canary
+
+Name | Description | Type | Required | Default
+ ------------ | ------------- | ------------- | ------------- | -------------
+steps| Defines the entire rollout process in steps | [CanaryStep](#CanaryStep)|true
+trafficRoutings| Define traffic routing related service, ingress information | [[]TrafficRouting](#TrafficRouting)| true
+
+
+##### CanaryStep
+
+Name | Description | Type | Required | Default
+ ------------ | ------------- | ------------- | ------------- | -------------
+weight| Define the percentage of traffic routing to the new version in each step, e.g., 20%, 40%...| int|false
+replicas| Define the replicas of release to the new version in each step, e.g., 5, 10...| int| false
+duration| Define the behavior after release each step, if not filled, the default requires manual determination. If filled, it indicates the time to wait in seconds, e.g., 60| int|false
+
+##### TrafficRouting
+
+Name | Description | Type | Required | Default
+ ------------ | ------------- | ------------- | ------------- | -------------
+service| Define service name | stirng | false | context.name
+ingressName| Define ingress name | string | false | context.name
+
+##### WorkloadType
+
+Name | Description | Type | Required | Default
+ ------------ | ------------- | ------------- | ------------- | -------------
+apiVersion| Target workload's apiVersion| string| true
+kind| Target workload's kind | string | true
+
+## Example
+
+```yaml
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+  annotations:
+    app.oam.dev/publishVersion: v1
+spec:
+  components:
+  - name: canary-demo
+    type: webservice
+    properties:
+      image: barnett/canarydemo:v1
+      ports:
+      - port: 8090
+    traits:
+    - type: scaler
+      properties:
+        replicas: 5
+    - type: gateway
+      properties:
+        domain: canary-demo.com
+        http:
+          "/version": 8090
+    - 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
+          # The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
+          - weight: 90
+          trafficRoutings:
+            - type: nginx
+EOF
+```
diff --git a/docs/reference/addons/nginx-ingress-controller.md b/docs/reference/addons/nginx-ingress-controller.md
new file mode 100644
index 00000000..e3fc9253
--- /dev/null
+++ b/docs/reference/addons/nginx-ingress-controller.md
@@ -0,0 +1,82 @@
+---
+title: Nginx Ingress Controller
+---
+
+
+[Nginx Ingress controller](https://kubernetes.github.io/ingress-nginx/) is an Ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer.
+
+**Notice: If your cluster is already have any kinds of [ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/), you don't need to enable this addon.**
+
+## Install
+
+```shell
+vela addon enable ingrss-controller
+```
+
+## Setup with Specified Service Type
+
+There are three service types for this addon which aligned with Kubernetes service, they're `ClusterIP`, `NodePort` and `LoadBalancer`.
+By default, the service type is ClusterIP for security.
+
+- `LoadBalancer` type requires your cluster has cloud LoadBalancer available.
+    ```shell script
+    vela addon enable ingrss-controller serviceType=LoadBalancer
+    ```
+- `NodePort` type requires you can access the Kubernetes Node IP/Port.
+    ```shell script
+    vela addon enable ingrss-controller serviceType=NodePort
+    ```
+
+## Get access address 
+
+After specify the service type to `LoadBalancer` or `NodePort`, you can obtain the access address through `vela status`:
+
+```shell
+vela status addon-ingrss-controller -n vela-system --endpoint
+```
+
+If the service type is `ClusterIP`, you use `vela port-forward` map the ingrss-controller's port to local
+
+```shell
+vela port-forward -n vela-system addon-ingress-controller 9080:80
+```
+
+## Uninstall
+
+```shell
+vela addon disable ingrss-controller
+```
+
+## Example
+
+Use this addon by deploy an application:
+
+```yaml
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: demo
+spec:
+  components:
+  - name: demo
+    type: webservice
+    properties:
+      image: barnett/canarydemo:v1
+      ports:
+      - port: 8090
+    traits:
+    - type: gateway
+      properties:
+        domain: canary-demo.com
+        http:
+          "/version": 8090
+EOF
+```
+
+Then access the gateway's endpoint will see:
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-endpoint>/version
+Demo: V1
+```
\ No newline at end of file
diff --git a/docs/reference/addons/overview.md b/docs/reference/addons/overview.md
index dc5c6ea7..959544f8 100644
--- a/docs/reference/addons/overview.md
+++ b/docs/reference/addons/overview.md
@@ -20,5 +20,7 @@ There's an community addon registry (https://addons.kubevela.net) maintained by
 * [KubeVela doc](./kubevela-io) Help you to read the KubeVela document in your cluster which can be air-gaped environment.
 * [Flink kubernetes operator](./flink-kubernetes-operator) A Kubernetes operator for Apache Flink(https://github.com/apache/flink-kubernetes-operator).
 * [dex](./dex) Provide [dex](https://github.com/dexidp/dex) login for VelaUX.
+* [Kruise Rollout](./kruise-rollout): [OpenKruise rollout](https://github.com/openkruise/rollouts) supports canary rollout for native deployment, stateful-set and OpenKruise [cloneset](https://openkruise.io/docs/user-manuals/cloneset/).
+* [ingress-nginx](./nginx-ingress-controller): An Ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer.
 
 **If you want to make your own addon please refer to [doc](../../platform-engineers/addon/intro.md).**
\ No newline at end of file
diff --git a/docs/resources/kruise-rollout-v1.jpg b/docs/resources/kruise-rollout-v1.jpg
new file mode 100644
index 00000000..6a3ad674
Binary files /dev/null and b/docs/resources/kruise-rollout-v1.jpg differ
diff --git a/docs/resources/kruise-rollout-v2.jpg b/docs/resources/kruise-rollout-v2.jpg
new file mode 100644
index 00000000..99df6e1e
Binary files /dev/null and b/docs/resources/kruise-rollout-v2.jpg differ
diff --git a/docs/tutorials/helm-rollout.md b/docs/tutorials/helm-rollout.md
new file mode 100644
index 00000000..0580b834
--- /dev/null
+++ b/docs/tutorials/helm-rollout.md
@@ -0,0 +1,184 @@
+---
+title: Canary Rollout Helm chart
+---
+
+## Before starting
+
+1. Please make sure you have read the doc of about [deploying helm chart](./helm).
+
+2. Make sure you have already enableld the kruise-rollout addon.
+```shell
+% vela addon enable kruise-rollout
+Addon: kruise-rollout enabled Successfully.
+```
+
+3. Please make sure one of the [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) is available in your Kubernetes cluster.
+   If not, you can install one in your cluster by enable the [ingress-nginx](../reference/addons/nginx-ingress-controller) addon:
+
+```shell
+vela addon enable ingress-nginx
+```
+
+Please refer [this](../reference/addons/nginx-ingress-controller) to get the gateway's access address.
+
+**You also can choose to install [traefik](../reference/addons/traefik) addon.**
+
+4. Please make sure the version of  Vela CLI tool `>=1.5.0-alpha.1`, some commands such as rollback rely on the new version.
+
+### First deployment
+
+When you want to use the canary rollout, you need to add the `kruise-rollout` trait at the first time, this configuration will take effect at next release process. Deploy the application with traits like below:
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+  annotations:
+    app.oam.dev/publishVersion: v1
+spec:
+  components:
+  - name: canary-demo
+    type: helm
+    properties:
+      repoType: "helm"
+      url: "https://wangyikewxgm.github.io/my-charts/"
+      chart: "canary-demo"
+      version: "1.0.0"
+    traits:
+    - type: kruise-rollout
+      properties:
+        canary:
+          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
+          steps:
+          - weight: 20
+          # The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
+          - weight: 90
+          trafficRoutings:
+          - type: nginx
+EOF
+```
+
+This is a general helm chart created by `helm create` command, which contains a deployment whose image is `barnett/canarydemo:v1`, a service and an ingress. You can check the source of chart in [repo](https://github.com/wangyikewxgm/my-charts/tree/main/canary-demo).
+
+Access the gateway endpoint. You can see the result always is `Demo: V1`
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+```
+
+### Canary Rollout
+
+Update the target version of helm chart from `1.0.0` to `2.0.0`:
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+  annotations:
+    app.oam.dev/publishVersion: v2
+spec:
+  components:
+  - name: canary-demo
+    type: helm
+    properties:
+      repoType: "helm"
+      url: "https://wangyikewxgm.github.io/my-charts/"
+      chart: "canary-demo"
+      # Upgade to version 2.0.0
+      version: "2.0.0"
+    traits:
+    - type: kruise-rollout
+      properties:
+        canary:
+          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
+          steps:
+          - weight: 20
+          # The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
+          - weight: 90
+          trafficRoutings:
+          - type: nginx
+EOF
+```
+
+The only difference between two versions is image tag. Version `2.0.0` uses `barnett/canarydemo:v2`.
+
+Access the gateway endpoint again. You will find out there is about 20% chance to meet `Demo: v2` result.
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V2
+```
+
+The other operations such as `continue rollout/rollback` are totally same with the operation for webservice component.
+
+
+### Continue rollout process
+
+After verify the success of the canary version through business-related metrics, such as logs, metrics, and other means, you can resume the workflow to continue the process of rollout.
+
+```shell
+vela workflow resume canary-demo
+```
+
+Access the gateway endpoint again multi times. You will find out the chance to meet result `Demo: v2` is highly increased, almost 90%.
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V2
+```
+
+### Canary validation successful, full release
+
+In the end, you can resume again to finish the rollout process.
+
+```shell
+vela workflow resume canary-demo
+```
+
+Access the gateway endpoint again multi times. You will find out the result always is `Demo: v2`.
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V2
+```
+
+### Canary verification failed, rollback
+
+If you want to cancel the rollout process and rollback the application to the latest version, after manually check. You can rollback the rollout workflow:
+
+You should suspend the workflow before rollback:
+```shell
+$ vela workflow suspend canary-demo
+Rollout default/canary-demo in cluster  suspended.
+Successfully suspend workflow: canary-demo
+```
+
+Then rollback:
+```shell
+$ vela workflow rollback canary-demo
+Application spec rollback successfully.
+Application status rollback successfully.
+Rollout default/canary-demo in cluster  rollback.
+Successfully rollback rolloutApplication outdated revision cleaned up.
+```
+
+Access the gateway endpoint again. You can see the result always is `Demo: V1`.
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+```
+
+Please notice: rollback operation in middle of a runningWorkflow will rollback to latest succeed revision which is `v1` in this case.
+Image a scenario, you deploy a successful `v1` and canary rollout to `v2`, but you find some error in this version, then you continue to rollout to `v3` directly. Error still exists, application is unhealthy then you decide to rollback.
+When you execute rollback workload will let application rollback to version `v1`.
+
+##Limitation
+
+1. As you can see, the helm chart used in this tutorial contains a service point to workload, an ingress route to the service. 
+If your helm chart doesn't have service or ingress that need not exposure the service, you cannot reproduce the canary rollout with this chart.
+   
+2. Currently, canary rollout has supported several types of workloads such as deployment, statefulset, and [open-kruise cloneset](https://openkruise.io/docs/user-manuals/cloneset/). That means the workload in your helm chart must be one of this three types.
\ No newline at end of file
diff --git a/docs/tutorials/k8s-object-rollout.md b/docs/tutorials/k8s-object-rollout.md
new file mode 100644
index 00000000..a1c5b25e
--- /dev/null
+++ b/docs/tutorials/k8s-object-rollout.md
@@ -0,0 +1,310 @@
+---
+title: Canary Rollout Kubernetes Objects
+---
+
+## Before starting
+
+1. Please make sure you have read the doc of about [deploying helm chart](./helm).
+
+2. Make sure you have already enableld the kruise-rollout addon.
+```shell
+% vela addon enable kruise-rollout
+Addon: kruise-rollout enabled Successfully.
+```
+
+3. Please make sure one of the [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) is available in your Kubernetes cluster.
+   If not, you can install one in your cluster by enable the [ingress-nginx](../reference/addons/nginx-ingress-controller) addon:
+
+```shell
+vela addon enable ingress-nginx
+```
+
+Please refer [this](../reference/addons/nginx-ingress-controller) to get the gateway's access address.
+
+**You also can choose to install [traefik](../reference/addons/traefik) addon.**
+
+4. Please make sure the version of  Vela CLI tool `>=1.5.0-alpha.1`, some commands such as rollback rely on the new version.
+
+### First deployment
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+  namespace: default
+  annotations:
+    app.oam.dev/publishVersion: v1
+spec:
+  components:
+    - name: canary-demo
+      properties:
+        objects:
+          - apiVersion: apps/v1
+            kind: Deployment
+            metadata:
+              name: canary-demo
+            spec:
+              replicas: 5
+              selector:
+                matchLabels:
+                  app: demo
+              template:
+                metadata:
+                  labels:
+                    app: demo
+                spec:
+                  containers:
+                    - image: barnett/canarydemo:v1
+                      name: demo
+                      ports:
+                        - containerPort: 8090
+          - apiVersion: v1
+            kind: Service
+            metadata:
+              labels:
+                app: demo
+              name: canary-demo
+              namespace: default
+            spec:
+              ports:
+                - name: http
+                  port: 8090
+                  protocol: TCP
+                  targetPort: 8090
+              selector:
+                app: demo
+          - apiVersion: networking.k8s.io/v1
+            kind: Ingress
+            metadata:
+              labels:
+                app: demo
+              name: canary-demo
+              namespace: default
+            spec:
+              ingressClassName: nginx
+              rules:
+                - host: canary-demo.com
+                  http:
+                    paths:
+                      - backend:
+                          service:
+                            name: canary-demo
+                            port:
+                              number: 8090
+                        path: /version
+                        pathType: ImplementationSpecific
+      type: k8s-objects
+      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
+                # The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
+                - weight: 90
+              trafficRoutings:
+                - type: nginx
+EOF
+```
+
+Access the gateway endpoint with the specific host.
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+``` 
+
+
+## Canary Release
+Modify the image tag, from v1 to v2, as follows:
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+  namespace: default
+  annotations:
+    app.oam.dev/publishVersion: v2
+spec:
+  components:
+    - name: canary-demo
+      properties:
+        objects:
+          - apiVersion: apps/v1
+            kind: Deployment
+            metadata:
+              name: canary-demo
+            spec:
+              replicas: 5
+              selector:
+                matchLabels:
+                  app: demo
+              template:
+                metadata:
+                  labels:
+                    app: demo
+                spec:
+                  containers:
+                    - image: barnett/canarydemo:v2
+                      name: demo
+                      ports:
+                        - containerPort: 8090
+          - apiVersion: v1
+            kind: Service
+            metadata:
+              labels:
+                app: demo
+              name: canary-demo
+              namespace: default
+            spec:
+              ports:
+                - name: http
+                  port: 8090
+                  protocol: TCP
+                  targetPort: 8090
+              selector:
+                app: demo
+          - apiVersion: networking.k8s.io/v1
+            kind: Ingress
+            metadata:
+              labels:
+                app: demo
+              name: canary-demo
+              namespace: default
+            spec:
+              ingressClassName: nginx
+              rules:
+                - host: canary-demo.com
+                  http:
+                    paths:
+                      - backend:
+                          service:
+                            name: canary-demo
+                            port:
+                              number: 8090
+                        path: /version
+                        pathType: ImplementationSpecific
+      type: k8s-objects
+      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
+                # The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
+                - weight: 90
+              trafficRoutings:
+                - type: nginx
+EOF
+```
+
+The configuration strategy of kruise-rollout trait means: The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed.
+
+Check the status of applciation:
+```shell
+$ vela status canary-demo
+About:
+
+  Name:         canary-demo                  
+  Namespace:    default                      
+  Created at:   2022-06-09 16:43:10 +0800 CST
+  Status:       runningWorkflow              
+
+Workflow:
+
+  mode: DAG
+  finished: false
+  Suspend: false
+  Terminated: false
+  Steps
+  - id:8adxa11wku
+    name:canary-demo
+    type:apply-component
+    phase:running 
+    message:wait healthy
+
+Services:
+
+  - Name: canary-demo  
+    Cluster: local  Namespace: default
+    Type: webservice
+    Unhealthy Ready:5/5
+    Traits:
+      ✅ scaler      ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
+      ❌ kruise-rollout: Rollout is in step(1/1), and you need manually confirm to enter the next step
+
+```
+
+The application's status is `runningWorkflow` that means the application's rollout process has not finished yet.
+
+Access the gateway endpoint again. You will find out there is about 20% chance to meet `Demo: v2` result.
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V2
+```
+
+## Continue rollout process
+
+After verify the success of the canary version through business-related metrics, such as logs, metrics, and other means, you can resume the workflow to continue the process of rollout.
+
+```shell
+vela workflow resume canary-demo
+```
+
+Access the gateway endpoint again multi times. You will find out the chance to meet result `Demo: v2` is highly increased, almost 90%.
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V2
+```
+
+## Canary validation successful, full release
+
+In the end, you can resume again to finish the rollout process.
+
+```shell
+vela workflow resume canary-demo
+```
+
+Access the gateway endpoint again multi times. You will find out the result always is `Demo: v2`.
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V2
+```
+
+## Canary verification failed, rollback
+
+If you want to cancel the rollout process and rollback the application to the latest version, after manually check. You can rollback the rollout workflow:
+
+You should suspend the workflow before rollback:
+```shell
+$ vela workflow suspend canary-demo
+Rollout default/canary-demo in cluster  suspended.
+Successfully suspend workflow: canary-demo
+```
+
+Then rollback:
+```shell
+$ vela workflow rollback canary-demo
+Application spec rollback successfully.
+Application status rollback successfully.
+Rollout default/canary-demo in cluster  rollback.
+Successfully rollback rolloutApplication outdated revision cleaned up.
+```
+
+Access the gateway endpoint again. You can see the result always is `Demo: V1`.
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+```
+
+**Please notice**: rollback operation in middle of a runningWorkflow will rollback to latest succeed revision which is `v1` in this case.
+Image a scenario, you deploy a successful `v1` and canary rollout to `v2`, but you find some error in this version, then you continue to rollout to `v3` directly. Error still exists, application is unhealthy then you decide to rollback.
+When you execute rollback workload will let application rollback to version `v1`.
\ No newline at end of file
diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/reference/addons/kruise-rollout.md b/i18n/zh/docusaurus-plugin-content-docs/current/reference/addons/kruise-rollout.md
new file mode 100644
index 00000000..0b9daad6
--- /dev/null
+++ b/i18n/zh/docusaurus-plugin-content-docs/current/reference/addons/kruise-rollout.md
@@ -0,0 +1,310 @@
+---
+title: Kruise-rollout
+---
+
+Kruise Rollout对原生Deployment、Kruise CloneSet提供渐进式交付的能力，例如：金丝雀发布、蓝绿发布、A/B Testing等，更多详情请参考：[Kruise Rollout](https://github.com/openkruise/rollouts/blob/master/docs/getting_started/introduction.md)。
+
+本文主要介绍如何使用Kruise Rollout实现金丝雀发布。
+
+## 准备工作
+
+1. 安装Kruise Rollout
+```shell
+% vela addon enable kruise-rollout
+enable addon by local dir: addons/kruise-rollout
+Addon: kruise-rollout enabled Successfully.
+```
+
+2. 请保证你的集群有一种  [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) 正在运行。
+如果没有你可以通过启用  [nginx-ingress-controller](./nginx-ingress-controller) 安装一个。
+
+```shell
+vela addon enable ingress-controller
+```
+
+请参考[文档](./nginx-ingress-controller) 获取网关的访问地址。
+
+## 首次部署
+
+部署应用:
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+  annotations:
+    app.oam.dev/publishVersion: v1
+spec:
+  components:
+  - name: canary-demo
+    type: webservice
+    properties:
+      image: barnett/canarydemo:v1
+      ports:
+      - port: 8090
+    traits:
+    - type: scaler
+      properties:
+        replicas: 5
+    - type: gateway
+      properties:
+        domain: canary-demo.com
+        http:
+          "/version": 8090
+    - type: kruise-rollout
+      properties:
+        canary:
+          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
+          steps:
+          - weight: 20
+          trafficRoutings:
+            - type: nginx
+EOF
+```
+
+检查应用状态，发现应用已经出于 `Running` 状态。
+
+
+```shell
+$ vela status canary-demo
+About:
+
+  Name:         canary-demo                  
+  Namespace:    default                      
+  Created at:   2022-06-09 16:43:10 +0800 CST
+  Status:       running                      
+
+Workflow:
+
+  mode: DAG
+  finished: true
+  Suspend: false
+  Terminated: false
+  Steps
+  - id:x6rnat7iby
+    name:canary-demo
+    type:apply-component
+    phase:succeeded 
+    message:
+
+Services:
+
+  - Name: canary-demo  
+    Cluster: local  Namespace: default
+    Type: webservice
+    Healthy Ready:5/5
+    Traits:
+      ✅ scaler      ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
+      ✅ kruise-rollout: rollout is healthy
+
+```
+
+用上面定义的路径和 Host 访问网关:
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+``` 
+
+## 金丝雀发布
+修改镜像标签 v1 -> v2：
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+  annotations:
+    app.oam.dev/publishVersion: v2
+spec:
+  components:
+  - name: canary-demo
+    type: webservice
+    properties:
+      image: barnett/canarydemo:v2
+      ports:
+      - port: 8090
+    traits:
+    - type: scaler
+      properties:
+        replicas: 5
+    - type: gateway
+      properties:
+        domain: canary-demo.com
+        http:
+          "/version": 8090
+    - type: kruise-rollout
+      properties:
+        canary:
+          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
+          steps:
+          - weight: 20
+          trafficRoutings:
+          - type: nginx
+EOF
+```
+
+请注意这里的 kurise-rollout 运维特征里升级策略的配置，这里的含义是先金丝雀发布一批，该批次包含了20%的实例个数，并将20%的流量导入到新版本实例中。
+检查 app 的状态：
+```shell
+$ vela status canary-demo
+About:
+
+  Name:         canary-demo                  
+  Namespace:    default                      
+  Created at:   2022-06-09 16:43:10 +0800 CST
+  Status:       runningWorkflow              
+
+Workflow:
+
+  mode: DAG
+  finished: false
+  Suspend: false
+  Terminated: false
+  Steps
+  - id:8adxa11wku
+    name:canary-demo
+    type:apply-component
+    phase:running 
+    message:wait healthy
+
+Services:
+
+  - Name: canary-demo  
+    Cluster: local  Namespace: default
+    Type: webservice
+    Unhealthy Ready:5/5
+    Traits:
+      ✅ scaler      ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
+      ❌ kruise-rollout: Rollout is in step(1/1), and you need manually confirm to enter the next step
+
+```
+
+application 的状态处于 `runningWorkflow` 意味着发布尚未完成。
+再次访问网关，你会发现有20%的机率看到新版本的结果 `Demo: v2`:
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V2
+```
+
+## 金丝雀验证OK，全量发布
+
+用户通过业务的相关指标，如：日志、Metrics等其它手段，验证金丝雀版本OK之后，继续执行工作流发布继续发布。
+
+
+```shell
+vela workflow resume canary-demo
+```
+
+## 金丝雀验证失败，回滚
+
+如果经过验证发现新版本有问题，你想中断发布，将应用回滚至上一个版本。可以如下操作：
+
+```shell
+vela workflow rollback canary-demo
+```
+
+回滚完成之后，访问网关，你会发现结果一直都是 `Demo: V1`：
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+```
+
+## Helm 应用的金丝雀发布
+
+### 首次部署：
+
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+  annotations:
+    app.oam.dev/publishVersion: v1
+spec:
+  components:
+  - name: canary-demo
+    type: helm
+    properties:
+      repoType: "helm"
+      url: "https://wangyikewxgm.github.io/my-charts/"
+      chart: "canary-demo"
+      version: "1.0.0"
+    traits:
+    - type: kruise-rollout
+      properties:
+        workloadType:
+           apiVersion: apps/v1
+           kind: Deployment
+        canary:
+          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
+          steps:
+          - weight: 20
+          trafficRoutings:
+          - type: nginx
+EOF
+```
+
+应用所使用的 chart 中包含了一个使用了 `barnett/canarydemo:v1` 镜像的 Deployment。
+
+另外，请注意你需要天蝎 kruise-rollout trait 中 `workloadType` 的字段，因为一个 chart 中可能包含各种资源，你需要指出发布资源的类型。
+
+部署成功之后，访问网关：
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+```
+
+### 金丝雀发布
+
+通过下面的步骤将 chart 的版本从 `1.0.0` 更新到 `2.0.0`：
+
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+  annotations:
+    app.oam.dev/publishVersion: v2
+spec:
+  components:
+  - name: canary-demo
+    type: helm
+    properties:
+      repoType: "helm"
+      url: "https://wangyikewxgm.github.io/my-charts/"
+      chart: "canary-demo"
+      # Upgade to version 2.0.0
+      version: "2.0.0"
+    traits:
+    - type: kruise-rollout
+      properties:
+        workloadType:
+           apiVersion: apps/v1
+           kind: Deployment
+        canary:
+          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
+          steps:
+          - weight: 20
+          trafficRoutings:
+          - type: nginx
+EOF
+```
+
+这两个版本直接的唯一差别是，新版本的镜像使用的是 v2 版本的 `barnett/canarydemo:v2`，再次访问网关，你会发现有20%的机率看到新版本的结果 `Demo: v2`:
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V2
+```
+
+其他 `继续发布/回滚` 等操作和上面的 webservice 的类型组件完全一致。
\ No newline at end of file
diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/reference/addons/nginx-ingress-controller.md b/i18n/zh/docusaurus-plugin-content-docs/current/reference/addons/nginx-ingress-controller.md
new file mode 100644
index 00000000..13e7d33d
--- /dev/null
+++ b/i18n/zh/docusaurus-plugin-content-docs/current/reference/addons/nginx-ingress-controller.md
@@ -0,0 +1,81 @@
+---
+title: Nginx Ingress Controller
+---
+
+[Nginx Ingress controller](https://kubernetes.github.io/ingress-nginx/) 通过借助 nginx 实现了 Ingress controller 的功能为集群提供代理和负载均衡的功能。
+
+##  安装
+
+```shell
+vela addon enable ingrss-controller
+```
+
+## 指定 Service Type
+
+可以选择三种服务类型，出于安全考虑默认是 `ClusterIP`，还可以指定为`NodePort` 和 `LoadBalancer`。
+
+- `LoadBalancer` 需要你的集群运行在某个公有云上，并有一种支持的 cloud LoadBalancer。
+    ```shell script
+    vela addon enable ingrss-controller serviceType=LoadBalancer
+    ```   
+  
+- `NodePort` 类型需要你能够访问集群节点的 IP和端口
+    ```shell script
+    vela addon enable ingrss-controller serviceType=NodePort
+    ```
+  
+## 获取网关地址
+
+如果指定了服务类型是 `NodePort` 和 `LoadBalancer`，你可以通过下面的命令，获取到网关的地址：
+
+```shell
+vela status addon-ingrss-controller -n vela-system --endpoint
+```
+
+如果是 `ClusterIP` 类型，又可以通过 `vela port-forward` 命令将网关的端口映射到本地：
+
+```shell
+vela port-forward -n vela-system addon-ingress-controller 9080:80
+```
+
+## 卸载
+
+```shell
+vela addon disable ingrss-controller
+```
+
+## 例子
+
+部署下面的应用：
+```yaml
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: demo
+spec:
+  components:
+  - name: demo
+    type: webservice
+    properties:
+      image: barnett/canarydemo:v1
+      ports:
+      - port: 8090
+    traits:
+    - type: gateway
+      properties:
+        domain: canary-demo.com
+        http:
+          "/version": 8090
+EOF
+```
+
+访问网关地址：
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-endpoint>/version
+Demo: V1
+```
+
+
+
diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.4/reference/addons/kruise-rollout.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.4/reference/addons/kruise-rollout.md
new file mode 100644
index 00000000..db360e90
--- /dev/null
+++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.4/reference/addons/kruise-rollout.md
@@ -0,0 +1,294 @@
+---
+title: Kruise-rollout
+---
+
+Kruise Rollout对原生Deployment、Kruise CloneSet提供渐进式交付的能力，例如：金丝雀发布、蓝绿发布、A/B Testing等，更多详情请参考：[Kruise Rollout](https://github.com/openkruise/rollouts/blob/master/docs/getting_started/introduction.md)。
+
+本文主要介绍如何使用Kruise Rollout实现金丝雀发布。
+
+## 准备工作
+
+1. 安装Kruise Rollout
+```shell
+% vela addon enable kruise-rollout
+enable addon by local dir: addons/kruise-rollout
+Addon: kruise-rollout enabled Successfully.
+```
+
+2. 请保证你的集群有一种  [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) 正在运行。
+如果没有你可以通过启用  [nginx-ingress-controller](./nginx-ingress-controller) 安装一个。
+
+```shell
+vela addon enable ingress-controller
+```
+
+请参考[文档](./nginx-ingress-controller) 获取网关的访问地址。
+
+## 首次部署
+
+部署应用:
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+spec:
+  components:
+  - name: canary-demo
+    type: webservice
+    properties:
+      image: barnett/canarydemo:v1
+      ports:
+      - port: 8090
+    traits:
+    - type: scaler
+      properties:
+        replicas: 5
+    - type: gateway
+      properties:
+        domain: canary-demo.com
+        http:
+          "/version": 8090
+    - type: kruise-rollout
+      properties:
+        canary:
+          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
+          steps:
+          - weight: 20
+EOF
+```
+
+检查应用状态，发现应用已经出于 `Running` 状态。
+
+
+```shell
+$ vela status canary-demo
+About:
+
+  Name:         canary-demo                  
+  Namespace:    default                      
+  Created at:   2022-06-09 16:43:10 +0800 CST
+  Status:       running                      
+
+Workflow:
+
+  mode: DAG
+  finished: true
+  Suspend: false
+  Terminated: false
+  Steps
+  - id:x6rnat7iby
+    name:canary-demo
+    type:apply-component
+    phase:succeeded 
+    message:
+
+Services:
+
+  - Name: canary-demo  
+    Cluster: local  Namespace: default
+    Type: webservice
+    Healthy Ready:5/5
+    Traits:
+      ✅ scaler      ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
+      ✅ kruise-rollout: rollout is healthy
+
+```
+
+用上面定义的路径和 Host 访问网关:
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+``` 
+
+## 金丝雀发布
+修改镜像标签 v1 -> v2：
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+spec:
+  components:
+  - name: canary-demo
+    type: webservice
+    properties:
+      image: barnett/canarydemo:v2
+      ports:
+      - port: 8090
+    traits:
+    - type: scaler
+      properties:
+        replicas: 5
+    - type: gateway
+      properties:
+        domain: canary-demo.com
+        http:
+          "/version": 8090
+    - type: kruise-rollout
+      properties:
+        canary:
+          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
+          steps:
+          - weight: 20
+EOF
+```
+
+请注意这里的 kurise-rollout 运维特征里升级策略的配置，这里的含义是先金丝雀发布一批，该批次包含了20%的实例个数，并将20%的流量导入到新版本实例中。
+检查 app 的状态：
+```shell
+$ vela status canary-demo
+About:
+
+  Name:         canary-demo                  
+  Namespace:    default                      
+  Created at:   2022-06-09 16:43:10 +0800 CST
+  Status:       runningWorkflow              
+
+Workflow:
+
+  mode: DAG
+  finished: false
+  Suspend: false
+  Terminated: false
+  Steps
+  - id:8adxa11wku
+    name:canary-demo
+    type:apply-component
+    phase:running 
+    message:wait healthy
+
+Services:
+
+  - Name: canary-demo  
+    Cluster: local  Namespace: default
+    Type: webservice
+    Unhealthy Ready:5/5
+    Traits:
+      ✅ scaler      ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
+      ❌ kruise-rollout: Rollout is in step(1/1), and you need manually confirm to enter the next step
+
+```
+
+application 的状态处于 `runningWorkflow` 意味着发布尚未完成。
+再次访问网关，你会发现有20%的机率看到新版本的结果 `Demo: v2`:
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V2
+```
+
+## 金丝雀验证OK，全量发布
+
+用户通过业务的相关指标，如：日志、Metrics等其它手段，验证金丝雀版本OK之后，继续执行工作流发布继续发布。
+
+
+```shell
+vela workflow resume canary-demo
+```
+
+## 金丝雀验证失败，回滚
+
+如果经过验证发现新版本有问题，你想中断发布，将应用回滚至上一个版本。可以如下操作：
+
+```shell
+vela workflow rollback canary-demo
+```
+
+回滚完成之后，访问网关，你会发现结果一直都是 `Demo: V1`：
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+```
+
+## Helm 应用的金丝雀发布
+
+### 首次部署：
+
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+spec:
+  components:
+  - name: canary-demo
+    type: helm
+    properties:
+      repoType: "helm"
+      url: "https://wangyikewxgm.github.io/my-charts/"
+      chart: "canary-demo"
+      version: "1.0.0"
+    traits:
+    - type: kruise-rollout
+      properties:
+        workloadType:
+           apiVersion: apps/v1
+           kind: Deployment
+        canary:
+          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
+          steps:
+          - weight: 20
+EOF
+```
+
+应用所使用的 chart 中包含了一个使用了 `barnett/canarydemo:v1` 镜像的 Deployment。
+
+另外，请注意你需要天蝎 kruise-rollout trait 中 `workloadType` 的字段，因为一个 chart 中可能包含各种资源，你需要指出发布资源的类型。
+
+部署成功之后，访问网关：
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+```
+
+### 金丝雀发布
+
+通过下面的步骤将 chart 的版本从 `1.0.0` 更新到 `2.0.0`：
+
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+spec:
+  components:
+  - name: canary-demo
+    type: helm
+    properties:
+      repoType: "helm"
+      url: "https://wangyikewxgm.github.io/my-charts/"
+      chart: "canary-demo"
+      # Upgade to version 2.0.0
+      version: "2.0.0"
+    traits:
+    - type: kruise-rollout
+      properties:
+        workloadType:
+           apiVersion: apps/v1
+           kind: Deployment
+        canary:
+          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
+          steps:
+          - weight: 20
+EOF
+```
+
+这两个版本直接的唯一差别是，新版本的镜像使用的是 v2 版本的 `barnett/canarydemo:v2`，再次访问网关，你会发现有20%的机率看到新版本的结果 `Demo: v2`:
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V2
+```
+
+其他 `继续发布/回滚` 等操作和上面的 webservice 的类型组件完全一致。
\ No newline at end of file
diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-v1.4/reference/addons/nginx-ingress-controller.md b/i18n/zh/docusaurus-plugin-content-docs/version-v1.4/reference/addons/nginx-ingress-controller.md
new file mode 100644
index 00000000..13e7d33d
--- /dev/null
+++ b/i18n/zh/docusaurus-plugin-content-docs/version-v1.4/reference/addons/nginx-ingress-controller.md
@@ -0,0 +1,81 @@
+---
+title: Nginx Ingress Controller
+---
+
+[Nginx Ingress controller](https://kubernetes.github.io/ingress-nginx/) 通过借助 nginx 实现了 Ingress controller 的功能为集群提供代理和负载均衡的功能。
+
+##  安装
+
+```shell
+vela addon enable ingrss-controller
+```
+
+## 指定 Service Type
+
+可以选择三种服务类型，出于安全考虑默认是 `ClusterIP`，还可以指定为`NodePort` 和 `LoadBalancer`。
+
+- `LoadBalancer` 需要你的集群运行在某个公有云上，并有一种支持的 cloud LoadBalancer。
+    ```shell script
+    vela addon enable ingrss-controller serviceType=LoadBalancer
+    ```   
+  
+- `NodePort` 类型需要你能够访问集群节点的 IP和端口
+    ```shell script
+    vela addon enable ingrss-controller serviceType=NodePort
+    ```
+  
+## 获取网关地址
+
+如果指定了服务类型是 `NodePort` 和 `LoadBalancer`，你可以通过下面的命令，获取到网关的地址：
+
+```shell
+vela status addon-ingrss-controller -n vela-system --endpoint
+```
+
+如果是 `ClusterIP` 类型，又可以通过 `vela port-forward` 命令将网关的端口映射到本地：
+
+```shell
+vela port-forward -n vela-system addon-ingress-controller 9080:80
+```
+
+## 卸载
+
+```shell
+vela addon disable ingrss-controller
+```
+
+## 例子
+
+部署下面的应用：
+```yaml
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: demo
+spec:
+  components:
+  - name: demo
+    type: webservice
+    properties:
+      image: barnett/canarydemo:v1
+      ports:
+      - port: 8090
+    traits:
+    - type: gateway
+      properties:
+        domain: canary-demo.com
+        http:
+          "/version": 8090
+EOF
+```
+
+访问网关地址：
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-endpoint>/version
+Demo: V1
+```
+
+
+
diff --git a/sidebars.js b/sidebars.js
index 2f81c8a8..f6a6ea13 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -32,13 +32,14 @@ module.exports = {
             'case-studies/multi-cluster',
             'tutorials/access-application',
             'end-user/traits/sidecar',
+            'end-user/traits/rollout',
           ],
         },
         {
           type: 'category',
           label: 'Helm Chart CD',
           collapsed: true,
-          items: ['tutorials/helm', 'tutorials/helm-multi-cluster'],
+          items: ['tutorials/helm', 'tutorials/helm-multi-cluster', 'tutorials/helm-rollout'],
         },
         {
           type: 'category',
@@ -60,7 +61,7 @@ module.exports = {
           type: 'category',
           label: 'Kubernetes Manifest CD',
           collapsed: true,
-          items: ['tutorials/k8s-object', 'end-user/components/ref-objects'],
+          items: ['tutorials/k8s-object', 'end-user/components/ref-objects', "tutorials/k8s-object-rollout"],
         },
         {
           type: 'category',
diff --git a/versioned_docs/version-v1.4/reference/addons/kruise-rollout.md b/versioned_docs/version-v1.4/reference/addons/kruise-rollout.md
new file mode 100644
index 00000000..54acdc79
--- /dev/null
+++ b/versioned_docs/version-v1.4/reference/addons/kruise-rollout.md
@@ -0,0 +1,298 @@
+---
+title: kruise-rollout
+---
+
+Kruise Rollout addon provides incremental delivery capabilities for Native Deployment, Kruise CloneSet, e.g. Canary Release, Blue-green Release, A/B Testing, etc.
+For more details, please refer to: [Kruise Rollout](https://github.com/openkruise/rollouts/blob/master/docs/getting_started/introduction.md).
+
+This article focuses on how to implement Canary Release using Kruise Rollout addon.
+
+## Requirements
+
+1. Install Kruise Rollout
+```shell
+% vela addon enable kruise-rollout
+enable addon by local dir: addons/kruise-rollout
+Addon: kruise-rollout enabled Successfully.
+```
+
+2. Please make sure one of the [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) is available in your Kubernetes cluster.
+If not yet, you can install one in your cluster by enable the [nginx-ingress-controller](./nginx-ingress-controller) addon:
+
+```shell
+vela addon enable ingress-controller
+```
+
+Please refer [this](./nginx-ingress-controller) to get the gateway's access address.
+
+
+## First Deployment
+
+Deploy the application:
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+spec:
+  components:
+  - name: canary-demo
+    type: webservice
+    properties:
+      image: barnett/canarydemo:v1
+      ports:
+      - port: 8090
+    traits:
+    - type: scaler
+      properties:
+        replicas: 5
+    - type: gateway
+      properties:
+        domain: canary-demo.com
+        http:
+          "/version": 8090
+    - type: kruise-rollout
+      properties:
+        canary:
+          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
+          steps:
+          - weight: 20
+EOF
+```
+
+Then check the status of application will find out the application is running.
+
+```shell
+$ vela status canary-demo
+About:
+
+  Name:         canary-demo                  
+  Namespace:    default                      
+  Created at:   2022-06-09 16:43:10 +0800 CST
+  Status:       running                      
+
+Workflow:
+
+  mode: DAG
+  finished: true
+  Suspend: false
+  Terminated: false
+  Steps
+  - id:x6rnat7iby
+    name:canary-demo
+    type:apply-component
+    phase:succeeded 
+    message:
+
+Services:
+
+  - Name: canary-demo  
+    Cluster: local  Namespace: default
+    Type: webservice
+    Healthy Ready:5/5
+    Traits:
+      ✅ scaler      ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
+      ✅ kruise-rollout: rollout is healthy
+
+```
+
+Access the gateway endpoint with the specific host.
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+``` 
+
+
+## Canary Release
+Modify the webservice image tag, from v1 to v2, as follows:
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+spec:
+  components:
+  - name: canary-demo
+    type: webservice
+    properties:
+      image: barnett/canarydemo:v2
+      ports:
+      - port: 8090
+    traits:
+    - type: scaler
+      properties:
+        replicas: 5
+    - type: gateway
+      properties:
+        domain: canary-demo.com
+        http:
+          "/version": 8090
+    - type: kruise-rollout
+      properties:
+        canary:
+          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
+          steps:
+          - weight: 20
+EOF
+```
+
+The configuration strategy of kruise-rollout trait means: The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed.
+
+Check the status of applciation:
+```shell
+$ vela status canary-demo
+About:
+
+  Name:         canary-demo                  
+  Namespace:    default                      
+  Created at:   2022-06-09 16:43:10 +0800 CST
+  Status:       runningWorkflow              
+
+Workflow:
+
+  mode: DAG
+  finished: false
+  Suspend: false
+  Terminated: false
+  Steps
+  - id:8adxa11wku
+    name:canary-demo
+    type:apply-component
+    phase:running 
+    message:wait healthy
+
+Services:
+
+  - Name: canary-demo  
+    Cluster: local  Namespace: default
+    Type: webservice
+    Unhealthy Ready:5/5
+    Traits:
+      ✅ scaler      ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
+      ❌ kruise-rollout: Rollout is in step(1/1), and you need manually confirm to enter the next step
+
+```
+
+The application's status is `runningWorkflow` that means the application's rollout process has not finished yet.
+
+Access the gateway endpoint again. You will find out there is about 20% chance to meet `Demo: v2` result.
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V2
+```
+
+## Canary validation successful, full release
+
+After user verifies the success of the canary version through business-related metrics, such as logs, metrics, and other means, you can resume the workflow to continue the process of rollout.
+
+```shell
+vela workflow resume canary-demo
+```
+
+## Canary verification failed, rollback
+
+If you want to cancel the rollout process and rollback the application to the latest version, after manually check. You can use this command:
+```shell
+vela workflow rollback canary-demo
+```
+
+Access the gateway endpoint again. You can see the result always is `Demo: V1`
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+```
+
+## Rollout for helm component
+
+This capability of rollout also can be used for helm component.
+
+### First deployment
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+spec:
+  components:
+  - name: canary-demo
+    type: helm
+    properties:
+      repoType: "helm"
+      url: "https://wangyikewxgm.github.io/my-charts/"
+      chart: "canary-demo"
+      version: "1.0.0"
+    traits:
+    - type: kruise-rollout
+      properties:
+        workloadType:
+           apiVersion: apps/v1
+           kind: Deployment
+        canary:
+          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
+          steps:
+          - weight: 20
+EOF
+```
+
+This helm chart contain a deployment whose image is `barnett/canarydemo:v1`.
+
+Please notice the `workloadType` configuration of kruise-rollout trait. You must tell the trait witch kind of resource in the helm chart want to roll out.
+
+Access the gateway endpoint. You can see the result always is `Demo: V1`
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+```
+
+### Canary Rollout
+
+Update the target version of helm chart from `1.0.0` to `2.0.0`:
+
+```shell
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: canary-demo
+spec:
+  components:
+  - name: canary-demo
+    type: helm
+    properties:
+      repoType: "helm"
+      url: "https://wangyikewxgm.github.io/my-charts/"
+      chart: "canary-demo"
+      # Upgade to version 2.0.0
+      version: "2.0.0"
+    traits:
+    - type: kruise-rollout
+      properties:
+        workloadType:
+           apiVersion: apps/v1
+           kind: Deployment
+        canary:
+          # The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
+          steps:
+          - weight: 20
+EOF
+```
+
+The only difference between two versions is image tag. Version `2.0.0` uses `barnett/canarydemo:v2`.
+
+Access the gateway endpoint again. You will find out there is about 20% chance to meet `Demo: v2` result.
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V2
+```
+
+The other operations such as `continue rollout/rollback` are totally same with the operation for webservice component.
+
+
diff --git a/versioned_docs/version-v1.4/reference/addons/nginx-ingress-controller.md b/versioned_docs/version-v1.4/reference/addons/nginx-ingress-controller.md
new file mode 100644
index 00000000..ef66b749
--- /dev/null
+++ b/versioned_docs/version-v1.4/reference/addons/nginx-ingress-controller.md
@@ -0,0 +1,80 @@
+---
+title: Nginx Ingress Controller
+---
+
+
+[Nginx Ingress controller](https://kubernetes.github.io/ingress-nginx/) is an Ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer.
+
+## Install
+
+```shell
+vela addon enable ingrss-controller
+```
+
+## Setup with Specified Service Type
+
+There are three service types for this addon which aligned with Kubernetes service, they're `ClusterIP`, `NodePort` and `LoadBalancer`.
+By default the service type is ClusterIP for security.
+
+- `LoadBalancer` type requires your cluster has cloud LoadBalancer available.
+    ```shell script
+    vela addon enable ingrss-controller serviceType=LoadBalancer
+    ```
+- `NodePort` type requires you can access the Kubernetes Node IP/Port.
+    ```shell script
+    vela addon enable ingrss-controller serviceType=NodePort
+    ```
+
+## Get access address 
+
+After specify the service type to `LoadBalancer` or `NodePort`, you can obtain the access address through `vela status`:
+
+```shell
+vela status addon-ingrss-controller -n vela-system --endpoint
+```
+
+If the service type is `ClusterIP`, you use `vela port-forward` map the ingrss-controller's port to local
+
+```shell
+vela port-forward -n vela-system addon-ingress-controller 9080:80
+```
+
+## Uninstall
+
+```shell
+vela addon disable ingrss-controller
+```
+
+## Example
+
+Use this addon by deploy an application:
+
+```yaml
+cat <<EOF | vela up -f -
+apiVersion: core.oam.dev/v1beta1
+kind: Application
+metadata:
+  name: demo
+spec:
+  components:
+  - name: demo
+    type: webservice
+    properties:
+      image: barnett/canarydemo:v1
+      ports:
+      - port: 8090
+    traits:
+    - type: gateway
+      properties:
+        domain: canary-demo.com
+        http:
+          "/version": 8090
+EOF
+```
+
+Then access the gateway's endpoint will see:
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-endpoint>/version
+Demo: V1
+```
\ No newline at end of file
diff --git a/versioned_docs/version-v1.4/reference/addons/overview.md b/versioned_docs/version-v1.4/reference/addons/overview.md
index dc5c6ea7..7bb57633 100644
--- a/versioned_docs/version-v1.4/reference/addons/overview.md
+++ b/versioned_docs/version-v1.4/reference/addons/overview.md
@@ -20,5 +20,7 @@ There's an community addon registry (https://addons.kubevela.net) maintained by
 * [KubeVela doc](./kubevela-io) Help you to read the KubeVela document in your cluster which can be air-gaped environment.
 * [Flink kubernetes operator](./flink-kubernetes-operator) A Kubernetes operator for Apache Flink(https://github.com/apache/flink-kubernetes-operator).
 * [dex](./dex) Provide [dex](https://github.com/dexidp/dex) login for VelaUX.
+* [Rollout](./kruise-rollout): Base on KubeVela Rollout implementation canary rollout and other types of rollout.
+* [nginx-ingress-controller](./nginx-ingress-controller): An Ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer.
 
 **If you want to make your own addon please refer to [doc](../../platform-engineers/addon/intro.md).**
\ No newline at end of file