docs: rewrite canary rollout workflow documents (#1220)

* update rollout docs

Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com>

add velaux  rollout content

Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com>

optimze

Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com>

translate to Chinese

Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com>

delete uesless pic

Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com>

* use VelaUX

Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com>

* fix comments

Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com>

---------

Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com>

docs/end-user/traits/rollout.md

@@ -6,25 +6,14 @@ In this section, we will introduce how to canary rollout a container service.
 
 ## Before starting
 
-1. Enable [`kruise-rollout`](../../reference/addons/kruise-rollout) addon, our canary rollout capability relies on the [rollouts from OpenKruise](https://github.com/openkruise/rollouts).
-  ```shell
-  vela addon enable kruise-rollout
+Enable [`kruise-rollout`](../../reference/addons/kruise-rollout) addon, our canary rollout capability relies on the [rollouts from OpenKruise](https://github.com/openkruise/rollouts).
+```shell
+vela addon enable kruise-rollout
  ```
 
-2. Please make sure one of the [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) is available in your cluster.
-   You can also enable the [`ingress-nginx`](../../reference/addons/nginx-ingress-controller) addon if you don't have any:
-  ```shell
-  vela addon enable ingress-nginx
-  ```
-  Please refer to [the addon doc](../../reference/addons/nginx-ingress-controller) to get the access address of gateway.
-
-3. Some of the commands such as `rollback` relies on vela-cli `>=1.5.0-alpha.1`, please upgrade the command line for convenience. You don't need to upgrade the controller.
-
-
 ## First Time Deploy
 
-When you want to use the canary rollout for every upgrade, you should **ALWAYS** have a `kruise-rollout` trait on your component.
-The day-2 canary rollout of the component need you have this trait attached already. Deploy the application with traits like below:
+Deploy the application as shown below:
 
 ```yaml
 cat <<EOF | vela up -f -
@@ -39,7 +28,7 @@ spec:
       - name: canary-demo
         type: webservice
         properties:
-      image: barnett/canarydemo:v1
+           image: wangyikewyk/canarydemo:v1
            ports:
               - port: 8090
         traits:
@@ -51,27 +40,10 @@ spec:
                 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: ingress
 EOF
 ```
 
-Here's an **overview about what will happen** when upgrade under this `kruise-rollout` trait configuration, the whole process will be divided into 3 steps:
-
-1. When the upgrade start, a new canary deployment will be created with `20%` of the total replicas. In our example, we have 5 total replicas, it will keep all the old ones and create `5 * 20% = 1` for the new canary, and serve for `20%` of the traffic. It will wait for a manual approval when everything gets ready.
-   - By default, the percent of replicas are aligned with the traffic, you can also configure the replicas individually according to [this doc](../../reference/addons/kruise-rollout).
-2. After the manual approval, the second batch starts. It will create `5 * 90% = 4.5` which is actually `5` replicas of new version in the system with the `90%` traffic. As a result, the system will totally have `10` replicas now. It will wait for a second manual approval.
-3. After the second approval, it will update the workload which means leverage the rolling update mechanism of the workload itself for upgrade. After the workload finished the upgrade, all the traffic will route to that workload and the canary deployment will be destroyed.
-
-Let's continue our demo, the first deployment has no difference with a normal deploy, you can check the status of application to make sure it's running for our next step.
+The first deployment is a default way to deploy an application. You can check the status of the application to ensure it's running before proceeding to the next step.
 
 ```shell
 $ vela status canary-demo
@@ -79,10 +51,20 @@ About:
 
   Name:         canary-demo                  
   Namespace:    default                      
-  Created at:   2022-06-09 16:43:10 +0800 CST
+  Created at:   2023-04-10 14:27:58 +0800 CST
   Status:       running                      
 
-...snip...
+Workflow:
+
+  mode: DAG-DAG
+  finished: true
+  Suspend: false
+  Terminated: false
+  Steps
+  - id: c1cqamr5w6
+    name: canary-demo
+    type: apply-component
+    phase: succeeded 
 
 Services:
 
@@ -92,15 +74,13 @@ Services:
     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 that all `v1` pods are ready now.
 
 ![image](../../resources/kruise-rollout-v1.jpg)
 
-Access the gateway endpoint with the specific host by:
+If you have already installed an ingress controller (or you can install one by enable the [ingress-nginx](../../reference/addons/nginx-ingress-controller.md) addon), you can access the gateway endpoint with the specific host by:
 
 ```shell
 $ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
@@ -126,7 +106,7 @@ spec:
       - name: canary-demo
         type: webservice
         properties:
-      image: barnett/canarydemo:v2
+           image: wangyikewyk/canarydemo:v2
            ports:
               - port: 8090
         traits:
@@ -138,19 +118,36 @@ spec:
                 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
+   workflow:
       steps:
-          - weight: 20
-          - weight: 90
-          trafficRoutings:
-          - type: ingress
+         - type: canary-deploy
+           name: rollout-20
+           properties:
+              weight: 20
+         - name: suspend-1st
+           type: suspend
+         - type: canary-deploy
+           name: rollout-50
+           properties:
+              weight: 50
+         - name: suspend-2nd
+           type: suspend
+         - type: canary-deploy
+           name: rollout-100
+           properties:
+              weight: 100
 EOF
 ```
 
-It will create a canary deployment and wait for manual approval, check the status of the application:
+As we can see, in this update, we have also configured a canary-deploy workflow. This workflow includes 5 steps and splits the entire process into 3 stages.
+Here's an **overview about what will happen** of the three stages:
+
+1. In the first stage, the deployment will be updated with 20% of the total replicas. In our example, since we have a total of 5 replicas, 1 replica will be updated to the new version and serve 20% of the traffic. The upgrade process will then wait for a manual approval before moving on to the next stage.
+2. Once the first stage has been approved, the second stage will begin. During this stage, 50% of the total replicas will be updated to the new version. In our example, this means that 2.5 replicas will be updated, which is rounded up to 3. These 3 replicas will serve 50% of the traffic, and the upgrade process will once again wait for a manual approval before moving on to the final stage.
+3. In the final stage, all replicas will be updated to the new version and serve 100% of the traffic
+
+
+Check the status of the application:
 
 ```shell
 $ vela status canary-demo
@@ -158,30 +155,48 @@ About:
 
   Name:         canary-demo                  
   Namespace:    default                      
-  Created at:   2022-06-09 16:43:10 +0800 CST
-  Status:       runningWorkflow              
+  Created at:   2023-04-10 15:10:56 +0800 CST
+  Status:       workflowSuspending           
 
-...snip...
+Workflow:
+
+  mode: StepByStep-DAG
+  finished: false
+  Suspend: true
+  Terminated: false
+  Steps
+  - id: hqhtsm949f
+    name: rollout-20
+    type: canary-deploy
+    phase: succeeded 
+  - id: umzd2xain9
+    name: suspend-1st
+    type: suspend
+    phase: suspending 
+    message: Suspended by field suspend
 
 Services:
 
   - Name: canary-demo  
     Cluster: local  Namespace: default
     Type: webservice
-    Unhealthy Ready:5/5
+    Healthy Ready:5/5
+    Traits:
+      ✅ rolling-release: workload deployment is completed      ✅ scaler      ✅ gateway: Visiting URL: canary-demo.com, IP: 192.168.9.103
+  - 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 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.
+The application's status is currently set to workflowSuspending, which means that the first step has been completed and the workflow is now waiting for manual approval.
 
-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.
+View the topology graph again to confirm that a new v2 pod has been created to serve canary traffic. Meanwhile, the remaining 4 v1 pods are still running and serving non-canary traffic.
+![image](../../resources/kruise-rollout-v2-batch1.jpg)
 
-![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.
+Access the gateway endpoint again. You will find that there is approximately a 20% chance of seeing the Demo: v2 result.
 
 ```shell
 $ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
@@ -196,13 +211,17 @@ After verify the success of the canary version through business-related metrics,
 vela workflow resume canary-demo
 ```
 
-Access the gateway endpoint again multi times. You will find out the chance (`90%`) to meet result `Demo: v2` is highly increased.
+Access the gateway endpoint again multi times. You will find out the chance (`50%`) to meet result `Demo: v2` is highly increased.
 
 ```shell
 $ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
 Demo: V2
 ```
 
+View topology graph again, you will see the workload updated 3 replicas to `v2`, and this pod will serve the canary traffic. Meanwhile, 2 pods of `v1` are still running and server non-canary traffic.
+
+![image](../../resources/kruise-rollout-v2-batch2.jpg)
+
 ## Canary validation succeed, finished the release
 
 In the end, you can resume again to finish the rollout process.
@@ -222,21 +241,10 @@ Demo: V2
 
 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.
 ```
 
@@ -248,3 +256,82 @@ Demo: V1
 ```
 
 Any rollback operation in middle of a runningWorkflow will rollback to the latest succeeded revision of this application. So, if you deploy a successful `v1` and upgrade to `v2`, but this version didn't succeed while you continue to upgrade to `v3`. The rollback of `v3` will automatically to `v1`, because release `v2` is not a succeeded one.
+
+## Perform canary rollout process on VelaUX
+
+You can also execute a Canary Rollout process on VelaUX.
+
+### First deployment
+
+To begin, create an application with a `webservice` component and set its image to `wangyikewyk/canarydemo:v1`, as shown in the image below:
+
+![image](../../resources/kruise-rollout-velaux-v1-component.jpg)
+
+Next, add a `scaler` trait for this component and set the replica number to 3, as shown below:
+
+![image](../../resources/kruise-rollout-velaux-v1-scaler.jpg)
+
+Finally, configure a gateway for the component and set the hostname and traffic route, as illustrated in the image:
+
+![image](../../resources/kruise-rollout-velaux-v1-gateway.jpg)
+
+After clicking the deploy button, the application will be deployed, and you can check its status on the `resource topology` page, as shown below:
+
+![image](../../resources/kruise-rollout-velaux-v1.jpg)
+
+### Day-2 Canary Release
+
+To update the component, change the image to `wangyikewyk/canarydemo:v2`:
+
+![image](../../resources/kruise-rollout-velaux-v2-component.jpg)
+
+Next, click the `deploy` button then click `Enable Canary Rollout` button to create a new canary rollout workflow, as shown below:
+
+![image](../../resources/kruise-rollout-velaux-enable-canary.jpg)
+
+Set the batches to 3 to perform a Canary Rollout of the application with 3 batches:
+
+![image](../../resources/kruise-rollout-velaux-batches-num.jpg)
+
+You will see the new created workflow is as shown below, click the `save` button to save it.
+
+![image](../../resources/kruise-rollout-velaux-canary-workflow.jpg)
+
+The rollout process is divided into three steps, with each step releasing 1/3 replicas and traffic to the new version. A manual approval step is between two `canary-deploy` steps. You can also modify the weight of every Canary Rollout step.
+
+Click deploy again and choose the `Default Canary Workflow` to begin the rollout process as shown: 
+
+![image](../../resources/kruise-rollout-velaux-choose-wf.jpg)
+
+After the first step is complete, 1 replica will be updated to v2, as shown below:
+
+![image](../../resources/kruise-rollout-velaux-v2-batch1.jpg)
+
+You can try to access the gateway using the following command, and you will have a 1/3 chance of getting the `Demo: V1`.
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+```
+
+### Continue rollout
+
+To continue the rollout process, click the `continue` button on the workflow page:
+
+![image](../../resources/kruise-rollout-velaux-v2-continue.jpg)
+
+You will find that 2 replicas have been updated to the new version:
+
+![image](../../resources/kruise-rollout-velaux-v2-batch2.jpg)
+
+### Rollback
+
+To terminate the rolling process and rollback the application to version v1, click the `rollback` button:
+
+![image](../../resources/kruise-rollout-velaux-v2-rollback.jpg)
+
+You will find that all replicas have been rolled back to v1:
+
+![image](../../resources/kruise-rollout-velaux-v1.jpg)
+
+

i18n/zh/docusaurus-plugin-content-docs/current/end-user/traits/rollout.md

@@ -6,27 +6,15 @@ title: 金丝雀发布
 
 ## 准备工作
 
-1. 通过如下命令启用 [`kruise-rollout`](../../reference/addons/kruise-rollout) 插件，金丝雀发布依赖于 [rollouts from OpenKruise](https://github.com/openkruise/rollouts).
+通过如下命令启用 [`kruise-rollout`](../../reference/addons/kruise-rollout) 插件，金丝雀发布依赖于 [rollouts from OpenKruise](https://github.com/openkruise/rollouts).
    
-   ```shell
-   vela addon enable kruise-rollout
-   ```
-
-2. 请确保在集群中至少安装一种 [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/)。
-   如果没有你也可以通过如下命令启用 [`ingress-nginx`](../../reference/addons/nginx-ingress-controller) 安装一个：
-   
-   ```shell
-   vela addon enable ingress-nginx
-   ```
-   
-   参考 [the addon doc](../../reference/addons/nginx-ingress-controller) 获取网关的访问地址。
-
-3. 一些指令例如 `rollback` 依赖 vela-cli 版本 `>=1.5.0-alpha.1`，请升级cli到最新版本，不用升级Controller。
+```shell
+vela addon enable kruise-rollout
+```
 
 ## 首次部署
 
-当你希望在每次升级策略配置时都使用金丝雀发布，**必须**在你的组件中添加 `kruise-rollout` 特性。 
-在 day-2 金丝雀发布中组件必须已经存在此特性。部署应用：
+对应用进行首次发布：
 
 ```yaml
 cat <<EOF | vela up -f -
@@ -41,7 +29,7 @@ spec:
       - name: canary-demo
         type: webservice
         properties:
-      image: barnett/canarydemo:v1
+           image: wangyikewyk/canarydemo:v1
            ports:
               - port: 8090
         traits:
@@ -53,27 +41,10 @@ spec:
                 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: ingress
 EOF
 ```
 
-下面解释了在使用了 `kruise-rollout` 运维特征之后，下次升级应用时，是如何进行金丝雀发布的，整个发布过程会分成3步：
-
-1. 当升级到第一个批次时，会产生 `20%` 的实例数量。在我们的示例中， 我们一共设置了5个实例，它会保留所有的老的版本并创建 `5 * 20% = 1` 个金丝雀实例版本，并且导入了 `20%` 的流量。在所有都准备好后，它会等待手工批准。
-   - 实例数量和导入流量的百分比默认是一致的，你可以根据 [文档](../../reference/addons/kruise-rollout) 配置比例。
-2. 在手工批准后，会进入到第二个阶段，它会创建 `5 * 90% = 4.5` 实际上是 `5` 个实例的新版本，并且导入 `90%` 的流量。这样一来，目前系统一共有 `10` 个实例，它需要等待下一步的手工批准。
-3. 在批准后，它就会利用滚动更新的机制来更新实例，在实例完成升级后，所有的流量路由都指向新的版本的实例，金丝雀发布也会被销毁。
-
-继续示例，我们的首次部署过程和一般的部署并没有太大区别，你可以通过如下命令来检查应用的状态来确保可以进行下一步操作。
+我们的首次部署就是进行一个普通的发布，你可以通过如下命令来检查应用的状态来确保可以进行下一步操作：
 
 ```shell
 $ vela status canary-demo
@@ -81,10 +52,20 @@ About:
 
   Name:         canary-demo                  
   Namespace:    default                      
-  Created at:   2022-06-09 16:43:10 +0800 CST
+  Created at:   2023-04-10 14:27:58 +0800 CST
   Status:       running                      
 
-...snip...
+Workflow:
+
+  mode: DAG-DAG
+  finished: true
+  Suspend: false
+  Terminated: false
+  Steps
+  - id: c1cqamr5w6
+    name: canary-demo
+    type: apply-component
+    phase: succeeded 
 
 Services:
 
@@ -94,14 +75,13 @@ Services:
     Healthy Ready:5/5
     Traits:
       ✅ scaler      ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
-      ✅ kruise-rollout: rollout is healthy
 ```
 
-如果你已经启用了 [velaux](../../reference/addons/velaux) 插件，你可以通过拓扑图来观察到所有的 `v1` pods 都处于 ready状态。
+如果你已经启用了 [velaux](../../reference/addons/velaux) 插件，你可以通过拓扑图来观察到所有的 `v1`  都处于 ready 状态。
 
 ![image](../../resources/kruise-rollout-v1.jpg)
 
-用上面定义的路径和 Host 访问网关：
+如果你的集群中已经按转了一个 ingress controller （或者你也可以通过启用 [ingress-nginx](../../reference/addons/nginx-ingress-controller.md) 插件来为你的集群安装一个，你就可以通过下面的命令来访问你的应用的网关入口：
 
 ```shell
 $ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
@@ -127,7 +107,7 @@ spec:
       - name: canary-demo
         type: webservice
         properties:
-      image: barnett/canarydemo:v2
+           image: wangyikewyk/canarydemo:v2
            ports:
               - port: 8090
         traits:
@@ -139,19 +119,35 @@ spec:
                 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
+   workflow:
       steps:
-          - weight: 20
-          - weight: 90
-          trafficRoutings:
-          - type: ingress
+         - type: canary-deploy
+           name: rollout-20
+           properties:
+              weight: 20
+         - name: suspend-1st
+           type: suspend
+         - type: canary-deploy
+           name: rollout-50
+           properties:
+              weight: 50
+         - name: suspend-2nd
+           type: suspend
+         - type: canary-deploy
+           name: rollout-100
+           properties:
+              weight: 100
 EOF
 ```
 
-它会创建一个金丝雀发布并且等待手工批准，你可以检查应用的状态：
+请注意，在这次更新中，我们除了更新了组件的镜像配置，还为这次更新设置了一条金丝雀发布的工作流，这个工作流包含 5 个步骤，总共 3 个阶段。
+下面介绍了三个阶段应用升级的详细状态：
+
+1. 先进行第一批次的升级，更新 `20%` 的实例数量到 v2 版本。在我们的示例中， 我们一共设置了5个实例，所以这个阶段会升级 `5 * 20% = 1` 个实例版本到新版本，并且导入了 `20%` 的流量。在所实例就绪之后好后，工作流会进入暂停状态，等待手工批准。
+2. 在手工批准后，会进入到第二个阶段，它会升级 `5 * 50% = 2。5` 实际上是 `5` 个实例的新版本，并且导入 `50%` 的流量。接下来，工作流会再次进入暂停状态，等待下一步的手工批准。
+3. 在批准后，全部的实例都将会更新到新版本，并且所有的流量路由都指向新的版本的实例。
+
+更新后你可以检查应用的状态：
 
 ```shell
 $ vela status canary-demo
@@ -159,25 +155,45 @@ About:
 
   Name:         canary-demo                  
   Namespace:    default                      
-  Created at:   2022-06-09 16:43:10 +0800 CST
-  Status:       runningWorkflow              
+  Created at:   2023-04-10 15:10:56 +0800 CST
+  Status:       workflowSuspending           
 
-...snip...
+Workflow:
+
+  mode: StepByStep-DAG
+  finished: false
+  Suspend: true
+  Terminated: false
+  Steps
+  - id: hqhtsm949f
+    name: rollout-20
+    type: canary-deploy
+    phase: succeeded 
+  - id: umzd2xain9
+    name: suspend-1st
+    type: suspend
+    phase: suspending 
+    message: Suspended by field suspend
 
 Services:
 
   - Name: canary-demo  
     Cluster: local  Namespace: default
     Type: webservice
-    Unhealthy Ready:5/5
+    Healthy Ready:5/5
+    Traits:
+      ✅ rolling-release: workload deployment is completed      ✅ scaler      ✅ gateway: Visiting URL: canary-demo.com, IP: 192.168.9.103
+  - 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 in step(1/1), and you need manually confirm to enter the next step
 ```
 
-应用的状态是 `runningWorkflow` 这意味着发布还没有完成。
+应用的状态是 `workflowSuspending` 这意味着工作流进入到等待审批的阶段。
 
-再次查看拓扑图，你会看到 `kruise-rollout` 特性创建了一个 `v2` 实例，并且这个实例会导入流量。同时 `v1` 版本的实例还在运行中并且不会导入任何流量。
+再次查看拓扑图，你会看到 deployment 已经升级了两个实例到 `v2` 版本，并且这些实例会被导入 20% 的流量。同时 `v1` 版本的实例还在运行中并且倒入 80% 的流量。
 
 ![image](../../resources/kruise-rollout-v2.jpg)
 
@@ -196,7 +212,7 @@ Demo: V2
 vela workflow resume canary-demo
 ```
 
-在多次重新访问网关后，你会发现机率大幅提升，有 `90%` 的结果是 `Demo: v2`。
+在多次重新访问网关后，你会发现机率大幅提升，有 `50%` 的结果是 `Demo: v2`。
 
 ```shell
 $ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
@@ -220,31 +236,99 @@ Demo: V2
 
 ## 金丝雀验证失败，回滚
 
-如果经过验证发现新版本有问题，你想中断发布，将应用回滚至上一个版本。可以如下操作：
-
-你需要在回滚前中止工作流：
-
-```shell
-$ vela workflow suspend canary-demo
-Rollout default/canary-demo in cluster  suspended.
-Successfully suspend workflow: canary-demo
-```
-
-回滚：
+如果经过验证发现新版本有问题，你想中断发布，将应用回滚至上一个版本。可以如下操作快速将应用回滚：
 
 ```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.
 ```
 
-再次访问网关，你会看到结果一直是 `Demo: V1`。
+再次访问网关，你会看到结果一直是 `Demo: V1`:
 
 ```shell
 $ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
 Demo: V1
 ```
 
-需要注意的是，任何在应用处于 `runningWorkflow` 状态时的回滚操作，都会回滚到应用最后一次成功发布的版本，所以如果你已经成功部署了 `v1` 并且升级到 `v2`， 但是如果 `v2` 失败了但是你又继续更新到 `v3`。那么从 `v3` 回滚会自动到 `v1`，这是因为 `v2` 并不是成功发布的版本。
+需要注意的是，任何在应用处于发布中状态时的回滚操作，都会回滚到应用最后一次成功发布的版本，所以如果你已经成功部署了 `v1` 并且升级到 `v2`， 但是如果 `v2` 失败了但是你又继续更新到 `v3`。那么从 `v3` 回滚会自动到 `v1`，这是因为 `v2` 并不是成功发布的版本。
+
+## 使用 VelaUX 做金丝雀发布
+
+你也可以在 VelaUX 上对应用进行金丝雀方式的升级。
+
+### 首次部署
+
+首先在 VelaUX 界面上创建一个应用，其中包含了一个 `webservice` 类型的组件，并且将组件的镜像设置为 `wangyikewyk/canarydemo:v1` 如下图所示：
+
+![image](../../resources/kruise-rollout-velaux-v1-component.jpg)
+
+接下来为这个组件添加一个副本个数为 3 的 `scaler` 运维特征：
+
+![image](../../resources/kruise-rollout-velaux-v1-scaler.jpg)
+
+最后为组件添加一个 `gateway` 运维特征，并设置响应的路由规则，如下：
+
+![image](../../resources/kruise-rollout-velaux-v1-gateway.jpg)
+
+之后点击 `deploy` 按钮应用进行部署，之后你就可以在资源拓扑图页面中看到所有实例都已经被创建：
+
+![image](../../resources/kruise-rollout-velaux-v1.jpg)
+
+### 继续金丝雀发布
+
+更新组件将镜像设置为 `wangyikewyk/canarydemo:v2`：
+
+![image](../../resources/kruise-rollout-velaux-v2-component.jpg)
+
+点击 `deploy` 按钮，并点击 `Enable Canary Rollout` 创建金丝雀发布的工作流，如下所示：
+
+![image](../../resources/kruise-rollout-velaux-enable-canary.jpg)
+
+这里我们可以将批次设置为 3，从而对应用分三个批次进行升级：
+
+![image](../../resources/kruise-rollout-velaux-batches-num.jpg)
+
+接下来可以看到新新创建的了一条金丝雀发布的工作流，点击 `save` 按钮对工作流进行保存，如下所示：
+
+![image](../../resources/kruise-rollout-velaux-canary-workflow.jpg)
+
+工作流包含三个 `canary-deploy`的步骤，说明整个发布过程被分为了三批进行发布，每个批次有升级 1/3 的实例到新版本，并且将 1/3 的流量导入到新版本。两个 `canary-deploy` 步骤间有一个人工确认的步骤。你也可以编辑 `canary-deploy` 的步骤来修改每个批次的发布比例。
+
+再次点击 `Deploy` 按钮发布，并选择刚才创建的 `Default Canary Workflow` 工作流开始发布，如下所示：
+
+![image](../../resources/kruise-rollout-velaux-choose-wf.jpg)
+
+当第一步完成之后，可以看到有 1 个实例被升级到了新版本，如下所示：
+
+![image](../../resources/kruise-rollout-velaux-v2-batch1.jpg)
+
+你可以通过下面的命令访问应用网关，你将会发现大约有 1/3 的概率看到 `Demo: V1` 的结果：
+
+```shell
+$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
+Demo: V1
+```
+
+### 继续发布
+
+在工作流页面，点击 `continue` 按钮继续下面后面的发布步骤：
+
+![image](../../resources/kruise-rollout-velaux-v2-continue.jpg)
+
+之后你将会看到又有 2 个实例升级到新版本：
+
+![image](../../resources/kruise-rollout-velaux-v2-batch2.jpg)
+
+### 回滚
+
+如果你想终止当前的发布工作流，并将应用的实例和流量回滚到发布钱的状态，可以在工作流的页面点击 `rollback` 按钮来进行这个操作：
+
+![image](../../resources/kruise-rollout-velaux-v2-rollback.jpg)
+
+接下来你将会发现所有的实例都回滚到了 v1版本：
+
+![image](../../resources/kruise-rollout-velaux-v1.jpg)
+
+