refine i18n of zh (#742)
Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>
This commit is contained in:
Jianbo Sun
GitHub
parent
86c202e28b
commit
c7d6b103bd
|
|
@ -162,5 +162,7 @@ If you're a system infra or operator, you can refer to extension documents to le
|
|||
|
||||
If you're extremely interested in KubeVela, you can also extend more features as a developer.
|
||||
|
||||
- Read the [developer guide](../../contributor/overview) to learn how to contribute and extend capabilities for KubeVela.
|
||||
- KubeVela use CUE as it's core engine, [learn CUE in KubeVela](../../platform-engineers/cue/basic) and try to extend with CUE configurations.
|
||||
- Read the [developer guide](../../contributor/overview) to learn how to contribute and extend capabilities for KubeVela.
|
||||
|
||||
Welcome to join the KubeVela community! We're eager to see you to contribute your extension.
|
||||
|
|
|
|||
|
|
@ -6,17 +6,17 @@ Definition are the basic building block of the KubeVela platform. A definition e
|
|||
|
||||
There're four types of Definition, they're `ComponentDefinition`, `TraitDefinition`, `PolicyDefinition` and `WorkflowStepDefinition`, corresponding to the application concepts.
|
||||
|
||||
## Sources of Definitions
|
||||
## How to get out-of-box Definitions?
|
||||
|
||||
There're two sources of definitions:
|
||||
There're two sources to get out-of-box definitions:
|
||||
|
||||
* Built-in definitions will be installed along with KubeVela helm chart. You can refer to the following links to learn more about built-in definitions.
|
||||
- [Component Definition](../end-user/components/references)
|
||||
- [Trait Definition](../end-user/traits/references)
|
||||
- [Policy Definition](../end-user/policies/references)
|
||||
- [Workflow Step Definition](../end-user/workflow/built-in-workflow-defs)
|
||||
* Installation of addons will install definitions if there're new capabilities contained.
|
||||
- [Addon registry](../reference/addons/overview) contains a large catalog of addon which are maintained and verified by the KubeVela team.
|
||||
* [Addons](../reference/addons/overview), as extension of KubeVela, each addon contains a bunch of definitions along its CRD controllers.
|
||||
- The community has a [verified addon registry](https://github.com/kubevela/catalog) which contains a large catalog of addons, the registry is maintained by the KubeVela team.
|
||||
|
||||
## Lifecycle of a Definition
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ You can also view the details with a browser, the following command will launch
|
|||
vela show webservice --web
|
||||
```
|
||||
|
||||
* Discover in UI console
|
||||
* Discover in UI console ( addon `velaux` installed)
|
||||
|
||||
|
||||
|
||||
|
|
@ -76,6 +76,10 @@ If you're a fan of our UI console, the usage of definition is very straight forw
|
|||
|
||||
|
||||
|
||||
1. Create Application and choose Component type which is actually choosing which component definition to use.
|
||||
2. Fill the properties of component is actually fill the parameter of component definition.
|
||||
3. The same step for trait, policy and workflow.
|
||||
|
||||
Finally, the UI console will compose the whole deployment plan in the format of OAM like below, then KubeVela controller will take care of the rest things:
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -55,6 +55,3 @@ After the configuration is complete, click `Submit` to save the step configurati
|
|||
|
||||
After the workflow is configured, please click the Save button at the top right of the workflow window to save all changes. After saving, you can click the `Deploy` on the top right of the page or the select button on the right to choose to execute the workflow and verify whether you can receive a message notification.
|
||||
|
||||
## Next Steps
|
||||
|
||||
- [Deploy the application to the environment](../how-to/dashboard/application/deploy-application)
|
||||
|
|
@ -156,7 +156,7 @@
|
|||
"description": "The skip to content label used for accessibility, allowing to rapidly navigate to main content with keyboard tab/enter navigation"
|
||||
},
|
||||
"Make shipping applications more enjoyable.": {
|
||||
"message": "让应用交付更愉快！"
|
||||
"message": "让应用部署和管理更轻松！"
|
||||
},
|
||||
"KubeVela models platform features (such as workloads, operational behaviors, and cloud services) as reusable": {
|
||||
"message": "KubeVela 将平台功能（如工作负载、运维操作行为和云服务）抽象建模为可重用的"
|
||||
|
|
|
|||
|
|
@ -2,13 +2,159 @@
|
|||
title: 获得更多？
|
||||
---
|
||||
|
||||
* 查看 [组件参考列表](./references)文档，了解所有内置支持的交付制品。
|
||||
KubeVela 是可编程的，你可以通过自定义模块轻松地扩展它，主流的方式是通过以下的途径发现、安装新的扩展能力：
|
||||
|
||||
* 通过[安装插件](../../how-to/cli/addon/addon)集成更多交付制品。
|
||||
## 了解内置的模块能力
|
||||
|
||||
* 自己动手扩展
|
||||
KubeVela 安装时就自带了很多开箱即用的功能，可以查看如下手册了解详情：
|
||||
|
||||
* 阅读[如何通过已经存在的 Definition 修改从而自定义组件类型](../../platform-engineers/cue/definition-edit)。
|
||||
* [构建自己的能力](../../platform-engineers/cue/advanced)
|
||||
学习[从零开始构建组件](../../platform-engineers/components/custom-component)。
|
||||
* [构建自己的插件](../../platform-engineers/addon/intro)。
|
||||
- [内置组件](./references)
|
||||
- [内置运维特征](../traits/references)
|
||||
- [内置策略](../policies/references)
|
||||
- [内置工作流步骤](../workflow/built-in-workflow-defs)
|
||||
|
||||
## 管理插件
|
||||
|
||||
你可以通过安装 KubeVela 的插件（Addon）获取更多的扩展能力。
|
||||
|
||||
### 查看所有插件
|
||||
|
||||
KubeVela 官方团队维护了一个默认的插件仓库 (https://addons.kubevela.net) ，默认情况下会从这个仓库实时发现。
|
||||
|
||||
|
||||
```shell
|
||||
$ vela addon list
|
||||
NAME REGISTRY DESCRIPTION AVAILABLE-VERSIONS STATUS
|
||||
ocm-gateway-manager-addon KubeVela ocm-gateway-manager-addon is the OCM addon automates the cluster-gateway apiserver. [1.3.2, 1.3.0, 1.1.11] disabled
|
||||
rollout KubeVela Provides basic batch publishing capability. [1.3.0, 1.2.4, 1.2.3] disabled
|
||||
terraform-baidu KubeVela Kubernetes Terraform Controller Provider for Baidu Cloud [1.0.1, 1.0.0] disabled
|
||||
terraform-tencent KubeVela Kubernetes Terraform Controller Provider for Tencent Cloud [1.0.1, 1.0.0] disabled
|
||||
model-serving KubeVela Enable serving for models [1.0.0] disabled
|
||||
model-training KubeVela Enable training for models [1.0.0] disabled
|
||||
terraform KubeVela Terraform Controller is a Kubernetes Controller for Terraform. [1.0.6] disabled
|
||||
terraform-aws KubeVela Kubernetes Terraform Controller for AWS [1.0.1, 1.0.0] disabled
|
||||
terraform-azure KubeVela Kubernetes Terraform Controller for Azure [1.0.1, 1.0.0] disabled
|
||||
terraform-gcp KubeVela Kubernetes Terraform Controller Provider for Google Cloud Platform [1.0.1, 1.0.0] disabled
|
||||
dex KubeVela Enable dex for login [0.6.5] disabled
|
||||
ocm-hub-control-plane KubeVela ocm-hub-control-plane can install OCM hub control plane to the central cluster. [0.6.0] disabled
|
||||
terraform-ucloud KubeVela Kubernetes Terraform Controller Provider for UCloud [1.0.1, 1.0.0] disabled
|
||||
fluxcd KubeVela Extended workload to do continuous and progressive delivery [1.1.0, 1.0.0] disabled
|
||||
velaux KubeVela KubeVela User Experience (UX). An extensible, application-oriented delivery and management Dashboard. [v1.3.0, v1.3.0-beta.2, 1.2.4] enabled (v1.3.0)
|
||||
terraform-alibaba KubeVela Kubernetes Terraform Controller for Alibaba Cloud [1.0.2, 1.0.1] disabled
|
||||
```
|
||||
|
||||
### 安装插件
|
||||
|
||||
```
|
||||
$ vela addon enable fluxcd
|
||||
I0111 21:45:24.553174 89345 apply.go:106] "creating object" name="addon-fluxcd" resource="core.oam.dev/v1beta1, Kind=Application"
|
||||
I0111 21:45:25.258914 89345 apply.go:106] "creating object" name="helm" resource="core.oam.dev/v1beta1, Kind=ComponentDefinition"
|
||||
I0111 21:45:25.342731 89345 apply.go:106] "creating object" name="kustomize-json-patch" resource="core.oam.dev/v1beta1, Kind=TraitDefinition"
|
||||
I0111 21:45:25.382201 89345 apply.go:106] "creating object" name="kustomize-patch" resource="core.oam.dev/v1beta1, Kind=TraitDefinition"
|
||||
I0111 21:45:25.411723 89345 apply.go:106] "creating object" name="kustomize" resource="core.oam.dev/v1beta1, Kind=ComponentDefinition"
|
||||
I0111 21:45:25.625815 89345 apply.go:106] "creating object" name="kustomize-strategy-merge" resource="core.oam.dev/v1beta1, Kind=TraitDefinition"
|
||||
I0111 21:45:25.660129 89345 apply.go:106] "creating object" name="component-uischema-helm" resource="/v1, Kind=ConfigMap"
|
||||
Addon: fluxcd enabled Successfully.
|
||||
```
|
||||
|
||||
#### 安装特定版本的插件
|
||||
|
||||
你可以通过通过设置 `--version` 启动参数，来指定安装插件的某个特定版本。例如：
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd --version=1.0.0
|
||||
```
|
||||
|
||||
如果不指定该参数，默认会安装此插件的最新版本。
|
||||
|
||||
启用一个插件时，默认会在所有子集群中安装该插件，你也可以通过设置 `--cluster` 启动参数选择安装在某些集群当中。例如：
|
||||
|
||||
```shell
|
||||
vela addon enable <addon-name> --clusters={cluster1,cluster2}
|
||||
```
|
||||
|
||||
安装完成后，插件中的功能会以组件，运维特征，工作流步骤等形式呈现，你可以通过 `vela component`，`vela trait` 等命令查看新增的能力，也可以在[插件的参考文档](../../reference/addons/overview)中查看每个官方插件对应的能力.
|
||||
|
||||
### 删除/卸载已安装的插件
|
||||
|
||||
> 删除前请确认插件对应的能力没有被任何应用使用。
|
||||
|
||||
```
|
||||
$ vela addon disable fluxcd
|
||||
Successfully disable addon:fluxcd
|
||||
```
|
||||
|
||||
### 查看插件的下载仓库
|
||||
|
||||
```
|
||||
$ vela addon registry list
|
||||
Name Type URL
|
||||
KubeVela helm https://addons.kubevela.net
|
||||
```
|
||||
|
||||
KubeVela 社区在 Github 上维护了一个官方的[正式插件包仓库](https://github.com/kubevela/catalog/tree/master/addons) 和一个[试验阶段插件包仓库](https://github.com/kubevela/catalog/tree/master/experimental) 。你在相应的仓库中找到插件包的定义文件。
|
||||
|
||||
同时这些文件会被同步到 [对象存储](https://addons.kubevela.net) 当中，以加快下载速度。
|
||||
|
||||
### 添加插件包仓库
|
||||
|
||||
你可以添加自己的插件包仓库，目前支持 OSS 和 Github 两种仓库类型。
|
||||
|
||||
```
|
||||
$ vela addon registry add experimental --type OSS --endpoint=https://addons.kubevela.net --path=experimental/
|
||||
Successfully add an addon registry experimental
|
||||
```
|
||||
|
||||
### 删除一个插件包仓库
|
||||
|
||||
```
|
||||
$ vela addon registry delete experimental
|
||||
Successfully delete an addon registry experimental
|
||||
```
|
||||
|
||||
### 多集群环境中启用插件包
|
||||
|
||||
如果你的环境中添加了若干个子集群，启用插件包时会默认在管控集群和所有子集群中安装此插件包。但如果子集群在某个插件包启用之后加入环境当中，则需要通过升级操作在新加入集群中安装此插件包。如下所示
|
||||
|
||||
```
|
||||
$ vela addon upgrade velaux
|
||||
Addon:
|
||||
enabled Successfully
|
||||
```
|
||||
|
||||
### 离线安装插件包
|
||||
|
||||
如果因为某些原因，你的环境无法通过访问插件包仓库，你可以通过指定本地的插件包目录来进行离线安装。如下所示：
|
||||
|
||||
```
|
||||
$ ls
|
||||
README.md fluxcd ocm-cluster-manager terraform terraform-alibaba terraform-aws terraform-azure velaux
|
||||
|
||||
$ vela addon enable velaux/
|
||||
Addon: velaux enabled Successfully
|
||||
```
|
||||
|
||||
需要注意的是，在安装插件过程当中，仍可能需要从网络中拉取镜像或者 helm chart，如果你的网络环境同样无法访问这些地址，请参考[文档](../../platform-engineers/system-operation/enable-addon-offline)进行完整的离线安装。
|
||||
|
||||
### 通过 UI 管理插件
|
||||
|
||||
具有插件管理权限的用户可以进入插件管理页面，进行插件启用/停用等操作。
|
||||
|
||||
|
||||
|
||||
如上图所示，在插件列表中，你可以查看到插件启用状态和其他基础信息。点击插件名称可以进入到插件详情页面，你可以查询到插件的版本列表，提供的扩展类型和介绍信息。
|
||||
|
||||
|
||||
|
||||
选择一个部署版本（默认为最新），设置需要部署的集群后，你可以点击 启用 按钮安装该插件。对于已启用的插件，如果没有应用使用该插件提供的扩展，你可以点击禁用按钮来卸载它。
|
||||
|
||||
### 编写自己的插件包
|
||||
|
||||
请参考[插件包制作文档](../../platform-engineers/addon/intro)。
|
||||
|
||||
## 作为开发者自定义和扩展
|
||||
|
||||
如果你对 KubeVela 扩展很感兴趣，你也可以了解 [CUE 体系](../../platform-engineers/cue/basic)开始自定义扩展能力，KubeVela 具备非常灵活的扩展能力。
|
||||
|
||||
非常欢迎广大开发者们阅读[开发者手册](../../contributor/overview)，了解更多的 KubeVela 细节，参与到社区的贡献中来。
|
||||
|
||||
|
|
@ -1,5 +1,384 @@
|
|||
---
|
||||
title: 分发引用的外部 Kubernetes 对象
|
||||
title: 多集群部署
|
||||
---
|
||||
|
||||
该文档已被迁移至[Kubernetes 交付制品]](../../tutorials/k8s-object#distributed-external-kubernetes-objects).
|
||||
> 开始这部分之前需要你先了解使用如何进行多集群应用的部署。你可以参考 [多集群应用交付](../../case-studies/multi-cluster) 章节了解相关基础细节.
|
||||
|
||||
你可以使用 KubeVela 引用已有的 Kubernetes 对象并将它们分发到其他位置来完成以下场景：
|
||||
|
||||
- 将管控集群中的密钥复制到子集群中。
|
||||
- 将验证集群中的工作负载部署到生产集群中。
|
||||
- 使用 Kubernetes 原生的 apiserver 作为控制面，将所有的 Kubernetes 对象存储在外部数据库中。然后通过引用这些资源，将它们下发到真正运行负载的子集群中。
|
||||
|
||||
## 在组件中引用已有的 Kubernetes 对象
|
||||
|
||||
为了在组件中使用已有的 Kubernetes 对象，你需要使用 `ref-objects` 类型的组件，并在参数中声明你想要引用的资源。例如，在下面的例子中，命名空间 `examples` 中的密钥 `image-credential-to-copy` 会被作为组件的源数据，然后你可以使用 Topology 策略来将它复制分发到杭州集群中。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ref-objects-example
|
||||
namespace: examples
|
||||
spec:
|
||||
components:
|
||||
- name: image-pull-secrets
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- resource: secret
|
||||
name: image-credential-to-copy
|
||||
policies:
|
||||
- name: topology-hangzhou-clusters
|
||||
type: topology
|
||||
properties:
|
||||
clusterLabelSelector:
|
||||
region: hangzhou
|
||||
```
|
||||
|
||||
## *ref-objects* 类型组件的细节
|
||||
|
||||
声明需要引用资源最直接的方法是使用 `resource: secret` 或 `resource: deployment` 这样的方式来确定引用资源的类型。如果 `name` 和 `labelSelector` 都没有被设置，那么应用将会在它的命名空间下尝试寻找与和组件名称一致的资源。你也可以显式地指定 `name` 和 `namespace` 来确定需要引用的资源。
|
||||
|
||||
除了 `name` 和 `namespace`，你还可以使用 `cluster` 字段让应用组件去引用子集群中的资源。你也可以使用 `labelSelector` 来筛选资源，而不是直接用 `name` 去确定目标资源。
|
||||
|
||||
在下面的样例中，应用会选择在 *hangzhou-1* 集群的 *examples* 命名空间中，所有符合声明标签要求的 Deployment。然后应用会将这些 Deployments 复制到 *hangzhou-2* 集群中。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ref-objects-duplicate-deployments
|
||||
namespace: examples
|
||||
spec:
|
||||
components:
|
||||
- name: duplicate-deployment
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- resource: deployment
|
||||
cluster: hangzhou-1
|
||||
# select all deployment in the `examples` namespace in cluster `hangzhou-1` that matches the labelSelector
|
||||
labelSelector:
|
||||
need-duplicate: "true"
|
||||
policies:
|
||||
- name: topology-hangzhou-2
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["hangzhou-2"]
|
||||
```
|
||||
|
||||
> 在一些场景下，你可能想要限制应用能够引用资源的范围，你可以通过在 KubeVela 控制器中设置 `--ref-objects-available-scope` 为 `namespace` 或者 `cluster` 来限制只在同命名空间或者同一集群内引用资源。
|
||||
|
||||
## 在 ref-objects 类型组件内使用运维特征
|
||||
|
||||
*ref-objects* 类型的组件同样也可以使用运维特征。其主体工作负载会被隐式地设置为引用资源列表中的第一个资源。所有作用在工作负载上的运维特征都会指向该资源。 如下所示的例子展示了如何为引用的 Deployment 设置副本数，并下发到 hangzhou 集群中。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ref-objects-multiple-resources
|
||||
namespace: examples
|
||||
spec:
|
||||
components:
|
||||
- name: nginx-ref-multiple-resources
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- resource: deployment
|
||||
- resource: service
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 3
|
||||
policies:
|
||||
- name: topology-hangzhou-clusters
|
||||
type: topology
|
||||
properties:
|
||||
clusterLabelSelector:
|
||||
region: hangzhou
|
||||
```
|
||||
|
||||
到此你已经完成了交付 Kubernetes 原生资源的学习！
|
||||
|
||||
## Working with Trait
|
||||
|
||||
The *ref-objects* typed component can also be used together with traits. The implicit main workload is the first referenced object and trait patch will be applied on it. The following example demonstrate how to set the replica number for the referenced deployment while deploying it in hangzhou clusters.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ref-objects-multiple-resources
|
||||
namespace: examples
|
||||
spec:
|
||||
components:
|
||||
- name: nginx-ref-multiple-resources
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- resource: deployment
|
||||
- resource: service
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 3
|
||||
policies:
|
||||
- name: topology-hangzhou-clusters
|
||||
type: topology
|
||||
properties:
|
||||
clusterLabelSelector:
|
||||
region: hangzhou
|
||||
```
|
||||
|
||||
There are several commonly used trait that could be used together with the ref-objects, particularly for Deployment.
|
||||
|
||||
### Container Image
|
||||
|
||||
The `container-image` trait can be used to change the default image settings declared in the original deployment.
|
||||
|
||||
By default, the `container-image` will replace the original image in the main container (the container uses the name of the component).
|
||||
```yaml
|
||||
traits:
|
||||
- type: container-image
|
||||
properties:
|
||||
image: busybox-1.34.0
|
||||
```
|
||||
|
||||
You can modify other containers by setting the `containerName` field.
|
||||
```yaml
|
||||
traits:
|
||||
- type: container-image
|
||||
properties:
|
||||
image: busybox-1.34.0
|
||||
containerName: sidecar-nginx
|
||||
```
|
||||
|
||||
You can also modify the ImagePullPolicy as well.
|
||||
```yaml
|
||||
traits:
|
||||
- type: container-image
|
||||
properties:
|
||||
image: busybox-1.34.0
|
||||
containerName: sidecar-nginx
|
||||
imagePullPolicy: IfNotPresent
|
||||
```
|
||||
|
||||
Multiple container patch is also available.
|
||||
```yaml
|
||||
traits:
|
||||
- type: container-image
|
||||
properties:
|
||||
containers:
|
||||
- containerName: busybox
|
||||
image: busybox-1.34.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
- containerName: sidecar-nginx
|
||||
image: nginx-1.20
|
||||
```
|
||||
|
||||
### Command
|
||||
|
||||
The `command` trait can be used to modify the original running command in deployment's pods.
|
||||
```yaml
|
||||
traits:
|
||||
- type: command
|
||||
properties:
|
||||
command: ["sleep", "8640000"]
|
||||
```
|
||||
|
||||
The above configuration can be used to patch the main container (the container that uses the name of the component). If you would like to modify another container, you could use the field `containerName`.
|
||||
```yaml
|
||||
traits:
|
||||
- type: command
|
||||
properties:
|
||||
command: ["sleep", "8640000"]
|
||||
containerName: sidecar-nginx
|
||||
```
|
||||
|
||||
If you want to replace the existing args in the container, instead of the command, use the `args` parameter.
|
||||
```yaml
|
||||
traits:
|
||||
- type: command
|
||||
properties:
|
||||
args: ["86400"]
|
||||
```
|
||||
|
||||
If you want to append/delete args to the existing args, use the `addArgs`/`delArgs` parameter. This can be useful if you have lots of args to be managed.
|
||||
```yaml
|
||||
traits:
|
||||
- type: command
|
||||
properties:
|
||||
addArgs: ["86400"]
|
||||
```
|
||||
```yaml
|
||||
traits:
|
||||
- type: command
|
||||
properties:
|
||||
delArgs: ["86400"]
|
||||
```
|
||||
|
||||
You can also configure commands in multiple containers.
|
||||
```yaml
|
||||
traits:
|
||||
- type: command
|
||||
properties:
|
||||
containers:
|
||||
- containerName: busybox
|
||||
command: ["sleep", "8640000"]
|
||||
- containerName: sidecar-nginx
|
||||
args: ["-q"]
|
||||
```
|
||||
|
||||
### Environment Variable
|
||||
|
||||
With the trait `env`, you can easily manipulate the declared environment variables.
|
||||
|
||||
For example, the following usage shows how to set multiple environment variables in the main container (the container uses the component's name). If any environment variable does not exist, it will be added. If exists, it will be updated.
|
||||
```yaml
|
||||
traits:
|
||||
- type: env
|
||||
properties:
|
||||
env:
|
||||
key_first: value_first
|
||||
key_second: value_second
|
||||
```
|
||||
|
||||
You can remove existing environment variables by setting the `unset` field.
|
||||
```yaml
|
||||
traits:
|
||||
- type: env
|
||||
properties:
|
||||
unset: ["key_existing_first", "key_existing_second"]
|
||||
```
|
||||
|
||||
If you would like to clear all the existing environment variables first, and then add new variables, use `replace: true`.
|
||||
```yaml
|
||||
traits:
|
||||
- type: env
|
||||
properties:
|
||||
env:
|
||||
key_first: value_first
|
||||
key_second: value_second
|
||||
replace: true
|
||||
```
|
||||
|
||||
If you want to modify the environment variable in other containers, use the `containerName` field.
|
||||
```yaml
|
||||
traits:
|
||||
- type: env
|
||||
properties:
|
||||
env:
|
||||
key_first: value_first
|
||||
key_second: value_second
|
||||
containerName: sidecar-nginx
|
||||
```
|
||||
|
||||
You can set environment variables in multiple containers as well.
|
||||
```yaml
|
||||
traits:
|
||||
- type: env
|
||||
properties:
|
||||
containers:
|
||||
- containerName: busybox
|
||||
env:
|
||||
key_for_busybox_first: value_first
|
||||
key_for_busybox_second: value_second
|
||||
- containerName: sidecar-nginx
|
||||
env:
|
||||
key_for_nginx_first: value_first
|
||||
key_for_nginx_second: value_second
|
||||
```
|
||||
|
||||
### Labels & Annotations
|
||||
|
||||
To add/update/remove labels or annotations for the workload (like Kubernetes Deployment), use the `labels` or `annotations` trait.
|
||||
|
||||
```yaml
|
||||
traits:
|
||||
# the `labels` trait will add/delete label key/value pair to the
|
||||
# labels of the workload and the template inside the spec of the workload (if exists)
|
||||
# 1. if original labels contains the key, value will be overridden
|
||||
# 2. if original labels do not contain the key, value will be added
|
||||
# 3. if original labels contains the key and the value is null, the key will be removed
|
||||
- type: labels
|
||||
properties:
|
||||
added-label-key: added-label-value
|
||||
label-key: modified-label-value
|
||||
to-delete-label-key: null
|
||||
```
|
||||
|
||||
```yaml
|
||||
traits:
|
||||
# the `annotations` trait will add/delete annotation key/value pair to the
|
||||
# labels of the workload and the template inside the spec of the workload (if exists)
|
||||
# 1. if original annotations contains the key, value will be overridden
|
||||
# 2. if original annotations do not contain the key, value will be added
|
||||
# 3. if original annotations contains the key and the value is null, the key will be removed
|
||||
- type: annotations
|
||||
properties:
|
||||
added-annotation-key: added-annotation-value
|
||||
annotation-key: modified-annotation-value
|
||||
to-delete-annotation-key: null
|
||||
```
|
||||
|
||||
### JSON Patch & JSON Merge Patch
|
||||
|
||||
Except for the above trait, a more powerful but more complex way to modify the original resources is to use the `json-patch` or `json-merge-patch` trait. They follow the [RFC 6902](https://datatracker.ietf.org/doc/html/rfc6902) and [RFC 7386](https://datatracker.ietf.org/doc/html/rfc7386) respectively. Usage examples are shown below.
|
||||
|
||||
```yaml
|
||||
traits:
|
||||
# the json patch can be used to add, replace and delete fields
|
||||
# the following part will
|
||||
# 1. add `deploy-label-key` to deployment labels
|
||||
# 2. set deployment replicas to 3
|
||||
# 3. set `pod-label-key` to `pod-label-modified-value` in pod labels
|
||||
# 4. delete `to-delete-label-key` in pod labels
|
||||
# 5. add sidecar container for pod
|
||||
- type: json-patch
|
||||
properties:
|
||||
operations:
|
||||
- op: add
|
||||
path: "/spec/replicas"
|
||||
value: 3
|
||||
- op: replace
|
||||
path: "/spec/template/metadata/labels/pod-label-key"
|
||||
value: pod-label-modified-value
|
||||
- op: remove
|
||||
path: "/spec/template/metadata/labels/to-delete-label-key"
|
||||
- op: add
|
||||
path: "/spec/template/spec/containers/1"
|
||||
value:
|
||||
name: busybox-sidecar
|
||||
image: busybox:1.34
|
||||
command: ["sleep", "864000"]
|
||||
```
|
||||
|
||||
```yaml
|
||||
traits:
|
||||
# the json merge patch can be used to add, replace and delete fields
|
||||
# the following part will
|
||||
# 1. add `deploy-label-key` to deployment labels
|
||||
# 2. set deployment replicas to 3
|
||||
# 3. set `pod-label-key` to `pod-label-modified-value` in pod labels
|
||||
# 4. delete `to-delete-label-key` in pod labels
|
||||
# 5. reset `containers` for pod
|
||||
- type: json-merge-patch
|
||||
properties:
|
||||
metadata:
|
||||
labels:
|
||||
deploy-label-key: deploy-label-added-value
|
||||
spec:
|
||||
replicas: 3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
pod-label-key: pod-label-modified-value
|
||||
to-delete-label-key: null
|
||||
spec:
|
||||
containers:
|
||||
- name: busybox-new
|
||||
image: busybox:1.34
|
||||
command: ["sleep", "864000"]
|
||||
```
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: 系统架构
|
|||
|
||||
KubeVela 的整体架构如下所示：
|
||||
|
||||
|
||||
|
||||
|
||||
## KubeVela 是一个控制平面系统
|
||||
|
||||
|
|
@ -38,9 +38,8 @@ KubeVela 本身是一个的应用交付与管理控制平面，它架在 Kuberne
|
|||
如果要详细学习 KubeVela 的可编程文档，欢迎查看文档网站中 [自定义扩展](../platform-engineers/oam/oam-model) 部分。
|
||||
|
||||
|
||||
## 谁应该使用 KubeVela？
|
||||
## 谁会使用 KubeVela？
|
||||
|
||||
|
||||
|
||||
- 云原生应用平台的构建者、PaaS、Serverless 平台工程师、基础设施平台管理员：
|
||||
- KubeVela 是一个普适的、高可扩展的应用交付引擎与内核，它以极简的架构实现了原生 Kubernetes 多集群控制平面的能力，能够将 OAM 应用引擎直接植入企业已有的 PaaS 平台之中并不破坏已有的能力，从而实现标准化应用交付。
|
||||
|
|
@ -49,7 +48,7 @@ KubeVela 本身是一个的应用交付与管理控制平面，它架在 Kuberne
|
|||
- 云原生时代的应用研发、运维人员、DevOps 工程师：
|
||||
- VelaUX 是一个基于 Vela Addon 机制构建的扩展能力集，安装这个插件后，你就拥有了一个开箱即用的现代化持续交付（CD）和应用管理平台。
|
||||
|
||||
## OAM、KubeVela 和 VelaUX 是什么关系？
|
||||
## 总结
|
||||
|
||||
- [OAM(Open Application Model)](https://github.com/oam-dev/spec) 是 KubeVela 背后的模型，它提供了一组平台无关的最佳实践和方法论，能够为不同的公司和厂商构建应用平台提供理论指导，共同提供标准化应用支撑，让应用可以在不同的平台顺畅的运行、平滑的迁移。当前 OAM 模型的演进主要基于 KubeVela 的实践。
|
||||
- KubeVela 是基于 Kubernetes 的混合云应用交付和管理控制平面，它以 [CRD 控制器](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 的形式运行，可以很轻量的安装到企业现有的 PaaS 体系中，并带来 OAM 的标准化模型和基于模型高可扩展功能的丰富社区插件。
|
||||
|
|
@ -58,7 +57,6 @@ KubeVela 本身是一个的应用交付与管理控制平面，它架在 Kuberne
|
|||
KubeVela 团队将主要聚焦在核心控制器层面，面向所有用户提供可靠、易用的核心框架和能力。另一方面，我们通过构建 VelaUX 插件为中小型企业提供开箱即用的应用交付和管理功能，不仅可以扩大 OAM 模型的受众，也能吃自己的狗粮打磨 KubeVela 核心框架的可扩展性和插件体系。我们将在打磨核心控制器的同时，持续提供开箱即用的插件能力，并与开源社区的优质项目做更多更好的集成。
|
||||
|
||||
|
||||
|
||||
## 下一步
|
||||
|
||||
- 查看 [快速开始](../quick-start)，了解更多使用场景和最佳实践。
|
||||
- 查看 [用户手册](../tutorials/webservice)，了解更多使用场景和最佳实践。
|
||||
|
|
|
|||
|
|
@ -2,32 +2,31 @@
|
|||
title: 模块定义
|
||||
---
|
||||
|
||||
Definition are the basic building block of the KubeVela platform. A definition encapsulates an arbitrarily complex automation as a lego style module that can be used to compose an Application, then safely shared, and repeatably executed by any KubeVela engine.
|
||||
模块定义是组成 KubeVela 平台的基本扩展能力单元，一个模块定义就像乐高积木，它将底层的能力封装成抽象的模块，使得这些能力可以被最终用户快速理解、使用并和其他能力组装、衔接，最终构成一个具有丰富功能的业务应用。模块定义最大的优势是可以被**分发**和**共享**，在不同的业务应用中重复使用，在基于 KubeVela 的不同平台上均能执行。
|
||||
|
||||
There're four types of Definition, they're `ComponentDefinition`, `TraitDefinition`, `PolicyDefinition` and `WorkflowStepDefinition`, corresponding to the application concepts.
|
||||
目前 KubeVela 一共有四种不同类型的模块定义，分别是组件定义（ComponentDefinition）、运维特征定义（TraitDefinition）、策略定义（PolicyDefinition）以及工作流步骤定义（WorkflowStepDefinition），对应了构成[应用](./core-concept)的四个基本概念。
|
||||
|
||||
## 模块定义的来源
|
||||
## 如何获取现成的模块定义？
|
||||
|
||||
There're two sources of definitions:
|
||||
除了自己编写模块定义以外，你可以通过以下两大途径获得社区已有的模块定义：
|
||||
|
||||
* Built-in definitions will be installed along with KubeVela helm chart. You can refer to the following links to learn more about built-in definitions.
|
||||
- [Component Definition](../end-user/components/references)
|
||||
- [Trait Definition](../end-user/traits/references)
|
||||
- [Policy Definition](../end-user/policies/references)
|
||||
- [Workflow Step Definition](../end-user/workflow/built-in-workflow-defs)
|
||||
* Installation of addons will install definitions if there're new capabilities contained.
|
||||
- [Addon registry](../reference/addons/overview) contains a large catalog of addon which are maintained and verified by the KubeVela team.
|
||||
* KubeVela 安装时自动就会安装内置的模块定义，你可以在下面这些参考文档中查看有哪些现成的能力：
|
||||
- [组件定义列表](../end-user/components/references)
|
||||
- [运维特征定义列表](../end-user/traits/references)
|
||||
- [策略定义列表](../end-user/policies/references)
|
||||
- [工作流步骤定义列表](../end-user/workflow/built-in-workflow-defs)
|
||||
* [扩展插件列表](../reference/addons/overview)，作为 KubeVela 的扩展，每一个插件都包含一组模块定义以及支撑其功能的 CRD Controller。
|
||||
- 社区有一个[插件注册中心](https://github.com/kubevela/catalog)包含了大量开箱即用的插件，由 KubeVela 核心维护者负责认证和维护。
|
||||
|
||||
## Lifecycle of a Definition
|
||||
## 模块定义的生命周期
|
||||
|
||||
A definition's lifecycle usually has 3 stages:
|
||||
一个模块定义通常有三个生命周期阶段：
|
||||
|
||||
### Discovery
|
||||
### 发现
|
||||
|
||||
When definitions installed in the system, they can be discovered by end user immediately.
|
||||
|
||||
* Check the list:
|
||||
当模块定义被安装到 KubeVela 控制平面以后，最终用户就可以立即发现和查看它们。
|
||||
|
||||
* 查看模块定义列表
|
||||
```
|
||||
$ vela def list
|
||||
NAME TYPE NAMESPACE DESCRIPTION
|
||||
|
|
@ -41,7 +40,7 @@ notification WorkflowStepDefinition vela-system Send message to
|
|||
...snip...
|
||||
```
|
||||
|
||||
* Show the details:
|
||||
* 查看模块定义的参数
|
||||
```
|
||||
$ vela show webservice
|
||||
# Properties
|
||||
|
|
@ -58,25 +57,31 @@ $ vela show webservice
|
|||
...snip...
|
||||
```
|
||||
|
||||
You can also view the details with a browser, the following command will launch a server and invoke your browser automatically:
|
||||
你也可以通过命令行打开一个网页查看这些参数：
|
||||
|
||||
```
|
||||
vela show webservice --web
|
||||
```
|
||||
|
||||
* Discover in UI console
|
||||
* 在 KubeVela 的 UI 控制台（需安装 velaux 插件）也可以看到
|
||||
|
||||
|
||||
|
||||
These definitions can also be discovered by the UI console, the more important thing is they can be displayed very well with [ui schema](../reference/ui-schema) defined.
|
||||
模块定义在 UI 控制台上可以比较方便的查看，更重要的是会有一个比较好的用户体验，你还可以[自定义 UI 展示](../reference/ui-schema)来优化 UI 控制台上模块定义的参数展示。
|
||||
|
||||
### Use
|
||||
### 使用
|
||||
|
||||
If you're a fan of our UI console, the usage of definition is very straight forward, just click along with the creation of the deployment process.
|
||||
在 KubeVela 的 UI 控制台上使用模块定义是非常自然的，整个流程紧紧围绕应用部署计划展开，你只要跟着界面操作指引一步步点击即可使用。
|
||||
|
||||
|
||||
|
||||
Finally, the UI console will compose the whole deployment plan in the format of OAM like below, then KubeVela controller will take care of the rest things:
|
||||
分为如下几步：
|
||||
|
||||
1. 创建应用选择组件类型，这个过程就是选择使用某个组件定义。
|
||||
2. 填写组件的参数则会根据组件定义的不同出现不同的待填写参数。
|
||||
3. 运维特征、策略、工作流步骤的使用也是如此，分别在不同的应用部署计划业务流程中体现。
|
||||
|
||||
最终 UI 控制台会组装成一个符合 OAM 模型定义的完整应用部署计划，然后 KubeVela 控制器会自动化处理剩下的事情：
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -130,19 +135,21 @@ spec:
|
|||
policies: ["target-prod", "deploy-ha"]
|
||||
```
|
||||
|
||||
Use the definition in command works the same, you can compose the application yaml manually and use `vela` command line tool to deploy.
|
||||
使用 KubeVela 命令行工具来使用模块定义也是如此，只要编写上述 Application 对象的 YAML 文件即可，可以使用 `vela` 命令如下：
|
||||
|
||||
```
|
||||
vela up -f https://kubevela.net/example/applications/first-app.yaml
|
||||
```
|
||||
|
||||
### Customize
|
||||
Application 也是一种 Kubernetes 的 CRD，你可以通过 `kubectl` 工具，或者直接调用 Kubernetes API 集成 KubeVela 功能。
|
||||
|
||||
> **⚠️ In most cases, you don't need to customize any definitions unless you're going to extend the capability of KubeVela. Before that, you should check the built-in definitions and addons to confirm if they can fit your needs.**
|
||||
### 自定义
|
||||
|
||||
A new definition is built in a declarative template in [CUE configuration language](https://cuelang.org/). If you're not familiar with CUE, you can refer to [CUE Basic](../platform-engineers/cue/basic) for some knowledge.
|
||||
> **⚠️ 请注意，在多数情况下，你不需要编写自定义模块，除非你的目的是扩展 KubeVela 的系统能力。在此之前，我们建议你先查看 KubeVela 内置的模块定义以及扩展插件，可能它们已经足够满足你的需求。**
|
||||
|
||||
A definition describes the module's inputs, outputs, operations, and the wiring between them. Here is an example of a simple component definition:
|
||||
KubeVela 使用 [CUE 配置语言](https://cuelang.org/)来编写自定义模块，如果你对 CUE 语言还不熟悉也不必担心，可以查看 [CUE 入门指南](../platform-engineers/cue/basic)，花 15 分钟即可了解基本的实用操作。
|
||||
|
||||
一个模块定义包含输入、输出、操作以及这三者之间的衔接关系，一个简单的组件模块定义如下所示：
|
||||
|
||||
```
|
||||
webserver: {
|
||||
|
|
@ -168,9 +175,8 @@ template: {
|
|||
}
|
||||
```
|
||||
|
||||
The `type` defines what kind of definition it is, the `parameter` defines the inputs, while the `output` section defines the outputs.
|
||||
You can refer to detail docs about [how to manage definition](../platform-engineers/cue/definition-edit) or learn the [definition protocol](../platform-engineers/oam/x-definition).
|
||||
`type` 字段定义了这个模块是哪种类型（组件、运维特征、策略或者工作流步骤）， `parameter` 定义了模块的输入，`output` 定义了模块的输出。还有一些高级的操作你可以通过了解[如何管理、编写模块定义](../platform-engineers/cue/definition-edit)以及[模块定义与 Kubernetes 的交互协议](../platform-engineers/oam/x-definition) 等章节文档了解更多细节。
|
||||
|
||||
## Next Step
|
||||
## 下一步
|
||||
|
||||
- View [Architecture](./architecture) to learn the overall architecture of KubeVela.
|
||||
- 查看 KubeVela [项目架构](./architecture)文档了解全局的架构。
|
||||
|
|
|
|||
|
|
@ -2,141 +2,4 @@
|
|||
title: 插件管理
|
||||
---
|
||||
|
||||
你可以通过安装 KubeVela 的插件（Addon）获取更多的系统功能。
|
||||
|
||||
## 通过 UI 管理插件
|
||||
|
||||
具有插件管理权限的用户可以进入插件管理页面，进行插件启用/停用等操作。
|
||||
|
||||
|
||||
|
||||
如上图所示，在插件列表中，你可以查看到插件启用状态和其他基础信息。点击插件名称可以进入到插件详情页面，你可以查询到插件的版本列表，提供的扩展类型和介绍信息。
|
||||
|
||||
|
||||
|
||||
选择一个部署版本（默认为最新），设置需要部署的集群后，你可以点击 启用 按钮安装该插件。对于已启用的插件，如果没有应用使用该插件提供的扩展，你可以点击禁用按钮来卸载它。
|
||||
|
||||
## 通过 CLI 管理插件
|
||||
|
||||
### 查看所有插件
|
||||
|
||||
KubeVela 官方团队维护了一个默认的插件仓库 (https://addons.kubevela.net) ，默认情况下会从这个仓库实时发现。
|
||||
|
||||
|
||||
```shell
|
||||
$ vela addon list
|
||||
NAME REGISTRY DESCRIPTION AVAILABLE-VERSIONS STATUS
|
||||
ocm-gateway-manager-addon KubeVela ocm-gateway-manager-addon is the OCM addon automates the cluster-gateway apiserver. [1.3.2, 1.3.0, 1.1.11] disabled
|
||||
rollout KubeVela Provides basic batch publishing capability. [1.3.0, 1.2.4, 1.2.3] disabled
|
||||
terraform-baidu KubeVela Kubernetes Terraform Controller Provider for Baidu Cloud [1.0.1, 1.0.0] disabled
|
||||
terraform-tencent KubeVela Kubernetes Terraform Controller Provider for Tencent Cloud [1.0.1, 1.0.0] disabled
|
||||
model-serving KubeVela Enable serving for models [1.0.0] disabled
|
||||
model-training KubeVela Enable training for models [1.0.0] disabled
|
||||
terraform KubeVela Terraform Controller is a Kubernetes Controller for Terraform. [1.0.6] disabled
|
||||
terraform-aws KubeVela Kubernetes Terraform Controller for AWS [1.0.1, 1.0.0] disabled
|
||||
terraform-azure KubeVela Kubernetes Terraform Controller for Azure [1.0.1, 1.0.0] disabled
|
||||
terraform-gcp KubeVela Kubernetes Terraform Controller Provider for Google Cloud Platform [1.0.1, 1.0.0] disabled
|
||||
dex KubeVela Enable dex for login [0.6.5] disabled
|
||||
ocm-hub-control-plane KubeVela ocm-hub-control-plane can install OCM hub control plane to the central cluster. [0.6.0] disabled
|
||||
terraform-ucloud KubeVela Kubernetes Terraform Controller Provider for UCloud [1.0.1, 1.0.0] disabled
|
||||
fluxcd KubeVela Extended workload to do continuous and progressive delivery [1.1.0, 1.0.0] disabled
|
||||
velaux KubeVela KubeVela User Experience (UX). An extensible, application-oriented delivery and management Dashboard. [v1.3.0, v1.3.0-beta.2, 1.2.4] enabled (v1.3.0)
|
||||
terraform-alibaba KubeVela Kubernetes Terraform Controller for Alibaba Cloud [1.0.2, 1.0.1] disabled
|
||||
```
|
||||
|
||||
### 安装插件
|
||||
|
||||
```
|
||||
$ vela addon enable fluxcd
|
||||
I0111 21:45:24.553174 89345 apply.go:106] "creating object" name="addon-fluxcd" resource="core.oam.dev/v1beta1, Kind=Application"
|
||||
I0111 21:45:25.258914 89345 apply.go:106] "creating object" name="helm" resource="core.oam.dev/v1beta1, Kind=ComponentDefinition"
|
||||
I0111 21:45:25.342731 89345 apply.go:106] "creating object" name="kustomize-json-patch" resource="core.oam.dev/v1beta1, Kind=TraitDefinition"
|
||||
I0111 21:45:25.382201 89345 apply.go:106] "creating object" name="kustomize-patch" resource="core.oam.dev/v1beta1, Kind=TraitDefinition"
|
||||
I0111 21:45:25.411723 89345 apply.go:106] "creating object" name="kustomize" resource="core.oam.dev/v1beta1, Kind=ComponentDefinition"
|
||||
I0111 21:45:25.625815 89345 apply.go:106] "creating object" name="kustomize-strategy-merge" resource="core.oam.dev/v1beta1, Kind=TraitDefinition"
|
||||
I0111 21:45:25.660129 89345 apply.go:106] "creating object" name="component-uischema-helm" resource="/v1, Kind=ConfigMap"
|
||||
Addon: fluxcd enabled Successfully.
|
||||
```
|
||||
|
||||
#### 安装特定版本的插件
|
||||
|
||||
你可以通过通过设置 `--version` 启动参数，来指定安装插件的某个特定版本。例如：
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd --version=1.0.0
|
||||
```
|
||||
|
||||
如果不指定该参数，默认会安装此插件的最新版本。
|
||||
|
||||
启用一个插件时，默认会在所有子集群中安装该插件，你也可以通过设置 `--cluster` 启动参数选择安装在某些集群当中。例如：
|
||||
|
||||
```shell
|
||||
vela addon enable <addon-name> --clusters={cluster1,cluster2}
|
||||
```
|
||||
|
||||
安装完成后，插件中的功能会以组件，运维特征，工作流步骤等形式呈现，你可以通过 `vela component`，`vela trait` 等命令查看新增的能力，也可以在[插件的参考文档](../../../reference/addons/overview)中查看每个官方插件对应的能力.
|
||||
|
||||
### 删除/卸载已安装的插件
|
||||
|
||||
> 删除前请确认插件对应的能力没有被任何应用使用。
|
||||
|
||||
```
|
||||
$ vela addon disable fluxcd
|
||||
Successfully disable addon:fluxcd
|
||||
```
|
||||
|
||||
### 查看插件的下载仓库
|
||||
|
||||
```
|
||||
$ vela addon registry list
|
||||
Name Type URL
|
||||
KubeVela helm https://addons.kubevela.net
|
||||
```
|
||||
|
||||
KubeVela 社区在 Github 上维护了一个官方的[正式插件包仓库](https://github.com/kubevela/catalog/tree/master/addons) 和一个[试验阶段插件包仓库](https://github.com/kubevela/catalog/tree/master/experimental) 。你在相应的仓库中找到插件包的定义文件。
|
||||
|
||||
同时这些文件会被同步到 [对象存储](https://addons.kubevela.net) 当中，以加快下载速度。
|
||||
|
||||
### 添加插件包仓库
|
||||
|
||||
你可以添加自己的插件包仓库，目前支持 OSS 和 Github 两种仓库类型。
|
||||
|
||||
```
|
||||
$ vela addon registry add experimental --type OSS --endpoint=https://addons.kubevela.net --path=experimental/
|
||||
Successfully add an addon registry experimental
|
||||
```
|
||||
|
||||
### 删除一个插件包仓库
|
||||
|
||||
```
|
||||
$ vela addon registry delete experimental
|
||||
Successfully delete an addon registry experimental
|
||||
```
|
||||
|
||||
### 多集群环境中启用插件包
|
||||
|
||||
如果你的环境中添加了若干个子集群，启用插件包时会默认在管控集群和所有子集群中安装此插件包。但如果子集群在某个插件包启用之后加入环境当中，则需要通过升级操作在新加入集群中安装此插件包。如下所示
|
||||
|
||||
```
|
||||
$ vela addon upgrade velaux
|
||||
Addon:
|
||||
enabled Successfully
|
||||
```
|
||||
|
||||
### 离线安装插件包
|
||||
|
||||
如果因为某些原因，你的环境无法通过访问插件包仓库，你可以通过指定本地的插件包目录来进行离线安装。如下所示：
|
||||
|
||||
```
|
||||
$ ls
|
||||
README.md fluxcd ocm-cluster-manager terraform terraform-alibaba terraform-aws terraform-azure velaux
|
||||
|
||||
$ vela addon enable velaux/
|
||||
Addon: velaux enabled Successfully
|
||||
```
|
||||
|
||||
需要注意的是，在安装插件过程当中，仍可能需要从网络中拉取镜像或者 helm chart，如果你的网络环境同样无法访问这些地址，请参考[文档](../../../platform-engineers/system-operation/enable-addon-offline)进行完整的离线安装。
|
||||
|
||||
## 编写自己的插件包
|
||||
|
||||
请参考[插件包制作文档](../../../platform-engineers/addon/intro)。
|
||||
文档已迁移到[这里](../../../end-user/components/more)。
|
||||
|
|
|
|||
|
|
@ -1,8 +1,10 @@
|
|||
---
|
||||
title: 创建应用
|
||||
title: 应用生命周期管理
|
||||
description: 本文介绍在 KubeVela Dashboard 中创建应用的操作方法。
|
||||
---
|
||||
|
||||
## 创建应用
|
||||
|
||||
### 判断你的应用类别
|
||||
|
||||
我们大致把应用分为三种类型，普通业务应用、中间件（第三方开源应用）、云服务。对于普通业务应用，我们建议你采用 `webservice` 部署类型或你的自定义类型。对于中间件或第三方复杂应用建议直接采用 `helm` 部署类型，对于比较简单且直接提供了 Docker 镜像的第三方开源应用，比如 wordpress,也可以直接采用 `webservice` 类型。
|
||||
|
|
@ -21,6 +23,155 @@ description: 本文介绍在 KubeVela Dashboard 中创建应用的操作方法
|
|||
|
||||
根据提示完成部署参数的设置后，点击提交按钮即可完成应用创建。成功创建后进入应用管理页面，应用处于未部署状态。
|
||||
|
||||
### 下一步
|
||||
## 绑定应用到环境
|
||||
|
||||
* [绑定应用到环境](./bind-new-environment).
|
||||
应用在创建完成后，需要绑定到 1 个或多个环境才能正式发布。
|
||||
|
||||
你可以绑定到开发环境做测试，然后在测试完成后绑定到生产环境做发布，不同的环境之间彼此隔离、互不影响。
|
||||
|
||||
创建完成应用后，在应用管理页面点击 `Bind Environment`就会出现如下弹窗：
|
||||
|
||||
|
||||
|
||||
在弹窗中选择需要发布的环境。如果环境还没创建，可点击下方的 `Create new environment` 创建新的环境。
|
||||
|
||||
点击确认即完成绑定，`Baseline Config` 右侧环境选项区域出现新的环境，且在工作流管理页面将自动生成新环境的部署工作流。切换到新环境视图下点击 `Deploy` 即可将应用发布到该环境。
|
||||
|
||||
## 部署应用
|
||||
|
||||
应用创建完成后，需要分别执行环境对应的工作流完成环境的部署，每个环节的对应工作流会自动生成。
|
||||
|
||||
### 首次部署
|
||||
|
||||
从应用列表点击指定应用进入应用详细页面，在 `Baseline Config` 右侧即为所有已绑定的环境列表。选择你需要部署的环境，点击环境名称进入环境页面。
|
||||
|
||||
|
||||
|
||||
环境处于未部署状态时将显示部署按钮，点击按钮即可开始执行当前环境的部署工作流。工作流执行状态显示在页面的右上方。如果你设置了审核的步骤，到达该步骤时页面中将弹出审核窗口。
|
||||
|
||||
|
||||
|
||||
如果部署步骤出现故障，该步骤显示为红色，鼠标移动到该步骤上将显示故障原因。
|
||||
|
||||
|
||||
|
||||
### 更新
|
||||
|
||||
应用详情页面的右上方有一个常驻的 `Deploy` 按钮，点击该按钮执行默认工作流。按钮右边三点按钮为选择不同的环境工作流，鼠标移动到其上方即可显示多个工作流选项。
|
||||
|
||||
|
||||
|
||||
更新部署可以在任意状态下进行，选择执行某一个流水线后，将使用最新的应用配置进行部署。如果该环境正在执行部署，UI 将提示你是否强制进行新的部署。
|
||||
|
||||
## 查看应用实例
|
||||
|
||||
查看应用运行实例信息是掌握应用运行状态的直接方式。
|
||||
|
||||
|
||||
|
||||
如上图所示，应用的运行实例页面处在应用环境视图下。切换不同的环境即可查询不同环境下部署的实例。
|
||||
|
||||
默认情况下，实例列表显示该应用在当前环境下的所有实例。通过实例列表上方的交付目标筛选，可以查询不同交付目标的实例列表。在实例列表中显示版本、状态等信息。
|
||||
|
||||
对于交付的 Kubernetes 集群的应用，用户可以点击实例行前方的 + 号展开一个实例的详情，即 Pod 详情，包括了容器状态及资源消耗情况，如果实例的拉起故障，可以从事件列表中查看到详细信息。
|
||||
|
||||
对于交付的 云服务 应用，用户可通过点击实例名称跳转到云服务商管理页面。
|
||||
|
||||
|
||||
|
||||
## 查看日志
|
||||
|
||||
### 通过 UI 查看应用日志
|
||||
|
||||
|
||||
|
||||
如上图所示，交付到 Kubernetes 集群的应用支持查询容器运行日志，切换到指定环境视图下，选择日志页面，即可通过组件/实例/容器的筛选查看对应的运行日志。
|
||||
|
||||
日志查询页面默认为每 5 秒自动刷新，查看最新的日志。若你的应用日志中没有时间信息，可点击 `Show timestamps` 展示日志记录时间。
|
||||
|
||||
### 通过 CLI 查看应用日志
|
||||
|
||||
```bash
|
||||
$ vela logs <app_name> -n <namespace>
|
||||
```
|
||||
|
||||
使用实际的应用名称，命名空间参数执行上述命令，在交互中选择你需要查询的工作负载即可查询应用日志。
|
||||
|
||||
## 访问应用
|
||||
|
||||
### 设置应用访问方式
|
||||
|
||||
交付的 Kubernetes 集群的应用需要设置访问方式即可生成访问地址，常见支持的方式如下：
|
||||
|
||||
1. 设置 Service 的暴露类型，比如 `LoadBalancer` 和 `NodePort`。适用于所有应用协议。
|
||||
2. 设置 Ingress 策略，仅适用于 HTTP/HTTPs 协议。
|
||||
|
||||
#### `webservice` 类型的应用
|
||||
|
||||
在部署参数中可以修改 `ExposeType` 字段参数来设置其暴露方式，同时在 `Service Ports` 中设置应用的监听端口，并将 `Expose` 设置为 True。
|
||||
|
||||
|
||||
|
||||
如果你的集群中存在 `Ingress Controller`，在应用 `Baseline Config` 页面中，新增 `gateway` 运维特征来设置访问域名。
|
||||
|
||||
|
||||
|
||||
如上图所示，在 `Domain` 中配置你的域名，注意请将该域名 DNS 解析到目标集群的网关 IP 之上。在 `Http` 模块下配置路由规则，默认你需要设置 `/`:`80`，根据你的应用监听端口设置。
|
||||
|
||||
其他部署类型的应用，一般存在对应的部署参数设置选项，根据部署参数设置即可。
|
||||
|
||||
### 获取访问地址
|
||||
|
||||
设置完应用访问方式后，执行应用部署，然后切换到环境视图下即可看到 `Service Endpoint` 按钮，鼠标移动到上方即可显示该应用的访问地址。
|
||||
|
||||
|
||||
|
||||
## 查看应用部署的资源列表
|
||||
|
||||
如果你希望查询应用在各集群部署了哪些资源，可通过下述操作方式查询。
|
||||
|
||||
## 通过 UI 查询
|
||||
|
||||
进入应用部署环境视图，默认进入状态展示页面，在该页面中即可查询到应用实际分发的资源列表，如果应用在更新过程中，资源列表会包括历史和当前版本。
|
||||
|
||||
|
||||
|
||||
在该页面中同时展示了组件状态和整体的交付状态。
|
||||
|
||||
## 通过 CLI 查询
|
||||
|
||||
```bash
|
||||
$ vela status <app_name> -n <namespace> --tree
|
||||
```
|
||||
|
||||
基于如上命令可以查询应用部署的资源清单。
|
||||
|
||||
## 查看应用部署版本
|
||||
|
||||
应用每执行一次部署即可生成一个版本，通过应用 `Baseline Config` 视图下的 `Revisions` 页面展示应用的历史部署版本。
|
||||
|
||||
|
||||
|
||||
通过 Webhook Trigger 触发部署的版本，如果携带了代码信息，版本号可与代码 Commit 信息进行关联。
|
||||
|
||||
## 回收应用部署的环境
|
||||
|
||||
当你需要将应用在某个环境的部署资源回收，即关闭应用时，参考下述操作。
|
||||
|
||||
|
||||
|
||||
如上图所示，完成部署的环境视图下回出现 `Recycle` 按钮，点击该按钮确认后即可将该环境部署的资源进行回收删除。
|
||||
|
||||
> 请注意，回收意味着对应的资源将删除，对于需要有状态存储的应用，该操作会导致数据丢失。纯无状态应用可通过重新部署后恢复。
|
||||
|
||||
### 删除应用和环境的绑定关系
|
||||
|
||||
应用如果成功从该环境回收后，操作区域将存在 `Delete` 按钮，点击该按钮即可删除应用与环境的绑定关系。
|
||||
|
||||
## 删除应用
|
||||
|
||||
应用需要完成所有环境的资源回收，完成后即可进行删除操作。
|
||||
|
||||
|
||||
|
||||
如上图所示，回到应用列表页面，鼠标移动到应用名称右侧的操作图标上，点击 Remove 选项即可完成应用的删除操作。
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ description: 指定用户将创建的应用部署到指定的环境。
|
|||
|
||||
|
||||
|
||||
### 更新部署
|
||||
### 更新
|
||||
|
||||
应用详情页面的右上方有一个常驻的 `Deploy` 按钮，点击该按钮执行默认工作流。按钮右边三点按钮为选择不同的环境工作流，鼠标移动到其上方即可显示多个工作流选项。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,20 @@
|
|||
---
|
||||
title: 使用触发器对接 CI 自动部署
|
||||
title: 触发器
|
||||
description: 使用触发器对接 CI 自动部署
|
||||
---
|
||||
|
||||
You can use triggers from [VelaUX addon](../../../reference/addons/velaux) to integrate with different CI systems, the architecture and supported platforms are described in the following picture, they're:
|
||||
|
||||
- [Custom](#custom-trigger), refer to [Jenkins CI](../../../tutorials/jenkins) guide for a real world use case
|
||||
- [ACR](#ACR-trigger)
|
||||
- [Harbor](#Harbor-trigger), refer to [Harbor Integration](../../../tutorials/trigger) guide for a real world use case
|
||||
- [DockerHub](#DockerHub-trigger)
|
||||
- [JFrog](#JFrog-trigger)
|
||||
|
||||
|
||||
|
||||
## 如何使用
|
||||
|
||||
应用在创建完成后，会自动创建一个默认触发器，你可以删除或者创建新的触发器。
|
||||
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 287 KiB |
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Kubernetes 原生资源
|
||||
title: 部署 Kubernetes 对象
|
||||
description: 对 Kubernetes 有一定了解的用户，参考本文档学习利用 KubeVela 的能力将已经定义好的 Kubernetes 资源便捷交付到多个集群。
|
||||
---
|
||||
|
||||
|
|
@ -12,13 +12,6 @@ KubeVela 支持面向应用组织多个 Kubernetes 资源进行交付，常见
|
|||
3. 初步了解多环境/多集群的应用发布。
|
||||
4. 应用发布过程控制：回退、终止和继续。
|
||||
|
||||
不仅如此，你还可以使用 KubeVela 引用已有的 Kubernetes 对象并将它们分发到其他位置来完成以下场景：
|
||||
|
||||
- 将管控集群中的密钥复制到子集群中。
|
||||
- 将验证集群中的工作负载部署到生产集群中。
|
||||
- 使用 Kubernetes 原生的 apiserver 作为控制面，将所有的 Kubernetes 对象存储在外部数据库中。然后通过引用这些资源，将它们下发到真正运行负载的子集群中。
|
||||
|
||||
|
||||
## 开始之前
|
||||
|
||||
- 准备一个 Deployment+Service 资源的 Yaml 定义文件，请注意，涉及多个资源时请将 Deployment、Statefulset、Job 等工作负载类资源置于第一个。如果多个工作负载类资源，请拆分为多个应用。
|
||||
|
|
@ -199,102 +192,6 @@ $ vela up -f https://kubevela.io/example/applications/app-with-k8s-objects.yaml
|
|||
$ vela workflow resume app-with-k8s-objects
|
||||
```
|
||||
|
||||
## 分发引用的外部 Kubernetes 对象
|
||||
|
||||
> 开始这部分之前需要你先了解使用 CLI 如何进行多集群应用的部署。你可以参考 [多集群应用交付](../case-studies/multi-cluster) 章节.
|
||||
|
||||
## 在组件中引用已有的 Kubernetes 对象
|
||||
|
||||
为了在组件中使用已有的 Kubernetes 对象，你需要使用 `ref-objects` 类型的组件，并在参数中声明你想要引用的资源。例如，在下面的例子中，命名空间 `examples` 中的密钥 `image-credential-to-copy` 会被作为组件的源数据，然后你可以使用 Topology 策略来将它复制分发到杭州集群中。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ref-objects-example
|
||||
namespace: examples
|
||||
spec:
|
||||
components:
|
||||
- name: image-pull-secrets
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- resource: secret
|
||||
name: image-credential-to-copy
|
||||
policies:
|
||||
- name: topology-hangzhou-clusters
|
||||
type: topology
|
||||
properties:
|
||||
clusterLabelSelector:
|
||||
region: hangzhou
|
||||
```
|
||||
|
||||
## *ref-objects* 类型组件的细节
|
||||
|
||||
声明需要引用资源最直接的方法是使用 `resource: secret` 或 `resource: deployment` 这样的方式来确定引用资源的类型。如果 `name` 和 `labelSelector` 都没有被设置，那么应用将会在它的命名空间下尝试寻找与和组件名称一致的资源。你也可以显式地指定 `name` 和 `namespace` 来确定需要引用的资源。
|
||||
|
||||
除了 `name` 和 `namespace`，你还可以使用 `cluster` 字段让应用组件去引用子集群中的资源。你也可以使用 `labelSelector` 来筛选资源，而不是直接用 `name` 去确定目标资源。
|
||||
|
||||
在下面的样例中，应用会选择在 *hangzhou-1* 集群的 *examples* 命名空间中，所有符合声明标签要求的 Deployment。然后应用会将这些 Deployments 复制到 *hangzhou-2* 集群中。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ref-objects-duplicate-deployments
|
||||
namespace: examples
|
||||
spec:
|
||||
components:
|
||||
- name: duplicate-deployment
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- resource: deployment
|
||||
cluster: hangzhou-1
|
||||
# select all deployment in the `examples` namespace in cluster `hangzhou-1` that matches the labelSelector
|
||||
labelSelector:
|
||||
need-duplicate: "true"
|
||||
policies:
|
||||
- name: topology-hangzhou-2
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["hangzhou-2"]
|
||||
```
|
||||
|
||||
> 在一些场景下，你可能想要限制应用能够引用资源的范围，你可以通过在 KubeVela 控制器中设置 `--ref-objects-available-scope` 为 `namespace` 或者 `cluster` 来限制只在同命名空间或者同一集群内引用资源。
|
||||
|
||||
## 在 ref-objects 类型组件内使用运维特征
|
||||
|
||||
*ref-objects* 类型的组件同样也可以使用运维特征。其主体工作负载会被隐式地设置为引用资源列表中的第一个资源。所有作用在工作负载上的运维特征都会指向该资源。 如下所示的例子展示了如何为引用的 Deployment 设置副本数，并下发到 hangzhou 集群中。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ref-objects-multiple-resources
|
||||
namespace: examples
|
||||
spec:
|
||||
components:
|
||||
- name: nginx-ref-multiple-resources
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- resource: deployment
|
||||
- resource: service
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 3
|
||||
policies:
|
||||
- name: topology-hangzhou-clusters
|
||||
type: topology
|
||||
properties:
|
||||
clusterLabelSelector:
|
||||
region: hangzhou
|
||||
```
|
||||
|
||||
到此你已经完成了交付 Kubernetes 原生资源的学习！
|
||||
|
||||
## 下一步
|
||||
|
||||
- [交付云厂商服务](./consume-cloud-services)
|
||||
|
|
|
|||
|
|
@ -53,6 +53,3 @@ description: 本文介绍 KubeVela 的工作流工程模式，常用操作和适
|
|||
|
||||
工作流配置完成后注意点击工作流窗口右上方的 Save 按钮保存所有变更。保存完成后可以点击页面右上方的 `Deploy` 或右边的选择按钮选择执行该工作流，验证是否可以收到消息通知。
|
||||
|
||||
## 下一步
|
||||
|
||||
- [部署应用到指定环境](../how-to/dashboard/application/deploy-application)
|
||||
|
|
@ -2,13 +2,159 @@
|
|||
title: 获得更多？
|
||||
---
|
||||
|
||||
* 查看 [组件参考列表](./references)文档，了解所有内置支持的交付制品。
|
||||
KubeVela 是可编程的，你可以通过自定义模块轻松地扩展它，主流的方式是通过以下的途径发现、安装新的扩展能力：
|
||||
|
||||
* 通过[安装插件](../../how-to/cli/addon/addon)集成更多交付制品。
|
||||
## 了解内置的模块能力
|
||||
|
||||
* 自己动手扩展
|
||||
KubeVela 安装时就自带了很多开箱即用的功能，可以查看如下手册了解详情：
|
||||
|
||||
* 阅读[如何通过已经存在的 Definition 修改从而自定义组件类型](../../platform-engineers/cue/definition-edit)。
|
||||
* [构建自己的能力](../../platform-engineers/cue/advanced)
|
||||
学习[从零开始构建组件](../../platform-engineers/components/custom-component)。
|
||||
* [构建自己的插件](../../platform-engineers/addon/intro)。
|
||||
- [内置组件](./references)
|
||||
- [内置运维特征](../traits/references)
|
||||
- [内置策略](../policies/references)
|
||||
- [内置工作流步骤](../workflow/built-in-workflow-defs)
|
||||
|
||||
## 管理插件
|
||||
|
||||
你可以通过安装 KubeVela 的插件（Addon）获取更多的扩展能力。
|
||||
|
||||
### 查看所有插件
|
||||
|
||||
KubeVela 官方团队维护了一个默认的插件仓库 (https://addons.kubevela.net) ，默认情况下会从这个仓库实时发现。
|
||||
|
||||
|
||||
```shell
|
||||
$ vela addon list
|
||||
NAME REGISTRY DESCRIPTION AVAILABLE-VERSIONS STATUS
|
||||
ocm-gateway-manager-addon KubeVela ocm-gateway-manager-addon is the OCM addon automates the cluster-gateway apiserver. [1.3.2, 1.3.0, 1.1.11] disabled
|
||||
rollout KubeVela Provides basic batch publishing capability. [1.3.0, 1.2.4, 1.2.3] disabled
|
||||
terraform-baidu KubeVela Kubernetes Terraform Controller Provider for Baidu Cloud [1.0.1, 1.0.0] disabled
|
||||
terraform-tencent KubeVela Kubernetes Terraform Controller Provider for Tencent Cloud [1.0.1, 1.0.0] disabled
|
||||
model-serving KubeVela Enable serving for models [1.0.0] disabled
|
||||
model-training KubeVela Enable training for models [1.0.0] disabled
|
||||
terraform KubeVela Terraform Controller is a Kubernetes Controller for Terraform. [1.0.6] disabled
|
||||
terraform-aws KubeVela Kubernetes Terraform Controller for AWS [1.0.1, 1.0.0] disabled
|
||||
terraform-azure KubeVela Kubernetes Terraform Controller for Azure [1.0.1, 1.0.0] disabled
|
||||
terraform-gcp KubeVela Kubernetes Terraform Controller Provider for Google Cloud Platform [1.0.1, 1.0.0] disabled
|
||||
dex KubeVela Enable dex for login [0.6.5] disabled
|
||||
ocm-hub-control-plane KubeVela ocm-hub-control-plane can install OCM hub control plane to the central cluster. [0.6.0] disabled
|
||||
terraform-ucloud KubeVela Kubernetes Terraform Controller Provider for UCloud [1.0.1, 1.0.0] disabled
|
||||
fluxcd KubeVela Extended workload to do continuous and progressive delivery [1.1.0, 1.0.0] disabled
|
||||
velaux KubeVela KubeVela User Experience (UX). An extensible, application-oriented delivery and management Dashboard. [v1.3.0, v1.3.0-beta.2, 1.2.4] enabled (v1.3.0)
|
||||
terraform-alibaba KubeVela Kubernetes Terraform Controller for Alibaba Cloud [1.0.2, 1.0.1] disabled
|
||||
```
|
||||
|
||||
### 安装插件
|
||||
|
||||
```
|
||||
$ vela addon enable fluxcd
|
||||
I0111 21:45:24.553174 89345 apply.go:106] "creating object" name="addon-fluxcd" resource="core.oam.dev/v1beta1, Kind=Application"
|
||||
I0111 21:45:25.258914 89345 apply.go:106] "creating object" name="helm" resource="core.oam.dev/v1beta1, Kind=ComponentDefinition"
|
||||
I0111 21:45:25.342731 89345 apply.go:106] "creating object" name="kustomize-json-patch" resource="core.oam.dev/v1beta1, Kind=TraitDefinition"
|
||||
I0111 21:45:25.382201 89345 apply.go:106] "creating object" name="kustomize-patch" resource="core.oam.dev/v1beta1, Kind=TraitDefinition"
|
||||
I0111 21:45:25.411723 89345 apply.go:106] "creating object" name="kustomize" resource="core.oam.dev/v1beta1, Kind=ComponentDefinition"
|
||||
I0111 21:45:25.625815 89345 apply.go:106] "creating object" name="kustomize-strategy-merge" resource="core.oam.dev/v1beta1, Kind=TraitDefinition"
|
||||
I0111 21:45:25.660129 89345 apply.go:106] "creating object" name="component-uischema-helm" resource="/v1, Kind=ConfigMap"
|
||||
Addon: fluxcd enabled Successfully.
|
||||
```
|
||||
|
||||
#### 安装特定版本的插件
|
||||
|
||||
你可以通过通过设置 `--version` 启动参数，来指定安装插件的某个特定版本。例如：
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd --version=1.0.0
|
||||
```
|
||||
|
||||
如果不指定该参数，默认会安装此插件的最新版本。
|
||||
|
||||
启用一个插件时，默认会在所有子集群中安装该插件，你也可以通过设置 `--cluster` 启动参数选择安装在某些集群当中。例如：
|
||||
|
||||
```shell
|
||||
vela addon enable <addon-name> --clusters={cluster1,cluster2}
|
||||
```
|
||||
|
||||
安装完成后，插件中的功能会以组件，运维特征，工作流步骤等形式呈现，你可以通过 `vela component`，`vela trait` 等命令查看新增的能力，也可以在[插件的参考文档](../../reference/addons/overview)中查看每个官方插件对应的能力.
|
||||
|
||||
### 删除/卸载已安装的插件
|
||||
|
||||
> 删除前请确认插件对应的能力没有被任何应用使用。
|
||||
|
||||
```
|
||||
$ vela addon disable fluxcd
|
||||
Successfully disable addon:fluxcd
|
||||
```
|
||||
|
||||
### 查看插件的下载仓库
|
||||
|
||||
```
|
||||
$ vela addon registry list
|
||||
Name Type URL
|
||||
KubeVela helm https://addons.kubevela.net
|
||||
```
|
||||
|
||||
KubeVela 社区在 Github 上维护了一个官方的[正式插件包仓库](https://github.com/kubevela/catalog/tree/master/addons) 和一个[试验阶段插件包仓库](https://github.com/kubevela/catalog/tree/master/experimental) 。你在相应的仓库中找到插件包的定义文件。
|
||||
|
||||
同时这些文件会被同步到 [对象存储](https://addons.kubevela.net) 当中，以加快下载速度。
|
||||
|
||||
### 添加插件包仓库
|
||||
|
||||
你可以添加自己的插件包仓库，目前支持 OSS 和 Github 两种仓库类型。
|
||||
|
||||
```
|
||||
$ vela addon registry add experimental --type OSS --endpoint=https://addons.kubevela.net --path=experimental/
|
||||
Successfully add an addon registry experimental
|
||||
```
|
||||
|
||||
### 删除一个插件包仓库
|
||||
|
||||
```
|
||||
$ vela addon registry delete experimental
|
||||
Successfully delete an addon registry experimental
|
||||
```
|
||||
|
||||
### 多集群环境中启用插件包
|
||||
|
||||
如果你的环境中添加了若干个子集群，启用插件包时会默认在管控集群和所有子集群中安装此插件包。但如果子集群在某个插件包启用之后加入环境当中，则需要通过升级操作在新加入集群中安装此插件包。如下所示
|
||||
|
||||
```
|
||||
$ vela addon upgrade velaux
|
||||
Addon:
|
||||
enabled Successfully
|
||||
```
|
||||
|
||||
### 离线安装插件包
|
||||
|
||||
如果因为某些原因，你的环境无法通过访问插件包仓库，你可以通过指定本地的插件包目录来进行离线安装。如下所示：
|
||||
|
||||
```
|
||||
$ ls
|
||||
README.md fluxcd ocm-cluster-manager terraform terraform-alibaba terraform-aws terraform-azure velaux
|
||||
|
||||
$ vela addon enable velaux/
|
||||
Addon: velaux enabled Successfully
|
||||
```
|
||||
|
||||
需要注意的是，在安装插件过程当中，仍可能需要从网络中拉取镜像或者 helm chart，如果你的网络环境同样无法访问这些地址，请参考[文档](../../platform-engineers/system-operation/enable-addon-offline)进行完整的离线安装。
|
||||
|
||||
### 通过 UI 管理插件
|
||||
|
||||
具有插件管理权限的用户可以进入插件管理页面，进行插件启用/停用等操作。
|
||||
|
||||
|
||||
|
||||
如上图所示，在插件列表中，你可以查看到插件启用状态和其他基础信息。点击插件名称可以进入到插件详情页面，你可以查询到插件的版本列表，提供的扩展类型和介绍信息。
|
||||
|
||||
|
||||
|
||||
选择一个部署版本（默认为最新），设置需要部署的集群后，你可以点击 启用 按钮安装该插件。对于已启用的插件，如果没有应用使用该插件提供的扩展，你可以点击禁用按钮来卸载它。
|
||||
|
||||
### 编写自己的插件包
|
||||
|
||||
请参考[插件包制作文档](../../platform-engineers/addon/intro)。
|
||||
|
||||
## 作为开发者自定义和扩展
|
||||
|
||||
如果你对 KubeVela 扩展很感兴趣，你也可以了解 [CUE 体系](../../platform-engineers/cue/basic)开始自定义扩展能力，KubeVela 具备非常灵活的扩展能力。
|
||||
|
||||
非常欢迎广大开发者们阅读[开发者手册](../../contributor/overview)，了解更多的 KubeVela 细节，参与到社区的贡献中来。
|
||||
|
||||
|
|
@ -1,5 +1,384 @@
|
|||
---
|
||||
title: 分发引用的外部 Kubernetes 对象
|
||||
title: 多集群部署
|
||||
---
|
||||
|
||||
该文档已被迁移至[Kubernetes 交付制品]](../../tutorials/k8s-object#distributed-external-kubernetes-objects).
|
||||
> 开始这部分之前需要你先了解使用如何进行多集群应用的部署。你可以参考 [多集群应用交付](../../case-studies/multi-cluster) 章节了解相关基础细节.
|
||||
|
||||
你可以使用 KubeVela 引用已有的 Kubernetes 对象并将它们分发到其他位置来完成以下场景：
|
||||
|
||||
- 将管控集群中的密钥复制到子集群中。
|
||||
- 将验证集群中的工作负载部署到生产集群中。
|
||||
- 使用 Kubernetes 原生的 apiserver 作为控制面，将所有的 Kubernetes 对象存储在外部数据库中。然后通过引用这些资源，将它们下发到真正运行负载的子集群中。
|
||||
|
||||
## 在组件中引用已有的 Kubernetes 对象
|
||||
|
||||
为了在组件中使用已有的 Kubernetes 对象，你需要使用 `ref-objects` 类型的组件，并在参数中声明你想要引用的资源。例如，在下面的例子中，命名空间 `examples` 中的密钥 `image-credential-to-copy` 会被作为组件的源数据，然后你可以使用 Topology 策略来将它复制分发到杭州集群中。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ref-objects-example
|
||||
namespace: examples
|
||||
spec:
|
||||
components:
|
||||
- name: image-pull-secrets
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- resource: secret
|
||||
name: image-credential-to-copy
|
||||
policies:
|
||||
- name: topology-hangzhou-clusters
|
||||
type: topology
|
||||
properties:
|
||||
clusterLabelSelector:
|
||||
region: hangzhou
|
||||
```
|
||||
|
||||
## *ref-objects* 类型组件的细节
|
||||
|
||||
声明需要引用资源最直接的方法是使用 `resource: secret` 或 `resource: deployment` 这样的方式来确定引用资源的类型。如果 `name` 和 `labelSelector` 都没有被设置，那么应用将会在它的命名空间下尝试寻找与和组件名称一致的资源。你也可以显式地指定 `name` 和 `namespace` 来确定需要引用的资源。
|
||||
|
||||
除了 `name` 和 `namespace`，你还可以使用 `cluster` 字段让应用组件去引用子集群中的资源。你也可以使用 `labelSelector` 来筛选资源，而不是直接用 `name` 去确定目标资源。
|
||||
|
||||
在下面的样例中，应用会选择在 *hangzhou-1* 集群的 *examples* 命名空间中，所有符合声明标签要求的 Deployment。然后应用会将这些 Deployments 复制到 *hangzhou-2* 集群中。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ref-objects-duplicate-deployments
|
||||
namespace: examples
|
||||
spec:
|
||||
components:
|
||||
- name: duplicate-deployment
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- resource: deployment
|
||||
cluster: hangzhou-1
|
||||
# select all deployment in the `examples` namespace in cluster `hangzhou-1` that matches the labelSelector
|
||||
labelSelector:
|
||||
need-duplicate: "true"
|
||||
policies:
|
||||
- name: topology-hangzhou-2
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["hangzhou-2"]
|
||||
```
|
||||
|
||||
> 在一些场景下，你可能想要限制应用能够引用资源的范围，你可以通过在 KubeVela 控制器中设置 `--ref-objects-available-scope` 为 `namespace` 或者 `cluster` 来限制只在同命名空间或者同一集群内引用资源。
|
||||
|
||||
## 在 ref-objects 类型组件内使用运维特征
|
||||
|
||||
*ref-objects* 类型的组件同样也可以使用运维特征。其主体工作负载会被隐式地设置为引用资源列表中的第一个资源。所有作用在工作负载上的运维特征都会指向该资源。 如下所示的例子展示了如何为引用的 Deployment 设置副本数，并下发到 hangzhou 集群中。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ref-objects-multiple-resources
|
||||
namespace: examples
|
||||
spec:
|
||||
components:
|
||||
- name: nginx-ref-multiple-resources
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- resource: deployment
|
||||
- resource: service
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 3
|
||||
policies:
|
||||
- name: topology-hangzhou-clusters
|
||||
type: topology
|
||||
properties:
|
||||
clusterLabelSelector:
|
||||
region: hangzhou
|
||||
```
|
||||
|
||||
到此你已经完成了交付 Kubernetes 原生资源的学习！
|
||||
|
||||
## Working with Trait
|
||||
|
||||
The *ref-objects* typed component can also be used together with traits. The implicit main workload is the first referenced object and trait patch will be applied on it. The following example demonstrate how to set the replica number for the referenced deployment while deploying it in hangzhou clusters.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ref-objects-multiple-resources
|
||||
namespace: examples
|
||||
spec:
|
||||
components:
|
||||
- name: nginx-ref-multiple-resources
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- resource: deployment
|
||||
- resource: service
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 3
|
||||
policies:
|
||||
- name: topology-hangzhou-clusters
|
||||
type: topology
|
||||
properties:
|
||||
clusterLabelSelector:
|
||||
region: hangzhou
|
||||
```
|
||||
|
||||
There are several commonly used trait that could be used together with the ref-objects, particularly for Deployment.
|
||||
|
||||
### Container Image
|
||||
|
||||
The `container-image` trait can be used to change the default image settings declared in the original deployment.
|
||||
|
||||
By default, the `container-image` will replace the original image in the main container (the container uses the name of the component).
|
||||
```yaml
|
||||
traits:
|
||||
- type: container-image
|
||||
properties:
|
||||
image: busybox-1.34.0
|
||||
```
|
||||
|
||||
You can modify other containers by setting the `containerName` field.
|
||||
```yaml
|
||||
traits:
|
||||
- type: container-image
|
||||
properties:
|
||||
image: busybox-1.34.0
|
||||
containerName: sidecar-nginx
|
||||
```
|
||||
|
||||
You can also modify the ImagePullPolicy as well.
|
||||
```yaml
|
||||
traits:
|
||||
- type: container-image
|
||||
properties:
|
||||
image: busybox-1.34.0
|
||||
containerName: sidecar-nginx
|
||||
imagePullPolicy: IfNotPresent
|
||||
```
|
||||
|
||||
Multiple container patch is also available.
|
||||
```yaml
|
||||
traits:
|
||||
- type: container-image
|
||||
properties:
|
||||
containers:
|
||||
- containerName: busybox
|
||||
image: busybox-1.34.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
- containerName: sidecar-nginx
|
||||
image: nginx-1.20
|
||||
```
|
||||
|
||||
### Command
|
||||
|
||||
The `command` trait can be used to modify the original running command in deployment's pods.
|
||||
```yaml
|
||||
traits:
|
||||
- type: command
|
||||
properties:
|
||||
command: ["sleep", "8640000"]
|
||||
```
|
||||
|
||||
The above configuration can be used to patch the main container (the container that uses the name of the component). If you would like to modify another container, you could use the field `containerName`.
|
||||
```yaml
|
||||
traits:
|
||||
- type: command
|
||||
properties:
|
||||
command: ["sleep", "8640000"]
|
||||
containerName: sidecar-nginx
|
||||
```
|
||||
|
||||
If you want to replace the existing args in the container, instead of the command, use the `args` parameter.
|
||||
```yaml
|
||||
traits:
|
||||
- type: command
|
||||
properties:
|
||||
args: ["86400"]
|
||||
```
|
||||
|
||||
If you want to append/delete args to the existing args, use the `addArgs`/`delArgs` parameter. This can be useful if you have lots of args to be managed.
|
||||
```yaml
|
||||
traits:
|
||||
- type: command
|
||||
properties:
|
||||
addArgs: ["86400"]
|
||||
```
|
||||
```yaml
|
||||
traits:
|
||||
- type: command
|
||||
properties:
|
||||
delArgs: ["86400"]
|
||||
```
|
||||
|
||||
You can also configure commands in multiple containers.
|
||||
```yaml
|
||||
traits:
|
||||
- type: command
|
||||
properties:
|
||||
containers:
|
||||
- containerName: busybox
|
||||
command: ["sleep", "8640000"]
|
||||
- containerName: sidecar-nginx
|
||||
args: ["-q"]
|
||||
```
|
||||
|
||||
### Environment Variable
|
||||
|
||||
With the trait `env`, you can easily manipulate the declared environment variables.
|
||||
|
||||
For example, the following usage shows how to set multiple environment variables in the main container (the container uses the component's name). If any environment variable does not exist, it will be added. If exists, it will be updated.
|
||||
```yaml
|
||||
traits:
|
||||
- type: env
|
||||
properties:
|
||||
env:
|
||||
key_first: value_first
|
||||
key_second: value_second
|
||||
```
|
||||
|
||||
You can remove existing environment variables by setting the `unset` field.
|
||||
```yaml
|
||||
traits:
|
||||
- type: env
|
||||
properties:
|
||||
unset: ["key_existing_first", "key_existing_second"]
|
||||
```
|
||||
|
||||
If you would like to clear all the existing environment variables first, and then add new variables, use `replace: true`.
|
||||
```yaml
|
||||
traits:
|
||||
- type: env
|
||||
properties:
|
||||
env:
|
||||
key_first: value_first
|
||||
key_second: value_second
|
||||
replace: true
|
||||
```
|
||||
|
||||
If you want to modify the environment variable in other containers, use the `containerName` field.
|
||||
```yaml
|
||||
traits:
|
||||
- type: env
|
||||
properties:
|
||||
env:
|
||||
key_first: value_first
|
||||
key_second: value_second
|
||||
containerName: sidecar-nginx
|
||||
```
|
||||
|
||||
You can set environment variables in multiple containers as well.
|
||||
```yaml
|
||||
traits:
|
||||
- type: env
|
||||
properties:
|
||||
containers:
|
||||
- containerName: busybox
|
||||
env:
|
||||
key_for_busybox_first: value_first
|
||||
key_for_busybox_second: value_second
|
||||
- containerName: sidecar-nginx
|
||||
env:
|
||||
key_for_nginx_first: value_first
|
||||
key_for_nginx_second: value_second
|
||||
```
|
||||
|
||||
### Labels & Annotations
|
||||
|
||||
To add/update/remove labels or annotations for the workload (like Kubernetes Deployment), use the `labels` or `annotations` trait.
|
||||
|
||||
```yaml
|
||||
traits:
|
||||
# the `labels` trait will add/delete label key/value pair to the
|
||||
# labels of the workload and the template inside the spec of the workload (if exists)
|
||||
# 1. if original labels contains the key, value will be overridden
|
||||
# 2. if original labels do not contain the key, value will be added
|
||||
# 3. if original labels contains the key and the value is null, the key will be removed
|
||||
- type: labels
|
||||
properties:
|
||||
added-label-key: added-label-value
|
||||
label-key: modified-label-value
|
||||
to-delete-label-key: null
|
||||
```
|
||||
|
||||
```yaml
|
||||
traits:
|
||||
# the `annotations` trait will add/delete annotation key/value pair to the
|
||||
# labels of the workload and the template inside the spec of the workload (if exists)
|
||||
# 1. if original annotations contains the key, value will be overridden
|
||||
# 2. if original annotations do not contain the key, value will be added
|
||||
# 3. if original annotations contains the key and the value is null, the key will be removed
|
||||
- type: annotations
|
||||
properties:
|
||||
added-annotation-key: added-annotation-value
|
||||
annotation-key: modified-annotation-value
|
||||
to-delete-annotation-key: null
|
||||
```
|
||||
|
||||
### JSON Patch & JSON Merge Patch
|
||||
|
||||
Except for the above trait, a more powerful but more complex way to modify the original resources is to use the `json-patch` or `json-merge-patch` trait. They follow the [RFC 6902](https://datatracker.ietf.org/doc/html/rfc6902) and [RFC 7386](https://datatracker.ietf.org/doc/html/rfc7386) respectively. Usage examples are shown below.
|
||||
|
||||
```yaml
|
||||
traits:
|
||||
# the json patch can be used to add, replace and delete fields
|
||||
# the following part will
|
||||
# 1. add `deploy-label-key` to deployment labels
|
||||
# 2. set deployment replicas to 3
|
||||
# 3. set `pod-label-key` to `pod-label-modified-value` in pod labels
|
||||
# 4. delete `to-delete-label-key` in pod labels
|
||||
# 5. add sidecar container for pod
|
||||
- type: json-patch
|
||||
properties:
|
||||
operations:
|
||||
- op: add
|
||||
path: "/spec/replicas"
|
||||
value: 3
|
||||
- op: replace
|
||||
path: "/spec/template/metadata/labels/pod-label-key"
|
||||
value: pod-label-modified-value
|
||||
- op: remove
|
||||
path: "/spec/template/metadata/labels/to-delete-label-key"
|
||||
- op: add
|
||||
path: "/spec/template/spec/containers/1"
|
||||
value:
|
||||
name: busybox-sidecar
|
||||
image: busybox:1.34
|
||||
command: ["sleep", "864000"]
|
||||
```
|
||||
|
||||
```yaml
|
||||
traits:
|
||||
# the json merge patch can be used to add, replace and delete fields
|
||||
# the following part will
|
||||
# 1. add `deploy-label-key` to deployment labels
|
||||
# 2. set deployment replicas to 3
|
||||
# 3. set `pod-label-key` to `pod-label-modified-value` in pod labels
|
||||
# 4. delete `to-delete-label-key` in pod labels
|
||||
# 5. reset `containers` for pod
|
||||
- type: json-merge-patch
|
||||
properties:
|
||||
metadata:
|
||||
labels:
|
||||
deploy-label-key: deploy-label-added-value
|
||||
spec:
|
||||
replicas: 3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
pod-label-key: pod-label-modified-value
|
||||
to-delete-label-key: null
|
||||
spec:
|
||||
containers:
|
||||
- name: busybox-new
|
||||
image: busybox:1.34
|
||||
command: ["sleep", "864000"]
|
||||
```
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: 系统架构
|
|||
|
||||
KubeVela 的整体架构如下所示：
|
||||
|
||||
|
||||
|
||||
|
||||
## KubeVela 是一个控制平面系统
|
||||
|
||||
|
|
@ -38,9 +38,8 @@ KubeVela 本身是一个的应用交付与管理控制平面，它架在 Kuberne
|
|||
如果要详细学习 KubeVela 的可编程文档，欢迎查看文档网站中 [自定义扩展](../platform-engineers/oam/oam-model) 部分。
|
||||
|
||||
|
||||
## 谁应该使用 KubeVela？
|
||||
## 谁会使用 KubeVela？
|
||||
|
||||
|
||||
|
||||
- 云原生应用平台的构建者、PaaS、Serverless 平台工程师、基础设施平台管理员：
|
||||
- KubeVela 是一个普适的、高可扩展的应用交付引擎与内核，它以极简的架构实现了原生 Kubernetes 多集群控制平面的能力，能够将 OAM 应用引擎直接植入企业已有的 PaaS 平台之中并不破坏已有的能力，从而实现标准化应用交付。
|
||||
|
|
@ -49,7 +48,7 @@ KubeVela 本身是一个的应用交付与管理控制平面，它架在 Kuberne
|
|||
- 云原生时代的应用研发、运维人员、DevOps 工程师：
|
||||
- VelaUX 是一个基于 Vela Addon 机制构建的扩展能力集，安装这个插件后，你就拥有了一个开箱即用的现代化持续交付（CD）和应用管理平台。
|
||||
|
||||
## OAM、KubeVela 和 VelaUX 是什么关系？
|
||||
## 总结
|
||||
|
||||
- [OAM(Open Application Model)](https://github.com/oam-dev/spec) 是 KubeVela 背后的模型，它提供了一组平台无关的最佳实践和方法论，能够为不同的公司和厂商构建应用平台提供理论指导，共同提供标准化应用支撑，让应用可以在不同的平台顺畅的运行、平滑的迁移。当前 OAM 模型的演进主要基于 KubeVela 的实践。
|
||||
- KubeVela 是基于 Kubernetes 的混合云应用交付和管理控制平面，它以 [CRD 控制器](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 的形式运行，可以很轻量的安装到企业现有的 PaaS 体系中，并带来 OAM 的标准化模型和基于模型高可扩展功能的丰富社区插件。
|
||||
|
|
@ -58,7 +57,6 @@ KubeVela 本身是一个的应用交付与管理控制平面，它架在 Kuberne
|
|||
KubeVela 团队将主要聚焦在核心控制器层面，面向所有用户提供可靠、易用的核心框架和能力。另一方面，我们通过构建 VelaUX 插件为中小型企业提供开箱即用的应用交付和管理功能，不仅可以扩大 OAM 模型的受众，也能吃自己的狗粮打磨 KubeVela 核心框架的可扩展性和插件体系。我们将在打磨核心控制器的同时，持续提供开箱即用的插件能力，并与开源社区的优质项目做更多更好的集成。
|
||||
|
||||
|
||||
|
||||
## 下一步
|
||||
|
||||
- 查看 [快速开始](../quick-start)，了解更多使用场景和最佳实践。
|
||||
- 查看 [用户手册](../tutorials/webservice)，了解更多使用场景和最佳实践。
|
||||
|
|
|
|||
|
|
@ -2,32 +2,31 @@
|
|||
title: 模块定义
|
||||
---
|
||||
|
||||
Definition are the basic building block of the KubeVela platform. A definition encapsulates an arbitrarily complex automation as a lego style module that can be used to compose an Application, then safely shared, and repeatably executed by any KubeVela engine.
|
||||
模块定义是组成 KubeVela 平台的基本扩展能力单元，一个模块定义就像乐高积木，它将底层的能力封装成抽象的模块，使得这些能力可以被最终用户快速理解、使用并和其他能力组装、衔接，最终构成一个具有丰富功能的业务应用。模块定义最大的优势是可以被**分发**和**共享**，在不同的业务应用中重复使用，在基于 KubeVela 的不同平台上均能执行。
|
||||
|
||||
There're four types of Definition, they're `ComponentDefinition`, `TraitDefinition`, `PolicyDefinition` and `WorkflowStepDefinition`, corresponding to the application concepts.
|
||||
目前 KubeVela 一共有四种不同类型的模块定义，分别是组件定义（ComponentDefinition）、运维特征定义（TraitDefinition）、策略定义（PolicyDefinition）以及工作流步骤定义（WorkflowStepDefinition），对应了构成[应用](./core-concept)的四个基本概念。
|
||||
|
||||
## 模块定义的来源
|
||||
## 如何获取现成的模块定义？
|
||||
|
||||
There're two sources of definitions:
|
||||
除了自己编写模块定义以外，你可以通过以下两大途径获得社区已有的模块定义：
|
||||
|
||||
* Built-in definitions will be installed along with KubeVela helm chart. You can refer to the following links to learn more about built-in definitions.
|
||||
- [Component Definition](../end-user/components/references)
|
||||
- [Trait Definition](../end-user/traits/references)
|
||||
- [Policy Definition](../end-user/policies/references)
|
||||
- [Workflow Step Definition](../end-user/workflow/built-in-workflow-defs)
|
||||
* Installation of addons will install definitions if there're new capabilities contained.
|
||||
- [Addon registry](../reference/addons/overview) contains a large catalog of addon which are maintained and verified by the KubeVela team.
|
||||
* KubeVela 安装时自动就会安装内置的模块定义，你可以在下面这些参考文档中查看有哪些现成的能力：
|
||||
- [组件定义列表](../end-user/components/references)
|
||||
- [运维特征定义列表](../end-user/traits/references)
|
||||
- [策略定义列表](../end-user/policies/references)
|
||||
- [工作流步骤定义列表](../end-user/workflow/built-in-workflow-defs)
|
||||
* [扩展插件列表](../reference/addons/overview)，作为 KubeVela 的扩展，每一个插件都包含一组模块定义以及支撑其功能的 CRD Controller。
|
||||
- 社区有一个[插件注册中心](https://github.com/kubevela/catalog)包含了大量开箱即用的插件，由 KubeVela 核心维护者负责认证和维护。
|
||||
|
||||
## Lifecycle of a Definition
|
||||
## 模块定义的生命周期
|
||||
|
||||
A definition's lifecycle usually has 3 stages:
|
||||
一个模块定义通常有三个生命周期阶段：
|
||||
|
||||
### Discovery
|
||||
### 发现
|
||||
|
||||
When definitions installed in the system, they can be discovered by end user immediately.
|
||||
|
||||
* Check the list:
|
||||
当模块定义被安装到 KubeVela 控制平面以后，最终用户就可以立即发现和查看它们。
|
||||
|
||||
* 查看模块定义列表
|
||||
```
|
||||
$ vela def list
|
||||
NAME TYPE NAMESPACE DESCRIPTION
|
||||
|
|
@ -41,7 +40,7 @@ notification WorkflowStepDefinition vela-system Send message to
|
|||
...snip...
|
||||
```
|
||||
|
||||
* Show the details:
|
||||
* 查看模块定义的参数
|
||||
```
|
||||
$ vela show webservice
|
||||
# Properties
|
||||
|
|
@ -58,25 +57,31 @@ $ vela show webservice
|
|||
...snip...
|
||||
```
|
||||
|
||||
You can also view the details with a browser, the following command will launch a server and invoke your browser automatically:
|
||||
你也可以通过命令行打开一个网页查看这些参数：
|
||||
|
||||
```
|
||||
vela show webservice --web
|
||||
```
|
||||
|
||||
* Discover in UI console
|
||||
* 在 KubeVela 的 UI 控制台（需安装 velaux 插件）也可以看到
|
||||
|
||||
|
||||
|
||||
These definitions can also be discovered by the UI console, the more important thing is they can be displayed very well with [ui schema](../reference/ui-schema) defined.
|
||||
模块定义在 UI 控制台上可以比较方便的查看，更重要的是会有一个比较好的用户体验，你还可以[自定义 UI 展示](../reference/ui-schema)来优化 UI 控制台上模块定义的参数展示。
|
||||
|
||||
### Use
|
||||
### 使用
|
||||
|
||||
If you're a fan of our UI console, the usage of definition is very straight forward, just click along with the creation of the deployment process.
|
||||
在 KubeVela 的 UI 控制台上使用模块定义是非常自然的，整个流程紧紧围绕应用部署计划展开，你只要跟着界面操作指引一步步点击即可使用。
|
||||
|
||||
|
||||
|
||||
Finally, the UI console will compose the whole deployment plan in the format of OAM like below, then KubeVela controller will take care of the rest things:
|
||||
分为如下几步：
|
||||
|
||||
1. 创建应用选择组件类型，这个过程就是选择使用某个组件定义。
|
||||
2. 填写组件的参数则会根据组件定义的不同出现不同的待填写参数。
|
||||
3. 运维特征、策略、工作流步骤的使用也是如此，分别在不同的应用部署计划业务流程中体现。
|
||||
|
||||
最终 UI 控制台会组装成一个符合 OAM 模型定义的完整应用部署计划，然后 KubeVela 控制器会自动化处理剩下的事情：
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -130,19 +135,21 @@ spec:
|
|||
policies: ["target-prod", "deploy-ha"]
|
||||
```
|
||||
|
||||
Use the definition in command works the same, you can compose the application yaml manually and use `vela` command line tool to deploy.
|
||||
使用 KubeVela 命令行工具来使用模块定义也是如此，只要编写上述 Application 对象的 YAML 文件即可，可以使用 `vela` 命令如下：
|
||||
|
||||
```
|
||||
vela up -f https://kubevela.net/example/applications/first-app.yaml
|
||||
```
|
||||
|
||||
### Customize
|
||||
Application 也是一种 Kubernetes 的 CRD，你可以通过 `kubectl` 工具，或者直接调用 Kubernetes API 集成 KubeVela 功能。
|
||||
|
||||
> **⚠️ In most cases, you don't need to customize any definitions unless you're going to extend the capability of KubeVela. Before that, you should check the built-in definitions and addons to confirm if they can fit your needs.**
|
||||
### 自定义
|
||||
|
||||
A new definition is built in a declarative template in [CUE configuration language](https://cuelang.org/). If you're not familiar with CUE, you can refer to [CUE Basic](../platform-engineers/cue/basic) for some knowledge.
|
||||
> **⚠️ 请注意，在多数情况下，你不需要编写自定义模块，除非你的目的是扩展 KubeVela 的系统能力。在此之前，我们建议你先查看 KubeVela 内置的模块定义以及扩展插件，可能它们已经足够满足你的需求。**
|
||||
|
||||
A definition describes the module's inputs, outputs, operations, and the wiring between them. Here is an example of a simple component definition:
|
||||
KubeVela 使用 [CUE 配置语言](https://cuelang.org/)来编写自定义模块，如果你对 CUE 语言还不熟悉也不必担心，可以查看 [CUE 入门指南](../platform-engineers/cue/basic)，花 15 分钟即可了解基本的实用操作。
|
||||
|
||||
一个模块定义包含输入、输出、操作以及这三者之间的衔接关系，一个简单的组件模块定义如下所示：
|
||||
|
||||
```
|
||||
webserver: {
|
||||
|
|
@ -168,9 +175,8 @@ template: {
|
|||
}
|
||||
```
|
||||
|
||||
The `type` defines what kind of definition it is, the `parameter` defines the inputs, while the `output` section defines the outputs.
|
||||
You can refer to detail docs about [how to manage definition](../platform-engineers/cue/definition-edit) or learn the [definition protocol](../platform-engineers/oam/x-definition).
|
||||
`type` 字段定义了这个模块是哪种类型（组件、运维特征、策略或者工作流步骤）， `parameter` 定义了模块的输入，`output` 定义了模块的输出。还有一些高级的操作你可以通过了解[如何管理、编写模块定义](../platform-engineers/cue/definition-edit)以及[模块定义与 Kubernetes 的交互协议](../platform-engineers/oam/x-definition) 等章节文档了解更多细节。
|
||||
|
||||
## Next Step
|
||||
## 下一步
|
||||
|
||||
- View [Architecture](./architecture) to learn the overall architecture of KubeVela.
|
||||
- 查看 KubeVela [项目架构](./architecture)文档了解全局的架构。
|
||||
|
|
|
|||
|
|
@ -2,141 +2,4 @@
|
|||
title: 插件管理
|
||||
---
|
||||
|
||||
你可以通过安装 KubeVela 的插件（Addon）获取更多的系统功能。
|
||||
|
||||
## 通过 UI 管理插件
|
||||
|
||||
具有插件管理权限的用户可以进入插件管理页面，进行插件启用/停用等操作。
|
||||
|
||||
|
||||
|
||||
如上图所示，在插件列表中，你可以查看到插件启用状态和其他基础信息。点击插件名称可以进入到插件详情页面，你可以查询到插件的版本列表，提供的扩展类型和介绍信息。
|
||||
|
||||
|
||||
|
||||
选择一个部署版本（默认为最新），设置需要部署的集群后，你可以点击 启用 按钮安装该插件。对于已启用的插件，如果没有应用使用该插件提供的扩展，你可以点击禁用按钮来卸载它。
|
||||
|
||||
## 通过 CLI 管理插件
|
||||
|
||||
### 查看所有插件
|
||||
|
||||
KubeVela 官方团队维护了一个默认的插件仓库 (https://addons.kubevela.net) ，默认情况下会从这个仓库实时发现。
|
||||
|
||||
|
||||
```shell
|
||||
$ vela addon list
|
||||
NAME REGISTRY DESCRIPTION AVAILABLE-VERSIONS STATUS
|
||||
ocm-gateway-manager-addon KubeVela ocm-gateway-manager-addon is the OCM addon automates the cluster-gateway apiserver. [1.3.2, 1.3.0, 1.1.11] disabled
|
||||
rollout KubeVela Provides basic batch publishing capability. [1.3.0, 1.2.4, 1.2.3] disabled
|
||||
terraform-baidu KubeVela Kubernetes Terraform Controller Provider for Baidu Cloud [1.0.1, 1.0.0] disabled
|
||||
terraform-tencent KubeVela Kubernetes Terraform Controller Provider for Tencent Cloud [1.0.1, 1.0.0] disabled
|
||||
model-serving KubeVela Enable serving for models [1.0.0] disabled
|
||||
model-training KubeVela Enable training for models [1.0.0] disabled
|
||||
terraform KubeVela Terraform Controller is a Kubernetes Controller for Terraform. [1.0.6] disabled
|
||||
terraform-aws KubeVela Kubernetes Terraform Controller for AWS [1.0.1, 1.0.0] disabled
|
||||
terraform-azure KubeVela Kubernetes Terraform Controller for Azure [1.0.1, 1.0.0] disabled
|
||||
terraform-gcp KubeVela Kubernetes Terraform Controller Provider for Google Cloud Platform [1.0.1, 1.0.0] disabled
|
||||
dex KubeVela Enable dex for login [0.6.5] disabled
|
||||
ocm-hub-control-plane KubeVela ocm-hub-control-plane can install OCM hub control plane to the central cluster. [0.6.0] disabled
|
||||
terraform-ucloud KubeVela Kubernetes Terraform Controller Provider for UCloud [1.0.1, 1.0.0] disabled
|
||||
fluxcd KubeVela Extended workload to do continuous and progressive delivery [1.1.0, 1.0.0] disabled
|
||||
velaux KubeVela KubeVela User Experience (UX). An extensible, application-oriented delivery and management Dashboard. [v1.3.0, v1.3.0-beta.2, 1.2.4] enabled (v1.3.0)
|
||||
terraform-alibaba KubeVela Kubernetes Terraform Controller for Alibaba Cloud [1.0.2, 1.0.1] disabled
|
||||
```
|
||||
|
||||
### 安装插件
|
||||
|
||||
```
|
||||
$ vela addon enable fluxcd
|
||||
I0111 21:45:24.553174 89345 apply.go:106] "creating object" name="addon-fluxcd" resource="core.oam.dev/v1beta1, Kind=Application"
|
||||
I0111 21:45:25.258914 89345 apply.go:106] "creating object" name="helm" resource="core.oam.dev/v1beta1, Kind=ComponentDefinition"
|
||||
I0111 21:45:25.342731 89345 apply.go:106] "creating object" name="kustomize-json-patch" resource="core.oam.dev/v1beta1, Kind=TraitDefinition"
|
||||
I0111 21:45:25.382201 89345 apply.go:106] "creating object" name="kustomize-patch" resource="core.oam.dev/v1beta1, Kind=TraitDefinition"
|
||||
I0111 21:45:25.411723 89345 apply.go:106] "creating object" name="kustomize" resource="core.oam.dev/v1beta1, Kind=ComponentDefinition"
|
||||
I0111 21:45:25.625815 89345 apply.go:106] "creating object" name="kustomize-strategy-merge" resource="core.oam.dev/v1beta1, Kind=TraitDefinition"
|
||||
I0111 21:45:25.660129 89345 apply.go:106] "creating object" name="component-uischema-helm" resource="/v1, Kind=ConfigMap"
|
||||
Addon: fluxcd enabled Successfully.
|
||||
```
|
||||
|
||||
#### 安装特定版本的插件
|
||||
|
||||
你可以通过通过设置 `--version` 启动参数，来指定安装插件的某个特定版本。例如：
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd --version=1.0.0
|
||||
```
|
||||
|
||||
如果不指定该参数，默认会安装此插件的最新版本。
|
||||
|
||||
启用一个插件时，默认会在所有子集群中安装该插件，你也可以通过设置 `--cluster` 启动参数选择安装在某些集群当中。例如：
|
||||
|
||||
```shell
|
||||
vela addon enable <addon-name> --clusters={cluster1,cluster2}
|
||||
```
|
||||
|
||||
安装完成后，插件中的功能会以组件，运维特征，工作流步骤等形式呈现，你可以通过 `vela component`，`vela trait` 等命令查看新增的能力，也可以在[插件的参考文档](../../../reference/addons/overview)中查看每个官方插件对应的能力.
|
||||
|
||||
### 删除/卸载已安装的插件
|
||||
|
||||
> 删除前请确认插件对应的能力没有被任何应用使用。
|
||||
|
||||
```
|
||||
$ vela addon disable fluxcd
|
||||
Successfully disable addon:fluxcd
|
||||
```
|
||||
|
||||
### 查看插件的下载仓库
|
||||
|
||||
```
|
||||
$ vela addon registry list
|
||||
Name Type URL
|
||||
KubeVela helm https://addons.kubevela.net
|
||||
```
|
||||
|
||||
KubeVela 社区在 Github 上维护了一个官方的[正式插件包仓库](https://github.com/kubevela/catalog/tree/master/addons) 和一个[试验阶段插件包仓库](https://github.com/kubevela/catalog/tree/master/experimental) 。你在相应的仓库中找到插件包的定义文件。
|
||||
|
||||
同时这些文件会被同步到 [对象存储](https://addons.kubevela.net) 当中，以加快下载速度。
|
||||
|
||||
### 添加插件包仓库
|
||||
|
||||
你可以添加自己的插件包仓库，目前支持 OSS 和 Github 两种仓库类型。
|
||||
|
||||
```
|
||||
$ vela addon registry add experimental --type OSS --endpoint=https://addons.kubevela.net --path=experimental/
|
||||
Successfully add an addon registry experimental
|
||||
```
|
||||
|
||||
### 删除一个插件包仓库
|
||||
|
||||
```
|
||||
$ vela addon registry delete experimental
|
||||
Successfully delete an addon registry experimental
|
||||
```
|
||||
|
||||
### 多集群环境中启用插件包
|
||||
|
||||
如果你的环境中添加了若干个子集群，启用插件包时会默认在管控集群和所有子集群中安装此插件包。但如果子集群在某个插件包启用之后加入环境当中，则需要通过升级操作在新加入集群中安装此插件包。如下所示
|
||||
|
||||
```
|
||||
$ vela addon upgrade velaux
|
||||
Addon:
|
||||
enabled Successfully
|
||||
```
|
||||
|
||||
### 离线安装插件包
|
||||
|
||||
如果因为某些原因，你的环境无法通过访问插件包仓库，你可以通过指定本地的插件包目录来进行离线安装。如下所示：
|
||||
|
||||
```
|
||||
$ ls
|
||||
README.md fluxcd ocm-cluster-manager terraform terraform-alibaba terraform-aws terraform-azure velaux
|
||||
|
||||
$ vela addon enable velaux/
|
||||
Addon: velaux enabled Successfully
|
||||
```
|
||||
|
||||
需要注意的是，在安装插件过程当中，仍可能需要从网络中拉取镜像或者 helm chart，如果你的网络环境同样无法访问这些地址，请参考[文档](../../../platform-engineers/system-operation/enable-addon-offline)进行完整的离线安装。
|
||||
|
||||
## 编写自己的插件包
|
||||
|
||||
请参考[插件包制作文档](../../../platform-engineers/addon/intro)。
|
||||
文档已迁移到[这里](../../../end-user/components/more)。
|
||||
|
|
|
|||
|
|
@ -1,8 +1,10 @@
|
|||
---
|
||||
title: 创建应用
|
||||
title: 应用生命周期管理
|
||||
description: 本文介绍在 KubeVela Dashboard 中创建应用的操作方法。
|
||||
---
|
||||
|
||||
## 创建应用
|
||||
|
||||
### 判断你的应用类别
|
||||
|
||||
我们大致把应用分为三种类型，普通业务应用、中间件（第三方开源应用）、云服务。对于普通业务应用，我们建议你采用 `webservice` 部署类型或你的自定义类型。对于中间件或第三方复杂应用建议直接采用 `helm` 部署类型，对于比较简单且直接提供了 Docker 镜像的第三方开源应用，比如 wordpress,也可以直接采用 `webservice` 类型。
|
||||
|
|
@ -21,6 +23,155 @@ description: 本文介绍在 KubeVela Dashboard 中创建应用的操作方法
|
|||
|
||||
根据提示完成部署参数的设置后，点击提交按钮即可完成应用创建。成功创建后进入应用管理页面，应用处于未部署状态。
|
||||
|
||||
### 下一步
|
||||
## 绑定应用到环境
|
||||
|
||||
* [绑定应用到环境](./bind-new-environment).
|
||||
应用在创建完成后，需要绑定到 1 个或多个环境才能正式发布。
|
||||
|
||||
你可以绑定到开发环境做测试，然后在测试完成后绑定到生产环境做发布，不同的环境之间彼此隔离、互不影响。
|
||||
|
||||
创建完成应用后，在应用管理页面点击 `Bind Environment`就会出现如下弹窗：
|
||||
|
||||
|
||||
|
||||
在弹窗中选择需要发布的环境。如果环境还没创建，可点击下方的 `Create new environment` 创建新的环境。
|
||||
|
||||
点击确认即完成绑定，`Baseline Config` 右侧环境选项区域出现新的环境，且在工作流管理页面将自动生成新环境的部署工作流。切换到新环境视图下点击 `Deploy` 即可将应用发布到该环境。
|
||||
|
||||
## 部署应用
|
||||
|
||||
应用创建完成后，需要分别执行环境对应的工作流完成环境的部署，每个环节的对应工作流会自动生成。
|
||||
|
||||
### 首次部署
|
||||
|
||||
从应用列表点击指定应用进入应用详细页面，在 `Baseline Config` 右侧即为所有已绑定的环境列表。选择你需要部署的环境，点击环境名称进入环境页面。
|
||||
|
||||
|
||||
|
||||
环境处于未部署状态时将显示部署按钮，点击按钮即可开始执行当前环境的部署工作流。工作流执行状态显示在页面的右上方。如果你设置了审核的步骤，到达该步骤时页面中将弹出审核窗口。
|
||||
|
||||
|
||||
|
||||
如果部署步骤出现故障，该步骤显示为红色，鼠标移动到该步骤上将显示故障原因。
|
||||
|
||||
|
||||
|
||||
### 更新
|
||||
|
||||
应用详情页面的右上方有一个常驻的 `Deploy` 按钮，点击该按钮执行默认工作流。按钮右边三点按钮为选择不同的环境工作流，鼠标移动到其上方即可显示多个工作流选项。
|
||||
|
||||
|
||||
|
||||
更新部署可以在任意状态下进行，选择执行某一个流水线后，将使用最新的应用配置进行部署。如果该环境正在执行部署，UI 将提示你是否强制进行新的部署。
|
||||
|
||||
## 查看应用实例
|
||||
|
||||
查看应用运行实例信息是掌握应用运行状态的直接方式。
|
||||
|
||||
|
||||
|
||||
如上图所示，应用的运行实例页面处在应用环境视图下。切换不同的环境即可查询不同环境下部署的实例。
|
||||
|
||||
默认情况下，实例列表显示该应用在当前环境下的所有实例。通过实例列表上方的交付目标筛选，可以查询不同交付目标的实例列表。在实例列表中显示版本、状态等信息。
|
||||
|
||||
对于交付的 Kubernetes 集群的应用，用户可以点击实例行前方的 + 号展开一个实例的详情，即 Pod 详情，包括了容器状态及资源消耗情况，如果实例的拉起故障，可以从事件列表中查看到详细信息。
|
||||
|
||||
对于交付的 云服务 应用，用户可通过点击实例名称跳转到云服务商管理页面。
|
||||
|
||||
|
||||
|
||||
## 查看日志
|
||||
|
||||
### 通过 UI 查看应用日志
|
||||
|
||||
|
||||
|
||||
如上图所示，交付到 Kubernetes 集群的应用支持查询容器运行日志，切换到指定环境视图下，选择日志页面，即可通过组件/实例/容器的筛选查看对应的运行日志。
|
||||
|
||||
日志查询页面默认为每 5 秒自动刷新，查看最新的日志。若你的应用日志中没有时间信息，可点击 `Show timestamps` 展示日志记录时间。
|
||||
|
||||
### 通过 CLI 查看应用日志
|
||||
|
||||
```bash
|
||||
$ vela logs <app_name> -n <namespace>
|
||||
```
|
||||
|
||||
使用实际的应用名称，命名空间参数执行上述命令，在交互中选择你需要查询的工作负载即可查询应用日志。
|
||||
|
||||
## 访问应用
|
||||
|
||||
### 设置应用访问方式
|
||||
|
||||
交付的 Kubernetes 集群的应用需要设置访问方式即可生成访问地址，常见支持的方式如下：
|
||||
|
||||
1. 设置 Service 的暴露类型，比如 `LoadBalancer` 和 `NodePort`。适用于所有应用协议。
|
||||
2. 设置 Ingress 策略，仅适用于 HTTP/HTTPs 协议。
|
||||
|
||||
#### `webservice` 类型的应用
|
||||
|
||||
在部署参数中可以修改 `ExposeType` 字段参数来设置其暴露方式，同时在 `Service Ports` 中设置应用的监听端口，并将 `Expose` 设置为 True。
|
||||
|
||||
|
||||
|
||||
如果你的集群中存在 `Ingress Controller`，在应用 `Baseline Config` 页面中，新增 `gateway` 运维特征来设置访问域名。
|
||||
|
||||
|
||||
|
||||
如上图所示，在 `Domain` 中配置你的域名，注意请将该域名 DNS 解析到目标集群的网关 IP 之上。在 `Http` 模块下配置路由规则，默认你需要设置 `/`:`80`，根据你的应用监听端口设置。
|
||||
|
||||
其他部署类型的应用，一般存在对应的部署参数设置选项，根据部署参数设置即可。
|
||||
|
||||
### 获取访问地址
|
||||
|
||||
设置完应用访问方式后，执行应用部署，然后切换到环境视图下即可看到 `Service Endpoint` 按钮，鼠标移动到上方即可显示该应用的访问地址。
|
||||
|
||||
|
||||
|
||||
## 查看应用部署的资源列表
|
||||
|
||||
如果你希望查询应用在各集群部署了哪些资源，可通过下述操作方式查询。
|
||||
|
||||
## 通过 UI 查询
|
||||
|
||||
进入应用部署环境视图，默认进入状态展示页面，在该页面中即可查询到应用实际分发的资源列表，如果应用在更新过程中，资源列表会包括历史和当前版本。
|
||||
|
||||
|
||||
|
||||
在该页面中同时展示了组件状态和整体的交付状态。
|
||||
|
||||
## 通过 CLI 查询
|
||||
|
||||
```bash
|
||||
$ vela status <app_name> -n <namespace> --tree
|
||||
```
|
||||
|
||||
基于如上命令可以查询应用部署的资源清单。
|
||||
|
||||
## 查看应用部署版本
|
||||
|
||||
应用每执行一次部署即可生成一个版本，通过应用 `Baseline Config` 视图下的 `Revisions` 页面展示应用的历史部署版本。
|
||||
|
||||
|
||||
|
||||
通过 Webhook Trigger 触发部署的版本，如果携带了代码信息，版本号可与代码 Commit 信息进行关联。
|
||||
|
||||
## 回收应用部署的环境
|
||||
|
||||
当你需要将应用在某个环境的部署资源回收，即关闭应用时，参考下述操作。
|
||||
|
||||
|
||||
|
||||
如上图所示，完成部署的环境视图下回出现 `Recycle` 按钮，点击该按钮确认后即可将该环境部署的资源进行回收删除。
|
||||
|
||||
> 请注意，回收意味着对应的资源将删除，对于需要有状态存储的应用，该操作会导致数据丢失。纯无状态应用可通过重新部署后恢复。
|
||||
|
||||
### 删除应用和环境的绑定关系
|
||||
|
||||
应用如果成功从该环境回收后，操作区域将存在 `Delete` 按钮，点击该按钮即可删除应用与环境的绑定关系。
|
||||
|
||||
## 删除应用
|
||||
|
||||
应用需要完成所有环境的资源回收，完成后即可进行删除操作。
|
||||
|
||||
|
||||
|
||||
如上图所示，回到应用列表页面，鼠标移动到应用名称右侧的操作图标上，点击 Remove 选项即可完成应用的删除操作。
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ description: 指定用户将创建的应用部署到指定的环境。
|
|||
|
||||
|
||||
|
||||
### 更新部署
|
||||
### 更新
|
||||
|
||||
应用详情页面的右上方有一个常驻的 `Deploy` 按钮，点击该按钮执行默认工作流。按钮右边三点按钮为选择不同的环境工作流，鼠标移动到其上方即可显示多个工作流选项。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,20 @@
|
|||
---
|
||||
title: 使用触发器对接 CI 自动部署
|
||||
title: 触发器
|
||||
description: 使用触发器对接 CI 自动部署
|
||||
---
|
||||
|
||||
You can use triggers from [VelaUX addon](../../../reference/addons/velaux) to integrate with different CI systems, the architecture and supported platforms are described in the following picture, they're:
|
||||
|
||||
- [Custom](#custom-trigger), refer to [Jenkins CI](../../../tutorials/jenkins) guide for a real world use case
|
||||
- [ACR](#ACR-trigger)
|
||||
- [Harbor](#Harbor-trigger), refer to [Harbor Integration](../../../tutorials/trigger) guide for a real world use case
|
||||
- [DockerHub](#DockerHub-trigger)
|
||||
- [JFrog](#JFrog-trigger)
|
||||
|
||||
|
||||
|
||||
## 如何使用
|
||||
|
||||
应用在创建完成后，会自动创建一个默认触发器，你可以删除或者创建新的触发器。
|
||||
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 287 KiB |
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Kubernetes 原生资源
|
||||
title: 部署 Kubernetes 对象
|
||||
description: 对 Kubernetes 有一定了解的用户，参考本文档学习利用 KubeVela 的能力将已经定义好的 Kubernetes 资源便捷交付到多个集群。
|
||||
---
|
||||
|
||||
|
|
@ -12,13 +12,6 @@ KubeVela 支持面向应用组织多个 Kubernetes 资源进行交付，常见
|
|||
3. 初步了解多环境/多集群的应用发布。
|
||||
4. 应用发布过程控制：回退、终止和继续。
|
||||
|
||||
不仅如此，你还可以使用 KubeVela 引用已有的 Kubernetes 对象并将它们分发到其他位置来完成以下场景：
|
||||
|
||||
- 将管控集群中的密钥复制到子集群中。
|
||||
- 将验证集群中的工作负载部署到生产集群中。
|
||||
- 使用 Kubernetes 原生的 apiserver 作为控制面，将所有的 Kubernetes 对象存储在外部数据库中。然后通过引用这些资源，将它们下发到真正运行负载的子集群中。
|
||||
|
||||
|
||||
## 开始之前
|
||||
|
||||
- 准备一个 Deployment+Service 资源的 Yaml 定义文件，请注意，涉及多个资源时请将 Deployment、Statefulset、Job 等工作负载类资源置于第一个。如果多个工作负载类资源，请拆分为多个应用。
|
||||
|
|
@ -199,102 +192,6 @@ $ vela up -f https://kubevela.io/example/applications/app-with-k8s-objects.yaml
|
|||
$ vela workflow resume app-with-k8s-objects
|
||||
```
|
||||
|
||||
## 分发引用的外部 Kubernetes 对象
|
||||
|
||||
> 开始这部分之前需要你先了解使用 CLI 如何进行多集群应用的部署。你可以参考 [多集群应用交付](../case-studies/multi-cluster) 章节.
|
||||
|
||||
## 在组件中引用已有的 Kubernetes 对象
|
||||
|
||||
为了在组件中使用已有的 Kubernetes 对象，你需要使用 `ref-objects` 类型的组件，并在参数中声明你想要引用的资源。例如，在下面的例子中，命名空间 `examples` 中的密钥 `image-credential-to-copy` 会被作为组件的源数据，然后你可以使用 Topology 策略来将它复制分发到杭州集群中。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ref-objects-example
|
||||
namespace: examples
|
||||
spec:
|
||||
components:
|
||||
- name: image-pull-secrets
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- resource: secret
|
||||
name: image-credential-to-copy
|
||||
policies:
|
||||
- name: topology-hangzhou-clusters
|
||||
type: topology
|
||||
properties:
|
||||
clusterLabelSelector:
|
||||
region: hangzhou
|
||||
```
|
||||
|
||||
## *ref-objects* 类型组件的细节
|
||||
|
||||
声明需要引用资源最直接的方法是使用 `resource: secret` 或 `resource: deployment` 这样的方式来确定引用资源的类型。如果 `name` 和 `labelSelector` 都没有被设置，那么应用将会在它的命名空间下尝试寻找与和组件名称一致的资源。你也可以显式地指定 `name` 和 `namespace` 来确定需要引用的资源。
|
||||
|
||||
除了 `name` 和 `namespace`，你还可以使用 `cluster` 字段让应用组件去引用子集群中的资源。你也可以使用 `labelSelector` 来筛选资源，而不是直接用 `name` 去确定目标资源。
|
||||
|
||||
在下面的样例中，应用会选择在 *hangzhou-1* 集群的 *examples* 命名空间中，所有符合声明标签要求的 Deployment。然后应用会将这些 Deployments 复制到 *hangzhou-2* 集群中。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ref-objects-duplicate-deployments
|
||||
namespace: examples
|
||||
spec:
|
||||
components:
|
||||
- name: duplicate-deployment
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- resource: deployment
|
||||
cluster: hangzhou-1
|
||||
# select all deployment in the `examples` namespace in cluster `hangzhou-1` that matches the labelSelector
|
||||
labelSelector:
|
||||
need-duplicate: "true"
|
||||
policies:
|
||||
- name: topology-hangzhou-2
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["hangzhou-2"]
|
||||
```
|
||||
|
||||
> 在一些场景下，你可能想要限制应用能够引用资源的范围，你可以通过在 KubeVela 控制器中设置 `--ref-objects-available-scope` 为 `namespace` 或者 `cluster` 来限制只在同命名空间或者同一集群内引用资源。
|
||||
|
||||
## 在 ref-objects 类型组件内使用运维特征
|
||||
|
||||
*ref-objects* 类型的组件同样也可以使用运维特征。其主体工作负载会被隐式地设置为引用资源列表中的第一个资源。所有作用在工作负载上的运维特征都会指向该资源。 如下所示的例子展示了如何为引用的 Deployment 设置副本数，并下发到 hangzhou 集群中。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: ref-objects-multiple-resources
|
||||
namespace: examples
|
||||
spec:
|
||||
components:
|
||||
- name: nginx-ref-multiple-resources
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- resource: deployment
|
||||
- resource: service
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 3
|
||||
policies:
|
||||
- name: topology-hangzhou-clusters
|
||||
type: topology
|
||||
properties:
|
||||
clusterLabelSelector:
|
||||
region: hangzhou
|
||||
```
|
||||
|
||||
到此你已经完成了交付 Kubernetes 原生资源的学习！
|
||||
|
||||
## 下一步
|
||||
|
||||
- [交付云厂商服务](./consume-cloud-services)
|
||||
|
|
|
|||
|
|
@ -53,6 +53,3 @@ description: 本文介绍 KubeVela 的工作流工程模式，常用操作和适
|
|||
|
||||
工作流配置完成后注意点击工作流窗口右上方的 Save 按钮保存所有变更。保存完成后可以点击页面右上方的 `Deploy` 或右边的选择按钮选择执行该工作流，验证是否可以收到消息通知。
|
||||
|
||||
## 下一步
|
||||
|
||||
- [部署应用到指定环境](../how-to/dashboard/application/deploy-application)
|
||||
|
|
@ -81,9 +81,9 @@ module.exports = {
|
|||
{
|
||||
'General CD Features': [
|
||||
'how-to/dashboard/application/create-application',
|
||||
'end-user/version-control',
|
||||
'tutorials/workflows',
|
||||
'end-user/workflow/component-dependency-parameter',
|
||||
'end-user/version-control',
|
||||
'end-user/policies/apply-once',
|
||||
'end-user/policies/gc',
|
||||
],
|
||||
|
|
|
|||
|
|
@ -162,5 +162,7 @@ If you're a system infra or operator, you can refer to extension documents to le
|
|||
|
||||
If you're extremely interested in KubeVela, you can also extend more features as a developer.
|
||||
|
||||
- Read the [developer guide](../../contributor/overview) to learn how to contribute and extend capabilities for KubeVela.
|
||||
- KubeVela use CUE as it's core engine, [learn CUE in KubeVela](../../platform-engineers/cue/basic) and try to extend with CUE configurations.
|
||||
- Read the [developer guide](../../contributor/overview) to learn how to contribute and extend capabilities for KubeVela.
|
||||
|
||||
Welcome to join the KubeVela community! We're eager to see you to contribute your extension.
|
||||
|
|
|
|||
|
|
@ -6,17 +6,17 @@ Definition are the basic building block of the KubeVela platform. A definition e
|
|||
|
||||
There're four types of Definition, they're `ComponentDefinition`, `TraitDefinition`, `PolicyDefinition` and `WorkflowStepDefinition`, corresponding to the application concepts.
|
||||
|
||||
## Sources of Definitions
|
||||
## How to get out-of-box Definitions?
|
||||
|
||||
There're two sources of definitions:
|
||||
There're two sources to get out-of-box definitions:
|
||||
|
||||
* Built-in definitions will be installed along with KubeVela helm chart. You can refer to the following links to learn more about built-in definitions.
|
||||
- [Component Definition](../end-user/components/references)
|
||||
- [Trait Definition](../end-user/traits/references)
|
||||
- [Policy Definition](../end-user/policies/references)
|
||||
- [Workflow Step Definition](../end-user/workflow/built-in-workflow-defs)
|
||||
* Installation of addons will install definitions if there're new capabilities contained.
|
||||
- [Addon registry](../reference/addons/overview) contains a large catalog of addon which are maintained and verified by the KubeVela team.
|
||||
* [Addons](../reference/addons/overview), as extension of KubeVela, each addon contains a bunch of definitions along its CRD controllers.
|
||||
- The community has a [verified addon registry](https://github.com/kubevela/catalog) which contains a large catalog of addons, the registry is maintained by the KubeVela team.
|
||||
|
||||
## Lifecycle of a Definition
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ You can also view the details with a browser, the following command will launch
|
|||
vela show webservice --web
|
||||
```
|
||||
|
||||
* Discover in UI console
|
||||
* Discover in UI console ( addon `velaux` installed)
|
||||
|
||||
|
||||
|
||||
|
|
@ -76,6 +76,10 @@ If you're a fan of our UI console, the usage of definition is very straight forw
|
|||
|
||||
|
||||
|
||||
1. Create Application and choose Component type which is actually choosing which component definition to use.
|
||||
2. Fill the properties of component is actually fill the parameter of component definition.
|
||||
3. The same step for trait, policy and workflow.
|
||||
|
||||
Finally, the UI console will compose the whole deployment plan in the format of OAM like below, then KubeVela controller will take care of the rest things:
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -55,6 +55,3 @@ After the configuration is complete, click `Submit` to save the step configurati
|
|||
|
||||
After the workflow is configured, please click the Save button at the top right of the workflow window to save all changes. After saving, you can click the `Deploy` on the top right of the page or the select button on the right to choose to execute the workflow and verify whether you can receive a message notification.
|
||||
|
||||
## Next Steps
|
||||
|
||||
- [Deploy the application to the environment](../how-to/dashboard/application/deploy-application)
|
||||
|
|
@ -169,6 +169,10 @@
|
|||
"type": "doc",
|
||||
"id": "version-v1.4/how-to/dashboard/application/create-application"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.4/end-user/version-control"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.4/tutorials/workflows"
|
||||
|
|
@ -177,10 +181,6 @@
|
|||
"type": "doc",
|
||||
"id": "version-v1.4/end-user/workflow/component-dependency-parameter"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.4/end-user/version-control"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.4/end-user/policies/apply-once"
|
||||
|
|
|
|||
Loading…
Reference in New Issue