Fix: add notes and arch (#589)

Signed-off-by: Yin Da <yd219913@alibaba-inc.com>

docs/case-studies/multi-cluster.md

@@ -175,6 +175,14 @@ Handling connection for 8080
 ## Advanced Usage
 
 
+### Understanding the Multi-cluster Application
+
+The following figure displays the architecture of a multi-cluster application. All the configurations (including Application, Policy and Workflow) lives in the hub cluster. Only the resources (like deployment or service) will be dispatched in to managed clusters.
+
+The policies mainly takes charge of describing the destination of the resources and how they should be overrided. The real executor of the resource dispatch is the workflow. In each `deploy` workflow step, it will refer to some policies, override the default configuration, and dispatch the resources.
+
+![multi-cluster-arch](../resources/multi-cluster-arch.jpg)
+
 ### Configure the deploy destination
 
 The most straightforward way to configure the deploy destination is to write cluster names inside the `topology` policy. Sometimes, it will be more easy to select clusters by labels, like filtering all clusters in hangzhou:
@@ -361,6 +369,8 @@ spec:
           policies: ["topology-hangzhou-clusters", "override-nginx-legacy-image", "override-high-availability"]
 ```
 
+> NOTE: The override policy is used to modify the basic configuration. Therefore, **it is designed to be used together with topology policy**. If you do not want to use topology policy, you can directly write configurations in the component part instead of using the override policy. *If you misuse the override policy in the deploy workflow step without topology policy, no error will be reported but you will find nothing is deployed.*
+
 The override policy has many advanced capabilities, such as adding new component or selecting components to use.
 The following example will first deploy an nginx webservice with `nginx:1.20` image to local cluster. Then two nginx webservices with `nginx` and `nginx:stable` images will be deployed to hangzhou clusters respectively.
 

i18n/zh/docusaurus-plugin-content-docs/current/case-studies/multi-cluster.md

@@ -175,6 +175,16 @@ Handling connection for 8080
 ## 进阶使用
 
 
+### 理解多集群应用
+
+下图为多集群应用的整体结构图。如图所示，所有的配置信息（包括应用、策略和工作流）都处于管控集群中。只有资源（如 deployment 或者 service）会被下发到子集群之中。
+
+策略主要负责描述资源的位置以及它们应该如何被差异化配置。资源下发真正的执行者是工作流。在工作流中，`deploy` 步骤会根据引用的策略对资源进行差异化配置，然后再将它们分发到对应的集群中。
+
+![multi-cluster-arch](../../../../../docs/resources/multi-cluster-arch.jpg)
+
+
+
 ### 配置部署目标
 
 选择部署目标的最直接的方法就是在 `topology` 策略中声明你想要部署的集群名称。有的时候，使用标签来筛选要部署的集群会更方便，比如下面这个例子通过标签筛选出所有的杭州集群：
@@ -360,6 +370,8 @@ spec:
           policies: ["topology-hangzhou-clusters", "override-nginx-legacy-image", "override-high-availability"]
 ```
 
+> 注意：override 策略是用来修改基础配置的策略，因此**它被设计成必须需要和 topology 策略一同使用**。如果你不想要使用 topology 策略，你可以直接将配置写在组件声明中，而不是使用 override 策略。*如果你错误的在 deploy 工作流步骤中使用了 override 策略，而没有使用 topology 策略，应用不会发生错误，但是也不会下发任何资源。*
+
 差异化配置有一些高级配置能力，比如添加额外的组件，或者选择部分组件。下面的样例中，应用会首先在 `local` 集群中部署一个镜像为 `nginx:1.20` 的 webservice，然后再将 `nginx` 和 `nginx:stable` 两个 webservice 部署到杭州集群中
 
 ```yaml

i18n/zh/docusaurus-plugin-content-docs/version-v1.3/case-studies/multi-cluster.md

@@ -175,6 +175,16 @@ Handling connection for 8080
 ## 进阶使用
 
 
+### 理解多集群应用
+
+下图为多集群应用的整体结构图。如图所示，所有的配置信息（包括应用、策略和工作流）都处于管控集群中。只有资源（如 deployment 或者 service）会被下发到子集群之中。
+
+策略主要负责描述资源的位置以及它们应该如何被差异化配置。资源下发真正的执行者是工作流。在工作流中，`deploy` 步骤会根据引用的策略对资源进行差异化配置，然后再将它们分发到对应的集群中。
+
+![multi-cluster-arch](../../../../../docs/resources/multi-cluster-arch.jpg)
+
+
+
 ### 配置部署目标
 
 选择部署目标的最直接的方法就是在 `topology` 策略中声明你想要部署的集群名称。有的时候，使用标签来筛选要部署的集群会更方便，比如下面这个例子通过标签筛选出所有的杭州集群：
@@ -360,6 +370,8 @@ spec:
           policies: ["topology-hangzhou-clusters", "override-nginx-legacy-image", "override-high-availability"]
 ```
 
+> 注意：override 策略是用来修改基础配置的策略，因此**它被设计成必须需要和 topology 策略一同使用**。如果你不想要使用 topology 策略，你可以直接将配置写在组件声明中，而不是使用 override 策略。*如果你错误的在 deploy 工作流步骤中使用了 override 策略，而没有使用 topology 策略，应用不会发生错误，但是也不会下发任何资源。*
+
 差异化配置有一些高级配置能力，比如添加额外的组件，或者选择部分组件。下面的样例中，应用会首先在 `local` 集群中部署一个镜像为 `nginx:1.20` 的 webservice，然后再将 `nginx` 和 `nginx:stable` 两个 webservice 部署到杭州集群中
 
 ```yaml

i18n/zh/docusaurus-plugin-content-docs/version-v1.3/end-user/traits/references.md

@@ -12,7 +12,7 @@ The `gateway` trait exposes a component to public Internet via a valid domain.
 
 * 所有组件类型
 
-## 字段说明
+### 参数说明
 
 | NAME        | DESCRIPTION                                                                                        | TYPE           | REQUIRED | DEFAULT |
 | ----------- | -------------------------------------------------------------------------------------------------- | -------------- | -------- | ------- |
@@ -105,7 +105,7 @@ spec:
 * worker
 * task
 
-## Parameters
+### 参数说明
 
 ```
 $ vela show scaler
@@ -148,7 +148,7 @@ spec:
 * 所有基于 `deployments.apps` 类型的组件
 
 
-### 字段说明
+### 参数说明
 
 
 ```
@@ -198,7 +198,7 @@ spec:
 
 * 所有基于 `deployments.apps` 类型的组件
 
-### Parameters
+### 参数说明
 
 ```
 $ vela show storage
@@ -266,7 +266,7 @@ $ vela show storage
 
 ```
 
-## Examples
+### 样例
 
 ```yaml
 # sample.yaml
@@ -327,7 +327,7 @@ spec:
 
 * 所有组件类型
 
-### Parameters
+### 参数说明
 
 ```shell
 $ vela show labels
@@ -373,7 +373,7 @@ spec:
 
 * 所有组件类型
 
-### Parameters
+### 参数说明
 
 ```shell
 $ vela show annotations
@@ -418,7 +418,7 @@ spec:
 
 * kustomize
 
-### Parameters
+### 参数说明
 
 ```shell
 vela show kustomize-patch
@@ -493,7 +493,7 @@ In this example, the `kustomize-patch` will patch the content for all Pods with
 
 * kustomize
 
-### Parameters
+### 参数说明
 
 ```shell
 vela show kustomize-json-patch
@@ -575,7 +575,7 @@ spec:
 
 * kustomize
 
-### Parameters
+### 参数说明
 
 ```shell
 vela show kustomize-json-patch
@@ -635,7 +635,7 @@ Service binding trait will bind data from Kubernetes `Secret` to the application
 * cron-task
 
 
-### Parameters
+### 参数说明
 
 Name | Description | Type | Required | Default
 ------------ | ------------- | ------------- | ------------- | -------------
@@ -684,7 +684,7 @@ The `sidecar` trait allows you to attach a sidecar container to the component.
 * task
 * cron-task
 
-### Parameters
+### 参数说明
 
 ```console
 # Properties

versioned_docs/version-v1.3/case-studies/multi-cluster.md

@@ -175,6 +175,14 @@ Handling connection for 8080
 ## Advanced Usage
 
 
+### Understanding the Multi-cluster Application
+
+The following figure displays the architecture of a multi-cluster application. All the configurations (including Application, Policy and Workflow) lives in the hub cluster. Only the resources (like deployment or service) will be dispatched in to managed clusters.
+
+The policies mainly takes charge of describing the destination of the resources and how they should be overrided. The real executor of the resource dispatch is the workflow. In each `deploy` workflow step, it will refer to some policies, override the default configuration, and dispatch the resources.
+
+![multi-cluster-arch](../resources/multi-cluster-arch.jpg)
+
 ### Configure the deploy destination
 
 The most straightforward way to configure the deploy destination is to write cluster names inside the `topology` policy. Sometimes, it will be more easy to select clusters by labels, like filtering all clusters in hangzhou:
@@ -361,6 +369,8 @@ spec:
           policies: ["topology-hangzhou-clusters", "override-nginx-legacy-image", "override-high-availability"]
 ```
 
+> NOTE: The override policy is used to modify the basic configuration. Therefore, **it is designed to be used together with topology policy**. If you do not want to use topology policy, you can directly write configurations in the component part instead of using the override policy. *If you misuse the override policy in the deploy workflow step without topology policy, no error will be reported but you will find nothing is deployed.*
+
 The override policy has many advanced capabilities, such as adding new component or selecting components to use.
 The following example will first deploy an nginx webservice with `nginx:1.20` image to local cluster. Then two nginx webservices with `nginx` and `nginx:stable` images will be deployed to hangzhou clusters respectively.
 

versioned_docs/version-v1.3/end-user/traits/references.md

@@ -104,7 +104,7 @@ The `scaler` trait allows you to change the replicas for the component.
 * worker
 * task
 
-## Parameters
+### Parameters
 
 ```
 $ vela show scaler
@@ -257,7 +257,7 @@ $ vela show storage
 
 ```
 
-## Examples
+### Examples
 
 ```yaml
 # sample.yaml

versioned_sidebars/version-v1.3-sidebars.json

@@ -564,4 +564,4 @@
       "id": "version-v1.3/developers/references/devex/faq"
     }
   ]
-}
+}