kubevela
/
kubevela.github.io
mirror of https://github.com/kubevela/kubevela.github.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #649 from wonderflow/refactor1 

Chore: refactor some docs
This commit is contained in:
barnettZQG 2022-05-11 19:02:53 +08:00 committed by GitHub
parent 94150ae946 64682bd274
commit af83643ff0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
57 changed files with 711 additions and 896 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/case-studies/gitops.md
View File

@ -4,7 +4,7 @@ title: GitOps
This section will introduce how to use KubeVela in GitOps environment and why.
> This section is only apply to CLI.
> This section is only apply to CLI, you need to enable the fluxcd addon.
## Introduction

2
docs/case-studies/multi-cluster.md
View File

@ -1,5 +1,5 @@
---
title: Multi-Cluster App Delivery
title: Multi-Cluster Delivery
---
KubeVela is by design a full functional Continuous Delivery (CD) platform with fine grained support for hybrid/multi-cloud/multi-cluster deployment.

37
docs/end-user/components/cue/task.md
View File

@ -2,39 +2,4 @@
title: Deploy Task or Cron Task
---
> This type is apply to CLI and UI.
## Describes jobs that run code or a script to completion
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-worker
spec:
components:
- name: mytask
type: task
properties:
image: perl
count: 10
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
```
## Describes cron jobs that run code or a script to completion
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: cron-worker
spec:
components:
- name: mytask
type: cron-task
properties:
image: perl
count: 10
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
schedule: "*/1 * * * *"
```
This docs are migrated, please refer to the [reference documents](../../components/references).

131
docs/end-user/components/kustomize.md
View File

