Fix: add notes and arch (#589)
Signed-off-by: Yin Da <yd219913@alibaba-inc.com>
This commit is contained in:
Somefive
GitHub
parent
bdfc9757d1
commit
874e4cb8fb
|
|
@ -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.
|
||||
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 171 KiB |
|
|
@ -175,6 +175,16 @@ Handling connection for 8080
|
|||
## 进阶使用
|
||||
|
||||
|
||||
### 理解多集群应用
|
||||
|
||||
下图为多集群应用的整体结构图。如图所示，所有的配置信息（包括应用、策略和工作流）都处于管控集群中。只有资源（如 deployment 或者 service）会被下发到子集群之中。
|
||||
|
||||
策略主要负责描述资源的位置以及它们应该如何被差异化配置。资源下发真正的执行者是工作流。在工作流中，`deploy` 步骤会根据引用的策略对资源进行差异化配置，然后再将它们分发到对应的集群中。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 配置部署目标
|
||||
|
||||
选择部署目标的最直接的方法就是在 `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
|
||||
|
|
|
|||
|
|
@ -175,6 +175,16 @@ Handling connection for 8080
|
|||
## 进阶使用
|
||||
|
||||
|
||||
### 理解多集群应用
|
||||
|
||||
下图为多集群应用的整体结构图。如图所示，所有的配置信息（包括应用、策略和工作流）都处于管控集群中。只有资源（如 deployment 或者 service）会被下发到子集群之中。
|
||||
|
||||
策略主要负责描述资源的位置以及它们应该如何被差异化配置。资源下发真正的执行者是工作流。在工作流中，`deploy` 步骤会根据引用的策略对资源进行差异化配置，然后再将它们分发到对应的集群中。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### 配置部署目标
|
||||
|
||||
选择部署目标的最直接的方法就是在 `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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 171 KiB |
|
|
@ -564,4 +564,4 @@
|
|||
"id": "version-v1.3/developers/references/devex/faq"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
|
|
|
|||
Loading…
Reference in New Issue