@ -2,133 +2,4 @@
title: Pull based Component
---
Create a Kustomize Component, it could be from Git Repo or OSS bucket or image registry.
> This type is only apply to CLI.
## Enable the fluxcd addon
This component type is provided by the fluxcd addon, you must enable it firstly.
```shell
vale addon enable fluxcd
```
## Watch Files
### Deploy From OSS bucket
KubeVela's `kustomize` component meets the needs of users to directly connect Yaml files and folders as component products. No matter whether your Yaml file/folder is stored in a Git Repo or an OSS bucket, KubeVela can read and deliver it.
Let's take the YAML folder component from the OSS bucket registry as an example to explain the usage. In the `Application` this time, I hope to deliver a component named bucket-comp. The deployment file corresponding to the component is stored in the cloud storage OSS bucket, and the corresponding bucket name is definition-registry. `kustomize.yaml` comes from this address of `oss-cn-beijing.aliyuncs.com` and the path is `./app/prod/`.
1. (Optional) If your OSS bucket needs identity verification, create a Secret:
```shell
$ kubectl create secret generic bucket-secret --from-literal=accesskey=<your-ak> --from-literal=secretkey=<your-sk>
secret/bucket-secret created
```
2. Deploy it:
```shell
cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: bucket-app
spec:
components:
- name: bucket-comp
type: kustomize
properties:
repoType: oss
# If the bucket is private, you will need to provide
secretRef: bucket-secret
url: oss-cn-beijing.aliyuncs.com
oss:
bucketName: definition-registry
path: ./app/prod/
EOF
```
Please copy the above code block and deploy it directly to the runtime cluster:
```shell
application.core.oam.dev/bucket-app created
```
Finally, we use `vela ls` to view the application status after successful delivery:
```shell
vela ls
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
bucket-app bucket-comp kustomize running healthy 2021-08-28 18:53:14 +0800 CST
```
The PHASE of the app is running, and the STATUS is healthy. Successful application deployment!
### Deploy From Git Repo
**How-to**
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: git-app
spec:
components:
- name: git-comp
type: kustomize
properties:
repoType: git
url: https://github.com/<path>/<to>/<repo>
git:
branch: master
provider: GitHub
path: ./app/dev/
```
**Override Kustomize**
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: bucket-app
spec:
components:
- name: bucket-comp
type: kustomize
properties:
# ...omitted for brevity
path: ./app/
```
## Watch Image Registry
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: image-app
spec:
components:
- name: image
type: kustomize
properties:
imageRepository:
image: <your image>
secretRef: imagesecret
filterTags:
pattern: '^master-[a-f0-9]+-(?P<ts>[0-9]+)'
extract: '$ts'
policy:
numerical:
order: asc
commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"
```
This docs are migrated, please refer to the reference documents.

4
docs/end-user/components/more.md
View File

@ -1,8 +1,8 @@
---
title: Needs More Component？
title: Needs More？
---
* Refer to [All Component References](./references) for all other component types.
* Refer to [All Component References](./references) to learn all built-in supported artifacts supported for delivery.
* Get more from [install addons](../../how-to/cli/addon/addon).

99
docs/end-user/components/ref-objects.md
View File

@ -2,101 +2,4 @@
title: Distributed External Kubernetes Objects
---
Sometimes, you may want to distribute existing Kubernetes objects. For example,
- Copying secrets from the hub cluster into managed clusters.
- Promote deployments from canary clusters into production clusters.
- Using Kubernetes apiserver as the control plane and storing all Kubernetes objects data in external databases. Then dispatch those data into real Kuberenetes managed clusters.
> This document requires you to know how to deploy multi-cluster application with policy and workflow first. You can refer to [Multi-cluster Application Delivery](../../case-studies/multi-cluster) for details.
> This type is only apply to CLI.
## Refer to Existing Kubernetes Objects in Component
To use existing Kubernetes objects in the component, you need to use the `ref-objects` typed component and declare which resources you want to refer to. For example, in the following example, the secret `image-credential-to-copy` in namespace `examples` will be taken as the source object for the component. Then you can use the topology policy to dispatch it into hangzhou clusters.
```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
```
## Details for the *ref-objects* typed component
The most simple way to specify resources is to directly use `resource: secret` or `resource: deployment` to describe the kind of resources. If no `name` or `labelSelector` is set, the application will try to find the resource with the same name as the component name in the application's namespace. You can also explicitly specify `name` and `namespace` for the target resource as well.
In addition to `name` and `namespace`, you can also specify the `cluster` field to let the application component refer to resources in managed clusters. You can also use the `labelSelector` to select resources in replace of finding resources by names.
In the following example, the application will select all deployments in the *hangzhou-1* cluster inside the *examples* namespace, which matches the desided labels. Then the application will copy these deployments into *hangzhou-2* cluster.
```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"]
```
> In some cases, you might want to restrict the scope for the application to access resources. You can set the `--ref-objects-available-scope` to `namespace` or `cluster` in KubeVela controller's bootstrap parameter, to retrict the application to be only able to refer to the resources inside the same namespace or the same cluster.
## 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
```
This docs has been migrated, please refer to the [k8s-objects docs](../../tutorials/k8s-object#distributed-external-kubernetes-objects).

14
docs/end-user/components/references.md
View File

@ -943,7 +943,7 @@ spec:
## Kustomize ( repoType: oss )
Create a Kustomize Component, it could be from Git Repo or OSS bucket or image registry.
KubeVela's `kustomize` component meets the needs of users to directly connect Yaml files and folders as component products. No matter whether your Yaml file/folder is stored in a Git Repo or an OSS bucket, KubeVela can read and deliver it.
### Parameters
@ -961,7 +961,19 @@ Create a Kustomize Component, it could be from Git Repo or OSS bucket or image r
### Examples
Let's take the YAML folder component from the OSS bucket registry as an example to explain the usage. In the `Application` we will deliver a component named bucket-comp. The deployment file corresponding to the component is stored in the cloud storage OSS bucket, and the corresponding bucket name is definition-registry. `kustomize.yaml` comes from this address of `oss-cn-beijing.aliyuncs.com` and the path is `./app/prod/`.
1. (Optional) If your OSS bucket needs identity verification, create a Secret:
```shell
$ kubectl create secret generic bucket-secret --from-literal=accesskey=<your-ak> --from-literal=secretkey=<your-sk>
secret/bucket-secret created
```
2. Deploy it:
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:

2
docs/end-user/policies/apply-once.md
View File

@ -1,5 +1,5 @@
---
title: Allow Configuration Drift
title: One-time delivery
---
By default, the KubeVela controller will prevent configuration drift for applied resources by reconciling them routinely. This is useful if you want to keep your application always having the desired configuration in avoid of some unintentional changes by external modifiers.

4
docs/install.mdx
View File

@ -177,7 +177,7 @@ KubeVela CLI provides an easy to engage and manage your application delivery in
** MacOS/Linux **
```shell script
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.3
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.4
```
**Windows**
@ -280,7 +280,7 @@ If you are helm user, you can also use helm to install kubevela core:
```
helm repo add kubevela https://charts.kubevela.net/core
helm repo update
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.3.3 --wait
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.3.4 --wait
```
</TabItem>

2
docs/platform-engineers/advanced-install.mdx
View File

@ -49,7 +49,7 @@ vela install --version 1.3.0-beta.2
** MacOS/Linux **
```shell script
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.3
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.4
```
**Windows**

2
docs/platform-engineers/debug/debug.md
View File

@ -2,6 +2,8 @@
title: Debug in the environment
---
> This feature is available in KubeVela v1.4.
When you deploy your application in a test environment and find problems with the application, you may want to debug the application in the environment. KubeVela provides the `vela debug` command to help you debug your application in the environment.
## Applications with workflow

2
docs/tutorials/consume-cloud-services.md
View File

@ -1,5 +1,5 @@
---
title: Deploy Cloud Service
title: Cloud Services
description: This section introduces the delivery of services provided by cloud vendors through KubeVela and orchestrating your services in the Kubernetes cluster.
---

2
docs/tutorials/helm.md
View File

@ -1,5 +1,5 @@
---
title: Deploy Helm Chart
title: Helm Chart
---
This section introduces that how you deploy Helm Chart into multi-environments and clusters.

104
docs/tutorials/k8s-object.mdx
View File

@ -1,5 +1,5 @@
---
title: Deploy Kubernetes Objects
title: Kubernetes Objects
---
This section introduces that how you can deploy Kubernetes objects into multi environments and clusters.
@ -11,6 +11,13 @@ KubeVela supports you to render, orchestrate and deploy Kubernetes objects. The
3. Multi-env/cluster in application delivery.
4. The control loop of application deployment: Rollback, Terminate and Continue.
What's more, you can even distribute existing Kubernetes objects with KubeVela in the following scenarios:
- Copying secrets from the hub cluster into managed clusters.
- Promote deployments from canary clusters into production clusters.
- Using Kubernetes apiserver as the control plane and storing all Kubernetes objects data in external databases. Then dispatch those data into real Kuberenetes managed clusters.
## Before starting
- Prepare a Deployment+Service yaml config resource.
@ -190,6 +197,101 @@ $ vela up -f https://kubevela.io/example/applications/app-with-k8s-objects.yaml
$ vela workflow resume app-with-k8s-objects
```
## Distributed External Kubernetes Objects
> This section requires you to know how to deploy multi-cluster application with policy and workflow first. You can refer to [Multi-cluster Application Delivery](../case-studies/multi-cluster) for details.
### Refer to Existing Kubernetes Objects in Component
To use existing Kubernetes objects in the component, you need to use the `ref-objects` typed component and declare which resources you want to refer to. For example, in the following example, the secret `image-credential-to-copy` in namespace `examples` will be taken as the source object for the component. Then you can use the topology policy to dispatch it into hangzhou clusters.
```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
```
### Details for the *ref-objects* typed component
The most simple way to specify resources is to directly use `resource: secret` or `resource: deployment` to describe the kind of resources. If no `name` or `labelSelector` is set, the application will try to find the resource with the same name as the component name in the application's namespace. You can also explicitly specify `name` and `namespace` for the target resource as well.
In addition to `name` and `namespace`, you can also specify the `cluster` field to let the application component refer to resources in managed clusters. You can also use the `labelSelector` to select resources in replace of finding resources by names.
In the following example, the application will select all deployments in the *hangzhou-1* cluster inside the *examples* namespace, which matches the desided labels. Then the application will copy these deployments into *hangzhou-2* cluster.
```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"]
```
> In some cases, you might want to restrict the scope for the application to access resources. You can set the `--ref-objects-available-scope` to `namespace` or `cluster` in KubeVela controller's bootstrap parameter, to retrict the application to be only able to refer to the resources inside the same namespace or the same cluster.
### 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
```
Congrats! Now you've learned how to deploy Kubernetes objects.
## Next step

2
docs/tutorials/webservice.md
View File

@ -1,5 +1,5 @@
---
title: Deploy Container Image
title: Container Image
description: deploy the business application by kubevela
---

10
i18n/zh/docusaurus-plugin-content-docs/current.json
View File

@ -255,9 +255,9 @@
"message": "基本概念",
"description": "Basic information"
},
"sidebar.docs.category.Deploy with more workload type": {
"message": "更多组件类型",
"description": "非常用的组件类型"
"sidebar.docs.category.Artifacts": {
"message": "交付制品",
"description": "多样化交付制品"
},
"sidebar.docs.category.User Guide": {
"message": "用户手册",
@ -274,5 +274,9 @@
"sidebar.docs.category.How-to manage the applications": {
"message": "应用基础管理",
"description": "提供基础管理能力说明"
},
"sidebar.docs.category.CI Integration": {
"message": "CI 集成",
"description": "CI 集成"
}
}

37
i18n/zh/docusaurus-plugin-content-docs/current/end-user/components/cue/task.md
View File

@ -2,39 +2,4 @@
title: 部署一次性或周期性任务
---
> 此类型适用于 UI 和 CLI
### 一次性任务（Task）描述运行代码或脚本以完成的作业
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-worker
spec:
components:
- name: mytask
type: task
properties:
image: perl
count: 10
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
```
### 描述一个定时任务
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: cron-worker
spec:
components:
- name: mytask
type: cron-task
properties:
image: perl
count: 10
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
schedule: "*/1 * * * *"
```
文档已迁移至 [组件类型参考文档](../../components/references).

6
i18n/zh/docusaurus-plugin-content-docs/current/end-user/components/more.md
View File

@ -1,10 +1,10 @@
---
title: 获得更多组件类型？
title: 获得更多？
---
* 查看 [所有组件参考列表](./references)。
* 查看 [组件参考列表](./references)文档，了解所有内置支持的交付制品。
* 从[插件安装](../../how-to/cli/addon/addon)中获得。
* 通过[安装插件](../../how-to/cli/addon/addon)集成更多交付制品。
* 自己动手扩展

99
i18n/zh/docusaurus-plugin-content-docs/current/end-user/components/ref-objects.md
View File

@ -2,101 +2,4 @@
title: 分发引用的外部 Kubernetes 对象
---
在一些场景下，你可能会想要引用已有的 Kubernetes 对象并将它们分发到其他位置，比如
- 将管控集群中的密钥复制到子集群中。
- 将验证集群中的工作负载部署到生产集群中。
- 使用 Kubernetes 原生的 apiserver 作为控制面，将所有的 Kubernetes 对象存储在外部数据库中。然后通过引用这些资源，将它们下发到真正运行负载的子集群中。
> 这篇文档需要你先了解如何进行多集群应用的部署。你可以参考 [多集群应用交付](../../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 交付制品]](../../tutorials/k8s-object#distributed-external-kubernetes-objects).

13
i18n/zh/docusaurus-plugin-content-docs/current/end-user/components/references.md
View File

@ -962,7 +962,20 @@ Create a Kustomize Component, it could be from Git Repo or OSS bucket or image r
### 样例
Let's take the YAML folder component from the OSS bucket registry as an example to explain the usage. In the `Application` we will deliver a component named bucket-comp. The deployment file corresponding to the component is stored in the cloud storage OSS bucket, and the corresponding bucket name is definition-registry. `kustomize.yaml` comes from this address of `oss-cn-beijing.aliyuncs.com` and the path is `./app/prod/`.
1. (Optional) If your OSS bucket needs identity verification, create a Secret:
```shell
$ kubectl create secret generic bucket-secret --from-literal=accesskey=<your-ak> --from-literal=secretkey=<your-sk>
secret/bucket-secret created
```
2. Deploy it:
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:

2
i18n/zh/docusaurus-plugin-content-docs/current/end-user/policies/apply-once.md
View File

@ -1,5 +1,5 @@
---
title: 允许配置漂移
title: 一次性交付
---
默认情况下，KubeVela 控制器会通过不断轮询应用下管控资源的方式来防止出现配置飘移。如果你希望声明应用中的资源状态为终态，这种处理方式可以让应用资源即使受到外部的变更操作也可以在一段时间后自动恢复回先前声明的状态。

4
i18n/zh/docusaurus-plugin-content-docs/current/install.mdx
View File

@ -178,7 +178,7 @@ KubeVela CLI 提供了命令行工具来便捷的应用终端管理能力。
** MacOS/Linux **
```shell script
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.3
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.4
```
**Windows**
@ -280,7 +280,7 @@ If you want to enable dashboard, please run "vela addon enable velaux"
```
helm repo add kubevela https://charts.kubevela.net/core
helm repo update
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.3.3 --wait
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.3.4 --wait
```
</TabItem>

2
i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/advanced-install.mdx
View File

@ -51,7 +51,7 @@ vela install --version 1.3.0-beta.2
** MacOS/Linux **
```shell script
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.3
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.4
```
**Windows**

2
i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/debug/debug.md
View File

@ -2,6 +2,8 @@
title: 在环境中调试
---
> 该功能需要安装至少 KubeVela v1.4 及以上版本.
当你在测试环境中部署应用，并发现应用出现问题时，你可能会想要在环境中调试应用。KubeVela 提供了 `vela debug` 命令，来帮助你在环境中调试应用。
## 使用工作流的应用

2
i18n/zh/docusaurus-plugin-content-docs/current/tutorials/consume-cloud-services.md
View File

@ -1,5 +1,5 @@
---
title: 交付云服务
title: 云服务
description: 本文介绍通过 KubeVela 交付云厂商提供的服务，并能够与 Kubernetes 集群中的业务打通。
---

2
i18n/zh/docusaurus-plugin-content-docs/current/tutorials/helm.md
View File

@ -1,5 +1,5 @@
---
title: 交付 Helm Chart
title: Helm Chart
description: 本文介绍通过 KubeVela 交付 Helm Chart
---

103
i18n/zh/docusaurus-plugin-content-docs/current/tutorials/k8s-object.mdx
View File

@ -1,5 +1,5 @@
---
title: 交付 Kubernetes 原生资源
title: Kubernetes 原生资源
description: 对 Kubernetes 有一定了解的用户，参考本文档学习利用 KubeVela 的能力将已经定义好的 Kubernetes 资源便捷交付到多个集群。
---
@ -12,6 +12,13 @@ KubeVela 支持面向应用组织多个 Kubernetes 资源进行交付，常见
3. 初步了解多环境/多集群的应用发布。
4. 应用发布过程控制：回退、终止和继续。
不仅如此，你还可以使用 KubeVela 引用已有的 Kubernetes 对象并将它们分发到其他位置来完成以下场景：
- 将管控集群中的密钥复制到子集群中。
- 将验证集群中的工作负载部署到生产集群中。
- 使用 Kubernetes 原生的 apiserver 作为控制面，将所有的 Kubernetes 对象存储在外部数据库中。然后通过引用这些资源，将它们下发到真正运行负载的子集群中。
## 开始之前
- 准备一个 Deployment+Service 资源的 Yaml 定义文件，请注意，涉及多个资源时请将 Deployment、Statefulset、Job 等工作负载类资源置于第一个。如果多个工作负载类资源，请拆分为多个应用。
@ -192,6 +199,100 @@ $ 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 原生资源的学习！
## 下一步

2
i18n/zh/docusaurus-plugin-content-docs/current/tutorials/webservice.md
View File

@ -1,5 +1,5 @@
---
title: 交付容器镜像
title: 容器镜像
description: 参考本文章，学习使用容器镜像部署企业业务应用，大多数企业业务应用都可作为无状态应用交付。
---

37
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/end-user/components/cue/task.md
View File

@ -2,39 +2,4 @@
title: 部署一次性或周期性任务
---
> 此类型适用于 UI 和 CLI
### 一次性任务（Task）描述运行代码或脚本以完成的作业
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-worker
spec:
components:
- name: mytask
type: task
properties:
image: perl
count: 10
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
```
### 描述一个定时任务
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: cron-worker
spec:
components:
- name: mytask
type: cron-task
properties:
image: perl
count: 10
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
schedule: "*/1 * * * *"
```
文档已迁移至 [组件类型参考文档](../../components/references).

6
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/end-user/components/more.md
View File

@ -1,10 +1,10 @@
---
title: 获得更多组件类型？
title: 获得更多？
---
* 查看 [所有组件参考列表](./references)。
* 查看 [组件参考列表](./references)文档，了解所有内置支持的交付制品。
* 从[插件安装](../../how-to/cli/addon/addon)中获得。
* 通过[安装插件](../../how-to/cli/addon/addon)集成更多交付制品。
* 自己动手扩展

99
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/end-user/components/ref-objects.md
View File

@ -2,101 +2,4 @@
title: 分发引用的外部 Kubernetes 对象
---
在一些场景下，你可能会想要引用已有的 Kubernetes 对象并将它们分发到其他位置，比如
- 将管控集群中的密钥复制到子集群中。
- 将验证集群中的工作负载部署到生产集群中。
- 使用 Kubernetes 原生的 apiserver 作为控制面，将所有的 Kubernetes 对象存储在外部数据库中。然后通过引用这些资源，将它们下发到真正运行负载的子集群中。
> 这篇文档需要你先了解如何进行多集群应用的部署。你可以参考 [多集群应用交付](../../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 交付制品]](../../tutorials/k8s-object#distributed-external-kubernetes-objects).

13
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/end-user/components/references.md
View File

@ -962,7 +962,20 @@ Create a Kustomize Component, it could be from Git Repo or OSS bucket or image r
### 样例
Let's take the YAML folder component from the OSS bucket registry as an example to explain the usage. In the `Application` we will deliver a component named bucket-comp. The deployment file corresponding to the component is stored in the cloud storage OSS bucket, and the corresponding bucket name is definition-registry. `kustomize.yaml` comes from this address of `oss-cn-beijing.aliyuncs.com` and the path is `./app/prod/`.
1. (Optional) If your OSS bucket needs identity verification, create a Secret:
```shell
$ kubectl create secret generic bucket-secret --from-literal=accesskey=<your-ak> --from-literal=secretkey=<your-sk>
secret/bucket-secret created
```
2. Deploy it:
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:

2
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/end-user/policies/apply-once.md
View File

@ -1,5 +1,5 @@
---
title: 允许配置漂移
title: 一次性交付
---
默认情况下，KubeVela 控制器会通过不断轮询应用下管控资源的方式来防止出现配置飘移。如果你希望声明应用中的资源状态为终态，这种处理方式可以让应用资源即使受到外部的变更操作也可以在一段时间后自动恢复回先前声明的状态。

4
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/install.mdx
View File

@ -178,7 +178,7 @@ KubeVela CLI 提供了命令行工具来便捷的应用终端管理能力。
** MacOS/Linux **
```shell script
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.3
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.4
```
**Windows**
@ -280,7 +280,7 @@ If you want to enable dashboard, please run "vela addon enable velaux"
```
helm repo add kubevela https://charts.kubevela.net/core
helm repo update
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.3.3 --wait
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.3.4 --wait
```
</TabItem>

2
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/platform-engineers/advanced-install.mdx
View File

@ -51,7 +51,7 @@ vela install --version 1.3.0-beta.2
** MacOS/Linux **
```shell script
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.3
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.4
```
**Windows**

70
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/platform-engineers/debug/debug.md Normal file
View File

@ -0,0 +1,70 @@
---
title: 在环境中调试
---
> 该功能需要安装至少 KubeVela v1.4 及以上版本.
当你在测试环境中部署应用，并发现应用出现问题时，你可能会想要在环境中调试应用。KubeVela 提供了 `vela debug` 命令，来帮助你在环境中调试应用。
## 使用工作流的应用
如果你的应用使用了工作流，那么在使用 `vela debug` 命令前，请确保你的应用中使用了 `debug` 策略：
```yaml
polices:
- name: debug
type: debug
```
你也可以使用 `vela up -f <application yaml> --debug` 来为你的应用自动加上 debug 策略。
对于使用了工作流的应用，`vela debug` 会首先列出工作流中的所有步骤，你可以选择指定的步骤进行调试。选择完步骤后，你可以分别查看该步骤中的所有 CUE 变量内容。其中：黄色标明的 `do` 和 `provider` 是本次使用的 CUE action，错误的内容将以红色标志。
![](https://static.kubevela.net/images/1.4/debug-workflow.gif)
你也可以使用 `vela debug <application-name> -s <step-name> -f <variable>` 来查看单个 步骤中的指定变量的内容。
![](https://static.kubevela.net/images/1.4/debug-workflow-focus.gif)
## 仅使用组件的应用
如果你的应用只使用了组件，没有使用工作流。那么，你可以直接使用 `vela debug <application-name>` 命令来进行调试你的应用。
部署如下应用，该应用的第一个组件会使用 `k8s-objects` 创建一个 Namespace，第二个组件则会使用 `webservice` 组件以及 `gateway` 运维特征，从而创建一个 Deployment 及其对应的 Service 和 Ingress。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: gateway-app
spec:
components:
- name: comp-namespace
type: k8s-objects
properties:
objects:
- apiVersion: v1
kind: Namespace
metadata:
name: test-ns1
- name: express-server
type: webservice
properties:
image: crccheck/hello-world
ports:
- port: 8000
traits:
- type: gateway
properties:
domain: testsvc.example.com
http:
"/": 8000
```
部署完应用后，你可以使用 `vela debug <application-name>` 命令分组件来查看该应用渲染出来的所有资源。
![](https://static.kubevela.net/images/1.4/debug-application.gif)
你也可以使用 `vela debug <application-name> -s <component-name>` 来查看单个组件中被渲染出来的所有资源。
![](https://static.kubevela.net/images/1.4/debug-application-comp.gif)

2
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/tutorials/consume-cloud-services.md
View File

@ -1,5 +1,5 @@
---
title: 交付云服务
title: 云服务
description: 本文介绍通过 KubeVela 交付云厂商提供的服务，并能够与 Kubernetes 集群中的业务打通。
---

2
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/tutorials/helm.md
View File

@ -1,5 +1,5 @@
---
title: 交付 Helm Chart
title: Helm Chart
description: 本文介绍通过 KubeVela 交付 Helm Chart
---

103
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/tutorials/k8s-object.mdx
View File

@ -1,5 +1,5 @@
---
title: 交付 Kubernetes 原生资源
title: Kubernetes 原生资源
description: 对 Kubernetes 有一定了解的用户，参考本文档学习利用 KubeVela 的能力将已经定义好的 Kubernetes 资源便捷交付到多个集群。
---
@ -12,6 +12,13 @@ KubeVela 支持面向应用组织多个 Kubernetes 资源进行交付，常见
3. 初步了解多环境/多集群的应用发布。
4. 应用发布过程控制：回退、终止和继续。
不仅如此，你还可以使用 KubeVela 引用已有的 Kubernetes 对象并将它们分发到其他位置来完成以下场景：
- 将管控集群中的密钥复制到子集群中。
- 将验证集群中的工作负载部署到生产集群中。
- 使用 Kubernetes 原生的 apiserver 作为控制面，将所有的 Kubernetes 对象存储在外部数据库中。然后通过引用这些资源，将它们下发到真正运行负载的子集群中。
## 开始之前
- 准备一个 Deployment+Service 资源的 Yaml 定义文件，请注意，涉及多个资源时请将 Deployment、Statefulset、Job 等工作负载类资源置于第一个。如果多个工作负载类资源，请拆分为多个应用。
@ -192,6 +199,100 @@ $ 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 原生资源的学习！
## 下一步

2
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/tutorials/webservice.md
View File

@ -1,5 +1,5 @@
---
title: 交付容器镜像
title: 容器镜像
description: 参考本文章，学习使用容器镜像部署企业业务应用，大多数企业业务应用都可作为无状态应用交付。
---

28
sidebars.js
View File

@ -19,25 +19,29 @@ module.exports = {
label: 'User Guide',
collapsed: false,
items: [
'tutorials/webservice',
'tutorials/helm',
'tutorials/k8s-object',
'tutorials/consume-cloud-services',
{
type: 'category',
label: 'Deploy with more workload type',
collapsed: true,
label: 'Artifacts',
collapsed: false,
items: [
'end-user/components/cue/task',
'end-user/components/kustomize',
'end-user/components/ref-objects',
'tutorials/webservice',
'tutorials/helm',
'tutorials/k8s-object',
'tutorials/consume-cloud-services',
'end-user/components/more',
],
},
'case-studies/multi-cluster',
'tutorials/jenkins',
'tutorials/trigger',
'case-studies/gitops',
{
type: 'category',
label: 'CI Integration',
collapsed: false,
items: [
'tutorials/jenkins',
'tutorials/trigger',
'case-studies/gitops',
],
},
{
'How-to manage the cloud resources': [
'end-user/components/cloud-services/provision-and-consume-cloud-services',

2
versioned_docs/version-v1.3/case-studies/gitops.md
View File

@ -4,7 +4,7 @@ title: GitOps
This section will introduce how to use KubeVela in GitOps environment and why.
> This section is only apply to CLI.
> This section is only apply to CLI, you need to enable the fluxcd addon.
## Introduction

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

@ -1,5 +1,5 @@
---
title: Multi-Cluster App Delivery
title: Multi-Cluster Delivery
---
KubeVela is by design a full functional Continuous Delivery (CD) platform with fine grained support for hybrid/multi-cloud/multi-cluster deployment.

37
versioned_docs/version-v1.3/end-user/components/cue/task.md
View File

@ -2,39 +2,4 @@
title: Deploy Task or Cron Task
---
> This type is apply to CLI and UI.
## Describes jobs that run code or a script to completion
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-worker
spec:
components:
- name: mytask
type: task
properties:
image: perl
count: 10
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
```
## Describes cron jobs that run code or a script to completion
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: cron-worker
spec:
components:
- name: mytask
type: cron-task
properties:
image: perl
count: 10
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
schedule: "*/1 * * * *"
```
This docs are migrated, please refer to the [reference documents](../../components/references).

131
versioned_docs/version-v1.3/end-user/components/kustomize.md
View File

@ -2,133 +2,4 @@
title: Pull based Component
---
Create a Kustomize Component, it could be from Git Repo or OSS bucket or image registry.
> This type is only apply to CLI.
## Enable the fluxcd addon
This component type is provided by the fluxcd addon, you must enable it firstly.
```shell
vale addon enable fluxcd
```
## Watch Files
### Deploy From OSS bucket
KubeVela's `kustomize` component meets the needs of users to directly connect Yaml files and folders as component products. No matter whether your Yaml file/folder is stored in a Git Repo or an OSS bucket, KubeVela can read and deliver it.
Let's take the YAML folder component from the OSS bucket registry as an example to explain the usage. In the `Application` this time, I hope to deliver a component named bucket-comp. The deployment file corresponding to the component is stored in the cloud storage OSS bucket, and the corresponding bucket name is definition-registry. `kustomize.yaml` comes from this address of `oss-cn-beijing.aliyuncs.com` and the path is `./app/prod/`.
1. (Optional) If your OSS bucket needs identity verification, create a Secret:
```shell
$ kubectl create secret generic bucket-secret --from-literal=accesskey=<your-ak> --from-literal=secretkey=<your-sk>
secret/bucket-secret created
```
2. Deploy it:
```shell
cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: bucket-app
spec:
components:
- name: bucket-comp
type: kustomize
properties:
repoType: oss
# If the bucket is private, you will need to provide
secretRef: bucket-secret
url: oss-cn-beijing.aliyuncs.com
oss:
bucketName: definition-registry
path: ./app/prod/
EOF
```
Please copy the above code block and deploy it directly to the runtime cluster:
```shell
application.core.oam.dev/bucket-app created
```
Finally, we use `vela ls` to view the application status after successful delivery:
```shell
vela ls
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
bucket-app bucket-comp kustomize running healthy 2021-08-28 18:53:14 +0800 CST
```
The PHASE of the app is running, and the STATUS is healthy. Successful application deployment!
### Deploy From Git Repo
**How-to**
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: git-app
spec:
components:
- name: git-comp
type: kustomize
properties:
repoType: git
url: https://github.com/<path>/<to>/<repo>
git:
branch: master
provider: GitHub
path: ./app/dev/
```
**Override Kustomize**
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: bucket-app
spec:
components:
- name: bucket-comp
type: kustomize
properties:
# ...omitted for brevity
path: ./app/
```
## Watch Image Registry
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: image-app
spec:
components:
- name: image
type: kustomize
properties:
imageRepository:
image: <your image>
secretRef: imagesecret
filterTags:
pattern: '^master-[a-f0-9]+-(?P<ts>[0-9]+)'
extract: '$ts'
policy:
numerical:
order: asc
commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"
```
This docs are migrated, please refer to the reference documents.

4
versioned_docs/version-v1.3/end-user/components/more.md
View File

@ -1,8 +1,8 @@
---
title: Needs More Component？
title: Needs More？
---
* Refer to [All Component References](./references) for all other component types.
* Refer to [All Component References](./references) to learn all built-in supported artifacts supported for delivery.
* Get more from [install addons](../../how-to/cli/addon/addon).

99
versioned_docs/version-v1.3/end-user/components/ref-objects.md
View File

@ -2,101 +2,4 @@
title: Distributed External Kubernetes Objects
---
Sometimes, you may want to distribute existing Kubernetes objects. For example,
- Copying secrets from the hub cluster into managed clusters.
- Promote deployments from canary clusters into production clusters.
- Using Kubernetes apiserver as the control plane and storing all Kubernetes objects data in external databases. Then dispatch those data into real Kuberenetes managed clusters.
> This document requires you to know how to deploy multi-cluster application with policy and workflow first. You can refer to [Multi-cluster Application Delivery](../../case-studies/multi-cluster) for details.
> This type is only apply to CLI.
## Refer to Existing Kubernetes Objects in Component
To use existing Kubernetes objects in the component, you need to use the `ref-objects` typed component and declare which resources you want to refer to. For example, in the following example, the secret `image-credential-to-copy` in namespace `examples` will be taken as the source object for the component. Then you can use the topology policy to dispatch it into hangzhou clusters.
```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
```
## Details for the *ref-objects* typed component
The most simple way to specify resources is to directly use `resource: secret` or `resource: deployment` to describe the kind of resources. If no `name` or `labelSelector` is set, the application will try to find the resource with the same name as the component name in the application's namespace. You can also explicitly specify `name` and `namespace` for the target resource as well.
In addition to `name` and `namespace`, you can also specify the `cluster` field to let the application component refer to resources in managed clusters. You can also use the `labelSelector` to select resources in replace of finding resources by names.
In the following example, the application will select all deployments in the *hangzhou-1* cluster inside the *examples* namespace, which matches the desided labels. Then the application will copy these deployments into *hangzhou-2* cluster.
```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"]
```
> In some cases, you might want to restrict the scope for the application to access resources. You can set the `--ref-objects-available-scope` to `namespace` or `cluster` in KubeVela controller's bootstrap parameter, to retrict the application to be only able to refer to the resources inside the same namespace or the same cluster.
## 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
```
This docs has been migrated, please refer to the [k8s-objects docs](../../tutorials/k8s-object#distributed-external-kubernetes-objects).

14
versioned_docs/version-v1.3/end-user/components/references.md
View File

@ -943,7 +943,7 @@ spec:
## Kustomize ( repoType: oss )
Create a Kustomize Component, it could be from Git Repo or OSS bucket or image registry.
KubeVela's `kustomize` component meets the needs of users to directly connect Yaml files and folders as component products. No matter whether your Yaml file/folder is stored in a Git Repo or an OSS bucket, KubeVela can read and deliver it.
### Parameters
@ -961,7 +961,19 @@ Create a Kustomize Component, it could be from Git Repo or OSS bucket or image r
### Examples
Let's take the YAML folder component from the OSS bucket registry as an example to explain the usage. In the `Application` we will deliver a component named bucket-comp. The deployment file corresponding to the component is stored in the cloud storage OSS bucket, and the corresponding bucket name is definition-registry. `kustomize.yaml` comes from this address of `oss-cn-beijing.aliyuncs.com` and the path is `./app/prod/`.
1. (Optional) If your OSS bucket needs identity verification, create a Secret:
```shell
$ kubectl create secret generic bucket-secret --from-literal=accesskey=<your-ak> --from-literal=secretkey=<your-sk>
secret/bucket-secret created
```
2. Deploy it:
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:

2
versioned_docs/version-v1.3/end-user/policies/apply-once.md
View File

@ -1,5 +1,5 @@
---
title: Allow Configuration Drift
title: One-time delivery
---
By default, the KubeVela controller will prevent configuration drift for applied resources by reconciling them routinely. This is useful if you want to keep your application always having the desired configuration in avoid of some unintentional changes by external modifiers.

10
versioned_docs/version-v1.3/install.mdx
View File

@ -144,12 +144,6 @@ nodes:
EOF
```
Install ingress controller to enable service route：
```shell script
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/kind/deploy.yaml
```
</TabItem>
<TabItem value="cloudprovider">
@ -183,7 +177,7 @@ KubeVela CLI provides an easy to engage and manage your application delivery in
** MacOS/Linux **
```shell script
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.3
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.4
```
**Windows**
@ -286,7 +280,7 @@ If you are helm user, you can also use helm to install kubevela core:
```
helm repo add kubevela https://charts.kubevela.net/core
helm repo update
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.3.3 --wait
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.3.4 --wait
```
</TabItem>

2
versioned_docs/version-v1.3/platform-engineers/advanced-install.mdx
View File

@ -49,7 +49,7 @@ vela install --version 1.3.0-beta.2
** MacOS/Linux **
```shell script
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.3
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.4
```
**Windows**

70
versioned_docs/version-v1.3/platform-engineers/debug/debug.md Normal file
View File

@ -0,0 +1,70 @@
---
title: Debug in the environment
---
> This feature is available in KubeVela v1.4.
When you deploy your application in a test environment and find problems with the application, you may want to debug the application in the environment. KubeVela provides the `vela debug` command to help you debug your application in the environment.
## Applications with workflow
If your application uses workflow, make sure your app has the `debug` policy before using the `vela debug` command:
```yaml
polices:
- name: debug
type: debug
```
You can also use `vela up -f <application yaml> --debug` to automatically add debug policy to your application.
For applications that use workflows, `vela debug` will first list all the steps in the workflow, and you can select the specified steps to debug. After selecting a step, you can view the contents of all CUE variables in that step individually. Among them: `do` and `provider` marked in yellow are the CUE actions used this time, and the error content will be marked in red.
![](https://static.kubevela.net/images/1.4/debug-workflow.gif)
You can also use `vela debug <application-name> -s <step-name> -f <variable>` to view the contents of specified variables in a single step.
![](https://static.kubevela.net/images/1.4/debug-workflow-focus.gif)
## Applications with components only
If your application only uses components, not workflows, then, you can use the `vela debug <application-name>` command directly to debug your application.
Deploy the following application. The first component will use `k8s-objects` to create a Namespace, and the second component will use the `webservice` with `gateway` trait to create a Deployment and its corresponding Service and Ingress.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: gateway-app
spec:
components:
- name: comp-namespace
type: k8s-objects
properties:
objects:
- apiVersion: v1
kind: Namespace
metadata:
name: test-ns1
- name: express-server
type: webservice
properties:
image: crccheck/hello-world
ports:
- port: 8000
traits:
- type: gateway
properties:
domain: testsvc.example.com
http:
"/": 8000
```
After the application is deployed, you can use the `vela debug <application-name>` command to view all the resources rendered by the application.
![](https://static.kubevela.net/images/1.4/debug-application.gif)
You can also use `vela debug <application-name> -s <component-name>` to see all resources rendered in a single component.
![](https://static.kubevela.net/images/1.4/debug-application-comp.gif)

2
versioned_docs/version-v1.3/tutorials/consume-cloud-services.md
View File

@ -1,5 +1,5 @@
---
title: Deploy Cloud Service
title: Cloud Services
description: This section introduces the delivery of services provided by cloud vendors through KubeVela and orchestrating your services in the Kubernetes cluster.
---

2
versioned_docs/version-v1.3/tutorials/helm.md
View File

@ -1,5 +1,5 @@
---
title: Deploy Helm Chart
title: Helm Chart
---
This section introduces that how you deploy Helm Chart into multi-environments and clusters.

104
versioned_docs/version-v1.3/tutorials/k8s-object.mdx
View File

@ -1,5 +1,5 @@
---
title: Deploy Kubernetes Objects
title: Kubernetes Objects
---
This section introduces that how you can deploy Kubernetes objects into multi environments and clusters.
@ -11,6 +11,13 @@ KubeVela supports you to render, orchestrate and deploy Kubernetes objects. The
3. Multi-env/cluster in application delivery.
4. The control loop of application deployment: Rollback, Terminate and Continue.
What's more, you can even distribute existing Kubernetes objects with KubeVela in the following scenarios:
- Copying secrets from the hub cluster into managed clusters.
- Promote deployments from canary clusters into production clusters.
- Using Kubernetes apiserver as the control plane and storing all Kubernetes objects data in external databases. Then dispatch those data into real Kuberenetes managed clusters.
## Before starting
- Prepare a Deployment+Service yaml config resource.
@ -190,6 +197,101 @@ $ vela up -f https://kubevela.io/example/applications/app-with-k8s-objects.yaml
$ vela workflow resume app-with-k8s-objects
```
## Distributed External Kubernetes Objects
> This section requires you to know how to deploy multi-cluster application with policy and workflow first. You can refer to [Multi-cluster Application Delivery](../case-studies/multi-cluster) for details.
### Refer to Existing Kubernetes Objects in Component
To use existing Kubernetes objects in the component, you need to use the `ref-objects` typed component and declare which resources you want to refer to. For example, in the following example, the secret `image-credential-to-copy` in namespace `examples` will be taken as the source object for the component. Then you can use the topology policy to dispatch it into hangzhou clusters.
```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
```
### Details for the *ref-objects* typed component
The most simple way to specify resources is to directly use `resource: secret` or `resource: deployment` to describe the kind of resources. If no `name` or `labelSelector` is set, the application will try to find the resource with the same name as the component name in the application's namespace. You can also explicitly specify `name` and `namespace` for the target resource as well.
In addition to `name` and `namespace`, you can also specify the `cluster` field to let the application component refer to resources in managed clusters. You can also use the `labelSelector` to select resources in replace of finding resources by names.
In the following example, the application will select all deployments in the *hangzhou-1* cluster inside the *examples* namespace, which matches the desided labels. Then the application will copy these deployments into *hangzhou-2* cluster.
```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"]
```
> In some cases, you might want to restrict the scope for the application to access resources. You can set the `--ref-objects-available-scope` to `namespace` or `cluster` in KubeVela controller's bootstrap parameter, to retrict the application to be only able to refer to the resources inside the same namespace or the same cluster.
### 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
```
Congrats! Now you've learned how to deploy Kubernetes objects.
## Next step

2
versioned_docs/version-v1.3/tutorials/webservice.md
View File

@ -1,5 +1,5 @@
---
title: Deploy Container Image
title: Container Image
description: deploy the business application by kubevela
---

61
versioned_sidebars/version-v1.3-sidebars.json
View File

@ -40,37 +40,25 @@
"label": "User Guide",
"items": [
{
"type": "doc",
"id": "version-v1.3/tutorials/webservice"
},
{
"type": "doc",
"id": "version-v1.3/tutorials/helm"
},
{
"type": "doc",
"id": "version-v1.3/tutorials/k8s-object"
},
{
"type": "doc",
"id": "version-v1.3/tutorials/consume-cloud-services"
},
{
"collapsed": true,
"collapsed": false,
"type": "category",
"label": "Deploy with more workload type",
"label": "Artifacts",
"items": [
{
"type": "doc",
"id": "version-v1.3/end-user/components/cue/task"
"id": "version-v1.3/tutorials/webservice"
},
{
"type": "doc",
"id": "version-v1.3/end-user/components/kustomize"
"id": "version-v1.3/tutorials/helm"
},
{
"type": "doc",
"id": "version-v1.3/end-user/components/ref-objects"
"id": "version-v1.3/tutorials/k8s-object"
},
{
"type": "doc",
"id": "version-v1.3/tutorials/consume-cloud-services"
},
{
"type": "doc",
@ -83,16 +71,23 @@
"id": "version-v1.3/case-studies/multi-cluster"
},
{
"type": "doc",
"id": "version-v1.3/tutorials/jenkins"
},
{
"type": "doc",
"id": "version-v1.3/tutorials/trigger"
},
{
"type": "doc",
"id": "version-v1.3/case-studies/gitops"
"collapsed": false,
"type": "category",
"label": "CI Integration",
"items": [
{
"type": "doc",
"id": "version-v1.3/tutorials/jenkins"
},
{
"type": "doc",
"id": "version-v1.3/tutorials/trigger"
},
{
"type": "doc",
"id": "version-v1.3/case-studies/gitops"
}
]
},
{
"collapsed": true,
@ -441,6 +436,10 @@
"type": "doc",
"id": "version-v1.3/platform-engineers/debug/dry-run"
},
{
"type": "doc",
"id": "version-v1.3/platform-engineers/debug/debug"
},
{
"type": "doc",
"id": "version-v1.3/platform-engineers/x-def-version"