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

Chore: release v1.3 docs 

Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>
This commit is contained in:
Jianbo Sun 2022-04-08 17:52:35 +08:00
parent 4f78653303
commit 6995f34cf4
1177 changed files with 60136 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
README.md
View File

@ -101,4 +101,17 @@ This command generates static content into the `build` directory and can be serv
GIT_USER=<Your GitHub username> USE_SSH=true yarn deploy
```
If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.
If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.
## Build New Version
```
yarn docusaurus docs:version v1.3
```
## Update Docs for version
```
make update-version version=v1.3
```

3
docs/end-user/quick-start-cli.md
View File

@ -64,4 +64,5 @@ Great! You have finished deploying your first KubeVela application, the simplest
## Next Step
* Components and traits are just the beginning of your vela sail. Learn how to do [Multi-Cluster App Delivery](../case-studies/multi-cluster) with advanced usage about Policy and Workflow.
* Learn how to do [Multi-Cluster App Delivery](../case-studies/multi-cluster),Components and traits are just the beginning of your vela sail, there're more powerful features around Policy and Workflow.
* Refer to [VelaUX](../quick-start) for UI Console experience.

8
docs/getting-started/introduction.md
View File

@ -24,14 +24,14 @@ This is why KubeVela appears here. It can simplify the application delivery and
![](../resources/vela-overview.jpg)
We mainly provide two products for different users, they're [KubeVela](../end-user/quick-start-cli) and [VelaUX](../quick-start).
We mainly provide two products for different users, they're [KubeVela](./end-user/quick-start-cli) and [VelaUX](./quick-start).
- Platform builders for PaaS, Serverless, Application Management/Delivery systems
- [KubeVela](../end-user/quick-start-cli) works as an application delivery engine that you could build your advanced platform with.
- [KubeVela](./end-user/quick-start-cli) works as an application delivery engine that you could build your advanced platform with.
- ISV, SaaS owners, and Application Architects who need to distribute software to anywhere
- KubeVela has full extension and integration capabilities to allow users to distribute applications with [customized addons](../platform-engineers/addon/intro) easily. Think about an App Store but on Kubernetes and clouds.
- KubeVela has full extension and integration capabilities to allow users to distribute applications with [customized addons](./platform-engineers/addon/intro) easily. Think about an App Store but on Kubernetes and clouds.
- Application Developers, Operators, DevOps Engineers
- [VelaUX](../quick-start) is an addon of KubeVela, with this addon enabled, it provides an out-of-box modern application Continuous Delivery (CD) and Management platform with an easy-to-use UI console.
- [VelaUX](./quick-start) is an addon of KubeVela, with this addon enabled, it provides an out-of-box modern application Continuous Delivery (CD) and Management platform with an easy-to-use UI console.
## What's the relationship between OAM, KubeVela and VelaUX?

2
docusaurus.config.js
View File

@ -77,7 +77,7 @@ module.exports = {
items: [
{
label: "Getting Started",
to: "/docs/quick-start",
to: "/docs/end-user/quick-start-cli",
},
{
label: "Tutorials",

3
i18n/zh/docusaurus-plugin-content-docs/current/end-user/quick-start-cli.md
View File

@ -61,4 +61,5 @@ Hello World
## 下一步
* 组件和运维特征的部署只是 KubeVela 最基本的能力。接下来，我们通过学习[多集群应用部署](../case-studies/multi-cluster) 来更深入的了解策略和工作流的能力。
* 学习[多集群应用部署](../case-studies/multi-cluster)，除了组件和运维特征，了解策略系统和工作流带来的更丰富能力。
* 想要开箱即用的图形化交互体验？查看 [VelaUX](../quick-start) 了解图形化控制台的使用方式。

6
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/introduction.md
View File

@ -29,11 +29,11 @@ KubeVela 通过以下设计，使得面向混合/多云环境的应用交付变
![](../resources/vela-overview.jpg)
- 云原生应用平台的构建者、PaaS、Serverless 平台工程师、基础设施平台管理员：
- [Vela Core](../end-user/quick-start-cli) 是一个普适的、高可扩展的应用交付引擎与内核，它以极简的架构实现了原生 Kubernetes 多集群控制平面的能力，能够将 OAM 应用引擎直接植入企业已有的 PaaS 平台之中并不破坏已有的能力，从而实现标准化应用交付。
- [Vela Core](./end-user/quick-start-cli) 是一个普适的、高可扩展的应用交付引擎与内核，它以极简的架构实现了原生 Kubernetes 多集群控制平面的能力，能够将 OAM 应用引擎直接植入企业已有的 PaaS 平台之中并不破坏已有的能力，从而实现标准化应用交付。
- 第三方软件供应商（ISV）、垂直领域软件开发者、架构师：
- Vela 提供的充分的可扩展和集成能力，可以允许你[自定义插件](../platform-engineers/addon/intro) 完成复杂应用的构建和分发，是一个 Kubernetes 和云平台之上的应用商店（App Store）。
- Vela 提供的充分的可扩展和集成能力，可以允许你[自定义插件](./platform-engineers/addon/intro) 完成复杂应用的构建和分发，是一个 Kubernetes 和云平台之上的应用商店（App Store）。
- 云原生时代的应用研发、运维人员、DevOps 工程师：
- [VelaUX](../quick-start) 是一个基于 Vela Addon 机制构建的扩展能力集，安装这个插件后，你就拥有了一个开箱即用的现代化持续交付（CD）和应用管理平台。
- [VelaUX](./quick-start) 是一个基于 Vela Addon 机制构建的扩展能力集，安装这个插件后，你就拥有了一个开箱即用的现代化持续交付（CD）和应用管理平台。
## OAM、KubeVela 和 VelaUX 是什么关系？

27
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/README.md Normal file
View File

@ -0,0 +1,27 @@
![alt](resources/KubeVela-03.png)
*Make shipping applications more enjoyable.*
# KubeVela
KubeVela is a modern application engine that adapts to your application's needs, not the other way around.
## Community
- Slack: [CNCF Slack](https://slack.cncf.io/) #kubevela channel
- Gitter: [Discussion](https://gitter.im/oam-dev/community)
- Bi-weekly Community Call: [Meeting Notes](https://docs.google.com/document/d/1nqdFEyULekyksFHtFvgvFAYE-0AMHKoS3RMnaKsarjs)
## Installation
Installation guide is available on [this section](install).
## Quick Start
Quick start is available on [this section](quick-start).
## Contributing
Check out [CONTRIBUTING](https://github.com/oam-dev/kubevela/blob/master/CONTRIBUTING.md) to see how to develop with KubeVela.
## Code of Conduct
KubeVela adopts the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).

235
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/application-crd.md Normal file
View File

@ -0,0 +1,235 @@
---
title: Application CRD
---
本部分将逐步介绍如何使用 `Application` 对象来定义你的应用，并以声明式的方式进行相应的操作。
## 示例
下面的示例应用声明了一个具有 *Worker* 工作负载类型的 `backend` 组件和具有 *Web Service* 工作负载类型的 `frontend` 组件。
此外，`frontend`组件声明了具有 `sidecar` 和 `autoscaler` 的 `trait` 运维能力，这意味着工作负载将自动注入 `fluentd` 的sidecar，并可以根据CPU使用情况触发1-10个副本进行扩展。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: website
spec:
components:
- name: backend
type: worker
properties:
image: busybox
cmd:
- sleep
- '1000'
- name: frontend
type: webservice
properties:
image: nginx
traits:
- type: autoscaler
properties:
min: 1
max: 10
cpuPercent: 60
- type: sidecar
properties:
name: "sidecar-test"
image: "fluentd"
```
### 部署应用
部署上述的 application yaml文件, 然后应用启动
```shell
$ kubectl get application -o yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: website
....
status:
components:
- apiVersion: core.oam.dev/v1alpha2
kind: Component
name: backend
- apiVersion: core.oam.dev/v1alpha2
kind: Component
name: frontend
....
status: running
```
你可以看到一个命名为 `frontend` 并带有被注入的容器 `fluentd` 的 Deployment 正在运行。
```shell
$ kubectl get deploy frontend
NAME READY UP-TO-DATE AVAILABLE AGE
frontend 1/1 1 1 100m
```
另一个命名为 `backend` 的 Deployment 也在运行。
```shell
$ kubectl get deploy backend
NAME READY UP-TO-DATE AVAILABLE AGE
backend 1/1 1 1 100m
```
同样被 `autoscaler` trait 创建出来的还有一个 HPA 。
```shell
$ kubectl get HorizontalPodAutoscaler frontend
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
frontend Deployment/frontend <unknown>/50% 1 10 1 101m
```
## 背后的原理
在上面的示例中, `type: worker` 指的是该组件的字段内容（即下面的 `properties` 字段中的内容）将遵从名为 `worker` 的 `ComponentDefinition` 对象中的规范定义，如下所示：
```yaml
apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
name: worker
annotations:
definition.oam.dev/description: "Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic."
spec:
workload:
definition:
apiVersion: apps/v1
kind: Deployment
schematic:
cue:
template: |
output: {
apiVersion: "apps/v1"
kind: "Deployment"
spec: {
selector: matchLabels: {
"app.oam.dev/component": context.name
}
template: {
metadata: labels: {
"app.oam.dev/component": context.name
}
spec: {
containers: [{
name: context.name
image: parameter.image
if parameter["cmd"] != _|_ {
command: parameter.cmd
}
}]
}
}
}
}
parameter: {
image: string
cmd?: [...string]
}
```
因此，`backend` 的 `properties` 部分仅支持两个参数：`image` 和 `cmd`。这是由定义的 `.spec.template` 字段中的 `parameter` 列表执行的。
类似的可扩展抽象机制也同样适用于 traits(运维能力)。
例如，`frontend` 中的 `type：autoscaler` 指的是组件对应的 trait 的字段规范（即 trait 的 `properties` 部分）
将由名为 `autoscaler` 的 `TraitDefinition` 对象执行，如下所示：
```yaml
apiVersion: core.oam.dev/v1beta1
kind: TraitDefinition
metadata:
annotations:
definition.oam.dev/description: "configure k8s HPA for Deployment"
name: hpa
spec:
appliesToWorkloads:
- webservice
- worker
schematic:
cue:
template: |
outputs: hpa: {
apiVersion: "autoscaling/v2beta2"
kind: "HorizontalPodAutoscaler"
metadata: name: context.name
spec: {
scaleTargetRef: {
apiVersion: "apps/v1"
kind: "Deployment"
name: context.name
}
minReplicas: parameter.min
maxReplicas: parameter.max
metrics: [{
type: "Resource"
resource: {
name: "cpu"
target: {
type: "Utilization"
averageUtilization: parameter.cpuUtil
}
}
}]
}
}
parameter: {
min: *1 | int
max: *10 | int
cpuUtil: *50 | int
}
```
应用同样有一个`sidecar`的运维能力
```yaml
apiVersion: core.oam.dev/v1beta1
kind: TraitDefinition
metadata:
annotations:
definition.oam.dev/description: "add sidecar to the app"
name: sidecar
spec:
appliesToWorkloads:
- webservice
- worker
schematic:
cue:
template: |-
patch: {
// +patchKey=name
spec: template: spec: containers: [parameter]
}
parameter: {
name: string
image: string
command?: [...string]
}
```
在业务用户使用之前，我们认为所有用于定义的对象（Definition Object）都已经由平台团队声明并安装完毕了。所以，业务用户将需要专注于应用（`Application`）本身。
请注意，KubeVela 的终端用户（业务研发）不需要了解定义对象，他们只需要学习如何使用平台已经安装的能力，这些能力通常还可以被可视化的表单展示出来（或者通过 JSON schema 对接其他方式）。请从[由定义生成前端表单](/docs/platform-engineers/openapi-v3-json-schema)部分的文档了解如何实现。
### 惯例和"标准协议"
在应用（`Application` 资源）部署到 Kubernetes 集群后，KubeVela 运行时将遵循以下 “标准协议”和惯例来生成和管理底层资源实例。
| Label | 描述 |
| :--: | :---------: |
|`workload.oam.dev/type=<component definition name>` | 其对应 `ComponentDefinition` 的名称 |
|`trait.oam.dev/type=<trait definition name>` | 其对应 `TraitDefinition` 的名称 |
|`app.oam.dev/name=<app name>` | 它所属的应用的名称 |
|`app.oam.dev/component=<component name>` | 它所属的组件的名称 |
|`trait.oam.dev/resource=<name of trait resource instance>` | 运维能力资源实例的名称 |
|`app.oam.dev/appRevision=<name of app revision>` | 它所属的应用revision的名称 |

211
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/case-studies/canary-blue-green.md Normal file
View File

@ -0,0 +1,211 @@
---
title: 基于 Istio 的渐进式发布
---
## 简介
KubeVela 后的应用交付模型（OAM）是一个从设计与实现上都高度可扩展的模型。因此，KubeVela 不需要任何“脏乱差”的胶水代码或者脚本就可以同任何云原生技术和工具（比如 Service Mesh）实现集成，让社区生态中各种先进技术立刻为你的应用交付助上“一臂之力”。
本文将会介绍如何使用 KubeVela 结合 [Istio](https://istio.io/latest/) 进行复杂的金丝雀发布流程。在这个过程中，KubeVela 会帮助你：
- 将 Istio 的能力进行封装和抽象后再交付给用户使用，使得用户无需成为 Istio 专家就可以直接使用这个金丝雀发布的场景（KubeVela 会为你提供一个封装好的 Rollout 运维特征）
- 通过声明式工作流来设计金丝雀发布的步骤，以及执行发布/回滚，而无需通过“脏乱差”的脚本或者人工的方式管理这个过程。
本案例中，我们将使用经典的微服务应用 [bookinfo](https://istio.io/latest/docs/examples/bookinfo/?ie=utf-8&hl=en&docs-search=Canary) 来展示上述金丝雀发布过程。
## 准备工作
如果你的集群尚未安装 Istio，你可以通过以下命令，开启 Istio 集群插件
```shell
vela addon enable istio
```
如果你的集群已经安装 Istio，你只需 apply [该目录](https://github.com/oam-dev/kubevela/tree/master/vela-templates/addons/istio/definitions) 下的四个 YAML 文件来达到和上面开启集群插件一样的效果
因为后面的例子运行在 default namespace，需要为 default namespace 打上 Istio 自动注入 sidecar 的标签。
```shell
kubectl label namespace default istio-injection=enabled
```
## 初次部署
执行下面的命令，部署 bookinfo 应用。
```shell
vela up -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/canary-rollout-use-case/first-deploy.yaml
```
该应用的组件架构和访问关系如下所示：
![book-info-struct](../resources/book-info-struct.jpg)
该应用包含四个组件，其中组件 pruductpage, details, ratings 均配置了一个暴露端口 (expose) 运维特征用来在集群内暴露服务。
组件 reviews 配置了一个金丝雀流量发布 (canary-traffic) 的运维特征。
productpage 组件还配置了一个 网关入口 (istio-gateway) 的运维特征，从而让该组件接收进入集群的流量。这个运维特征通过设置 `gateway:ingressgateway` 来使用 Istio 的默认网关实现，设置 `hosts: "*"` 来指定携带任意 host 信息的请求均可进入网关。
```shell
...
- name: productpage
type: webservice
properties:
image: docker.io/istio/examples-bookinfo-productpage-v1:1.16.2
port: 9080
traits:
- type: expose
properties:
port:
- 9080
- type: istio-gateway
properties:
hosts:
- "*"
gateway: ingressgateway
match:
- exact: /productpage
- prefix: /static
- exact: /login
- prefix: /api/v1/products
port: 9080
...
```
你可以通过执行下面的命令将网关的端口映射到本地。
```shell
kubectl port-forward service/istio-ingressgateway -n istio-system 19082:80
```
通过浏览器访问 http://127.0.0.1:19082/productpage 将会看到下面的页面。
![pic-v2](../resources/canary-pic-v2.jpg)
## 金丝雀发布
接下来我们以 `reviews` 组件为例，模拟一次金丝雀发布的完整过程，及先升级一部分组件实例，同时调整流量，以此达到渐进式灰度发布的目的。
执行下面的命令，来更新应用。
```shell
vela up -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/canary-rollout-use-case/rollout-v2.yaml
```
这次操作更新了 reviews 组件的镜像，从之前的 v2 升级到了 v3。同时 reviews 组件的灰度发布 (Rollout) 运维特征指定了，升级的目标实例个数为 2 个，分两个批次升级，每批升级 1 个实例。
```shell
...
- name: reviews
type: webservice
properties:
image: docker.io/istio/examples-bookinfo-reviews-v3:1.16.2
port: 9080
volumes:
- name: wlp-output
type: emptyDir
mountPath: /opt/ibm/wlp/output
- name: tmp
type: emptyDir
mountPath: /tmp
traits:
- type: expose
properties:
port:
- 9080
- type: rollout
properties:
targetSize: 2
rolloutBatches:
- replicas: 1
- replicas: 1
- type: canary-traffic
properties:
port: 9080
...
```
这次更新还为应用新增了一个升级的执行工作流，该工作流包含三个步骤。
第一步通过指定 `batchPartition` 等于 0 设置只升级第一批次的实例。并通过 `traffic.weightedTargets` 将 10% 的流量切换到新版本的实例上面。
完成第一步之后，执行第二步工作流会进入暂停状态，等待用户校验服务状态。
工作流的第三步是完成剩下实例的升级，并将全部流量切换致新的组件版本上。
```shell
...
workflow:
steps:
- name: rollout-1st-batch
type: canary-rollout
properties:
# just upgrade first batch of component
batchPartition: 0
traffic:
weightedTargets:
- revision: reviews-v1
weight: 90 # 90% shift to new version
- revision: reviews-v2
weight: 10 # 10% shift to new version
# give user time to verify part of traffic shifting to newRevision
- name: manual-approval
type: suspend
- name: rollout-rest
type: canary-rollout
properties:
# upgrade all batches of component
batchPartition: 1
traffic:
weightedTargets:
- revision: reviews-v2
weight: 100 # 100% shift to new version
...
```
更新完成之后，再在浏览器多次访问之前的网址。发现有大概10%的概率会看到下面这个新的页面，
![pic-v3](../resources/canary-pic-v3.jpg)
可见新版本的页面由之前的黑色五角星变成了红色五角星
### 继续完成全量发布
如果在人工校验时，发现服务符合预期，需要继续执行工作流，完成全量发布。你可以通过执行下面的命令完成这一操作。
```shell
vela workflow resume book-info
```
在浏览器上继续多次访问网页，会发现五角星将一直是红色的。
### 终止发布工作流并回滚
如果在人工校验时，发现服务不符合预期，需要终止预先定义好的发布工作流，并将流量和实例切换回之前的版本。你可以通过执行下面的命令完成这一操作：
```shell
vela up -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/canary-rollout-use-case/rollback.yaml
```
这个操作将会更新 Workflow 定义去使用 `canary-rollback` step：
```yaml
...
workflow:
steps:
- name: rollback
type: canary-rollback
```
此次操作的原理是：
- 更新 Rollout 对象的 `targetRevisionName` 成旧的版本，这样会自动回滚所有已发布的新版本的实例回到旧版本，并且保持还没升级的旧版本实例。
- 更新 VirtualService 对象的 `route` 字段，将所有流量导向旧的版本。
- 更新 DestinationRule 对象的 `subset` 字段，只容纳旧的版本。
看到了吗？这么多操作，但是暴露给用户的只有一个简单的 step 定义，全部复杂的操作都并抽象化在背后自动运行！
在浏览器上继续访问网址，会发现五角星又变回到了黑色。

405
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/case-studies/gitops.md Normal file
View File

@ -0,0 +1,405 @@
---
title: GitOps 交付
---
本案例将介绍如何在 GitOps 场景下使用 KubeVela，并介绍这样做的好处是什么。
## 简介
GitOps 是一种现代化的持续交付手段，它允许开发人员通过直接更改 Git 仓库中的代码和配置来自动部署应用，在提高部署生产力的同时也通过分支回滚等能力提高了可靠性。其具体的好处可以查看[这篇文章](https://www.weave.works/blog/what-is-gitops-really)，本文将不再赘述。
KubeVela 作为一个声明式的应用交付控制平面，天然就可以以 GitOps 的方式进行使用，并且这样做会在 GitOps 的基础上为用户提供更多的益处和端到端的体验，包括：
- 应用交付工作流（CD 流水线）
- 即：KubeVela 支持在 GitOps 模式中描述过程式的应用交付，而不只是简单的声明终态；
- 处理部署过程中的各种依赖关系和拓扑结构；
- 在现有各种 GitOps 工具的语义之上提供统一的上层抽象，简化应用交付与管理过程；
- 统一进行云服务的声明、部署和服务绑定；
- 提供开箱即用的交付策略（金丝雀、蓝绿发布等）；
- 提供开箱即用的混合云/多云部署策略（放置规则、集群过滤规则等）；
- 在多环境交付中提供 Kustomize 风格的 Patch 来描述部署差异，而无需学习任何 Kustomize 本身的细节；
- …… 以及更多。
在本文中，我们主要讲解直接使用 KubeVela 在 GitOps 模式下进行交付的步骤。
交付的面向人员有以下两种，我们将分别介绍：
1. 面向平台管理员/运维人员的基础设施交付，用户可以通过直接更新仓库中的配置文件，从而更新集群中的基础设施配置，如系统的依赖软件、安全策略、存储、网络等基础设施配置。
2. 面向终端开发者的交付，用户的代码一旦合并到应用代码仓库，就自动化触发集群中应用的更新，可以更高效的完成应用的迭代，与 KubeVela 的灰度发布、流量调拨、多集群部署等功能结合可以形成更为强大的自动化发布能力。
> 提示：你也可以通过类似的步骤使用 ArgoCD 等 GitOps 工具来间接使用 KubeVela，细节的操作文档我们会在后续发布中提供。
## 面向平台管理员/运维人员的交付
如图所示，对于平台管理员/运维人员而言，他们并不需要关心应用的代码，所以只需要准备一个 Git 配置仓库并部署 KubeVela 配置文件，后续对于应用及基础设施的配置变动，便可通过直接更新 Git 配置仓库来完成，使得每一次配置变更可追踪。
![alt](../resources/ops-flow.jpg)
### 准备配置仓库
> 具体的配置可参考 [示例仓库](https://github.com/oam-dev/samples/tree/master/9.GitOps_Demo/for-SREs)。
在本例中，我们将部署一个 MySQL 数据库软件作为项目的基础设施，同时部署一个业务应用，使用这个数据库。配置仓库的目录结构如下:
* `clusters/` 中包含集群中的 KubeVela GitOps 配置，用户需要将 `clusters/` 中的文件手动部署到集群中。这个是一次性的管控操作，执行完成后，KubeVela 便能自动监听配置仓库中的文件变动且自动更新集群中的配置。其中，`clusters/apps.yaml` 将监听 `apps/` 下所有应用的变化，`clusters/infra.yaml` 将监听 `infrastructure/` 下所有基础设施的变化。
* `apps/` 目录中包含业务应用的所有配置，在本例中为一个使用数据库的业务应用。
* `infrastructure/` 中包含一些基础设施相关的配置和策略，在本例中为 MySQL 数据库。
```shell
├── apps
│   └── my-app.yaml
├── clusters
│   ├── apps.yaml
│   └── infra.yaml
└── infrastructure
└── mysql.yaml
```
> KubeVela 建议使用如上的目录结构管理你的 GitOps 仓库。`clusters/` 中存放相关的 KubeVela GitOps 配置并需要被手动部署到集群中，`apps/` 和 `infrastructure/` 中分别存放你的应用和基础设施配置。通过把应用和基础配置分开，能够更为合理的管理你的部署环境，隔离应用的变动影响。
#### `clusters/` 目录
首先，我们来看下 clusters 目录，这也是 KubeVela 对接 GitOps 的初始化操作配置目录
以 `clusters/infra.yaml` 为例：
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: infra
spec:
components:
- name: database-config
type: kustomize
properties:
repoType: git
# 将此处替换成你需要监听的 git 配置仓库地址
url: https://github.com/FogDong/KubeVela-GitOps-Infra-Demo
# 如果是私有仓库，还需要关联 git secret
# secretRef: git-secret
# 自动拉取配置的时间间隔，由于基础设施的变动性较小，此处设置为十分钟
pullInterval: 10m
git:
# 监听变动的分支
branch: main
# 监听变动的路径，指向仓库中 infrastructure 目录下的文件
path: ./infrastructure
```
`apps.yaml` 与 `infra.yaml` 几乎保持一致，只不过监听的文件目录有所区别。
在 `apps.yaml` 中，`properties.path` 的值将改为 `./apps`，表明监听 `apps/` 目录下的文件变动。
cluster 文件夹中的 GitOps 管控配置文件需要在初始化的时候一次性手动部署到集群中，在此之后 KubeVela 将自动监听 `apps/` 以及 `infrastructure/` 目录下的配置文件并定期更新同步。
#### `apps/` 目录
`apps/` 目录中存放着应用配置文件，这是一个配置了数据库信息以及 Ingress 的简单应用。该应用将连接到一个 MySQL 数据库，并简单地启动服务。在默认的服务路径下，会显示当前版本号。在 `/db` 路径下，会列出当前数据库中的信息。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: my-app
namespace: default
spec:
components:
- name: my-server
type: webservice
properties:
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412
port: 8088
env:
- name: DB_HOST
value: mysql-cluster-mysql.default.svc.cluster.local:3306
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: ROOT_PASSWORD
traits:
- type: ingress
properties:
domain: testsvc.example.com
http:
/: 8088
```
#### `infrastructure/` 目录
`infrastructure/` 目录下存放一些基础设施的配置。此处我们使用 [mysql controller](https://github.com/bitpoke/mysql-operator) 来部署了一个 MySQL 集群。
> 注意，请确保你的集群中有一个 secret，并通过 `ROOT_PASSWORD` 声明了 MySQL 密码。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: mysql
namespace: default
spec:
components:
- name: mysql-controller
type: helm
properties:
repoType: helm
url: https://presslabs.github.io/charts
chart: mysql-operator
version: "0.4.0"
- name: mysql-cluster
type: raw
dependsOn:
- mysql-controller
properties:
apiVersion: mysql.presslabs.org/v1alpha1
kind: MysqlCluster
metadata:
name: mysql-cluster
spec:
replicas: 1
# 关联 secret 名称
secretName: mysql-secret
```
#### 部署 `clusters/` 目录下的文件
配置完以上文件并存放到 Git 配置仓库后，我们需要在集群中手动部署 `clusters/` 目录下的 KubeVela GitOps 配置文件。
首先，在集群中部署 `clusters/infra.yaml`。可以看到它自动在集群中拉起了 `infrastructure/` 目录下的 MySQL 部署文件：
```shell
vela up -f clusters/infra.yaml
```
```shell
$ vela ls
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
```
接着，在集群中部署 `clusters/apps.yaml`，可以看到它自动拉起了 `apps/` 目录下的应用部署文件：
```shell
vela up -f clusters/apps.yaml
```
```shell
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
apps apps kustomize running healthy 2021-09-27 16:55:53 +0800 CST
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
my-app my-server webservice ingress running healthy 2021-09-27 16:55:55 +0800 CST
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
```
至此，我们通过部署 KubeVela GitOps 配置文件，自动在集群中拉起了应用及数据库。
通过 curl 应用的 Ingress，可以看到目前的版本是 0.1.5，并且成功地连接到了数据库：
```shell
$ kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
my-server <none> testsvc.example.com <ingress-ip> 80 162m
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>
Version: 0.1.5
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>/db
User: KubeVela
Description: It's a test user
```
### 修改配置
完成了首次部署后，我们可以通过修改配置仓库中的配置，来完成集群中应用的配置更新。
修改应用 Ingress 的 Domain：
```yaml
...
traits:
- type: ingress
properties:
domain: kubevela.example.com
http:
/: 8089
```
经过一段时间后，重新查看集群中的 Ingress：
```shell
NAME CLASS HOSTS ADDRESS PORTS AGE
my-server <none> kubevela.example.com <ingress-ip> 80 162m
```
可以看到，Ingress 的 Host 地址已被成功更新。
通过这种方式，我们可以方便地通过更新 Git 配置仓库中的文件，从而自动化更新集群中的配置。
## 面向终端开发者的交付
如图所示，对于终端开发者而言，在 KubeVela Git 配置仓库以外，还需要准备一个应用代码仓库。在用户更新了应用代码仓库中的代码后，需要配置一个 CI 来自动构建镜像并推送至镜像仓库中。KubeVela 会监听镜像仓库中的最新镜像，并自动更新配置仓库中的镜像配置，最后再更新集群中的应用配置。使用户可以达成在更新代码后，集群中的配置也自动更新的效果。
![alt](../resources/dev-flow.jpg)
### 准备代码仓库
准备一个代码仓库，里面包含一些源代码以及对应的 Dockerfile。
这些代码将连接到一个 MySQL 数据库，并简单地启动服务。在默认的服务路径下，会显示当前版本号。在 `/db` 路径下，会列出当前数据库中的信息。
```go
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
_, _ = fmt.Fprintf(w, "Version: %s\n", VERSION)
})
http.HandleFunc("/db", func(w http.ResponseWriter, r *http.Request) {
rows, err := db.Query("select * from userinfo;")
if err != nil {
_, _ = fmt.Fprintf(w, "Error: %v\n", err)
}
for rows.Next() {
var username string
var desc string
err = rows.Scan(&username, &desc)
if err != nil {
_, _ = fmt.Fprintf(w, "Scan Error: %v\n", err)
}
_, _ = fmt.Fprintf(w, "User: %s \nDescription: %s\n\n", username, desc)
}
})
if err := http.ListenAndServe(":8088", nil); err != nil {
panic(err.Error())
}
```
我们希望用户改动代码进行提交后，自动构建出最新的镜像并推送到镜像仓库。这一步 CI 可以通过集成 GitHub Actions、Jenkins 或者其他 CI 工具来实现。在本例中，我们通过借助 GitHub Actions 来完成持续集成。具体的代码文件及配置可参考 [示例仓库](https://github.com/oam-dev/samples/tree/master/9.GitOps_Demo/for-developers/app-code)。
### 配置秘钥信息
在新的镜像推送到镜像仓库后，KubeVela 会识别到新的镜像，并更新仓库及集群中的 `Application` 配置文件。因此，我们需要一个含有 Git 信息的 Secret，使 KubeVela 向 Git 仓库进行提交。部署如下文件，将其中的用户名和密码替换成你的 Git 用户名及密码（或 Token）：
```yaml
apiVersion: v1
kind: Secret
metadata:
name: git-secret
type: kubernetes.io/basic-auth
stringData:
username: <your username>
password: <your password>
```
### 准备配置仓库
配置仓库与之前面向运维人员的配置大同小异，只需要加上与镜像仓库相关的配置即可。具体配置请参考 [示例仓库](https://github.com/oam-dev/samples/tree/master/9.GitOps_Demo/for-developers/kubevela-config)。
修改 `clusters/` 中的 `apps.yaml`，该 GitOps 配置会监听仓库中 `apps/` 下的应用文件变动以及镜像仓库中的镜像更新：
```yaml
...
imageRepository:
# 镜像地址
image: <your image>
# 如果这是一个私有的镜像仓库，可以通过 `kubectl create secret docker-registry` 创建对应的镜像秘钥并相关联
# secretRef: imagesecret
filterTags:
# 可对镜像 tag 进行过滤
pattern: '^master-[a-f0-9]+-(?P<ts>[0-9]+)'
extract: '$ts'
# 通过 policy 筛选出最新的镜像 Tag 并用于更新
policy:
numerical:
order: asc
# 追加提交信息
commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"
```
修改 `apps/my-app.yaml` 中的 image 字段，在后面加上 `# {"$imagepolicy": "default:apps"}` 的注释。KubeVela 会通过该注释去更新对应的镜像字段。`default:apps` 是上面 GitOps 配置对应的命名空间和名称。
```yaml
spec:
components:
- name: my-server
type: webservice
properties:
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412 # {"$imagepolicy": "default:apps"}
```
将 `clusters/` 中包含镜像仓库配置的文件更新到集群中后，我们便可以通过修改代码来完成应用的更新。
### 修改代码
将代码文件中的 `Version` 改为 `0.1.6`，并修改数据库中的数据:
```go
const VERSION = "0.1.6"
...
func InsertInitData(db *sql.DB) {
stmt, err := db.Prepare(insertInitData)
if err != nil {
panic(err)
}
defer stmt.Close()
_, err = stmt.Exec("KubeVela2", "It's another test user")
if err != nil {
panic(err)
}
}
```
提交该改动至代码仓库，可以看到，我们配置的 CI 流水线开始构建镜像并推送至镜像仓库。
而 KubeVela 会通过监听镜像仓库，根据最新的镜像 Tag 来更新配置仓库中 `apps/` 下的应用 `my-app`。
此时，可以看到配置仓库中有一条来自 `kubevelabot` 的提交，提交信息均带有 `Update image automatically.` 前缀。你也可以通过 `{{range .Updated.Images}}{{println .}}{{end}}` 在 `commitMessage` 字段中追加你所需要的信息。
![alt](../resources/gitops-commit.png)
> 值得注意的是，如果你希望将代码和配置放在同一个仓库，需要过滤掉来自 `kubevelabot` 的提交来防止流水线的重复构建。可以在 CI 中通过如下配置过滤：
>
> ```shell
> jobs:
> publish:
> if: "!contains(github.event.head_commit.message, 'Update image automatically')"
> ```
重新查看集群中的应用，可以看到经过一段时间后，应用 `my-app` 的镜像已经被更新。
> KubeVela 会通过你配置的 `interval` 时间间隔，来每隔一段时间分别从配置仓库及镜像仓库中获取最新信息：
> * 当 Git 仓库中的配置文件被更新时，KubeVela 将根据最新的配置更新集群中的应用。
> * 当镜像仓库中多了新的 Tag 时，KubeVela 将根据你配置的 policy 规则，筛选出最新的镜像 Tag，并更新到 Git 仓库中。而当代码仓库中的文件被更新后，KubeVela 将重复第一步，更新集群中的文件，从而达到了自动部署的效果。
通过 `curl` 对应的 `Ingress` 查看当前版本和数据库信息：
```shell
$ kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
my-server <none> kubevela.example.com <ingress-ip> 80 162m
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>
Version: 0.1.6
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>/db
User: KubeVela
Description: It's a test user
User: KubeVela2
Description: It's another test user
```
版本已被成功更新！至此，我们完成了从变更代码，到自动部署至集群的全部操作。
## 总结
在运维侧，如若需要更新基础设施（如数据库）的配置，或是应用的配置项，只需要修改配置仓库中的文件，KubeVela 将自动把配置同步到集群中，简化了部署流程。
在研发侧，用户修改代码仓库中的代码后，KubeVela 将自动更新配置仓库中的镜像。从而进行应用的版本更新。
通过与 GitOps 的结合，KubeVela 加速了应用从开发到部署的整个流程。

233
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/case-studies/initialize-env.md Normal file
View File

@ -0,0 +1,233 @@
---
title: 一键创建/销毁环境
---
本章将介绍如何使用 KubeVela 在交付应用时对环境进行快速初始化和销毁。
## 环境指什么？
一个应用开发团队通常需要做一些初始化工作来满足应用部署时方方面面的需要，即“初始化环境”。
这里的环境是一个逻辑概念，既可以表示应用部署时依赖的公共资源，也可以表示应用运行必要的准备工作。
KubeVela 同样是 Application 对象做环境的初始化，可以初始化的资源类型包括但不限于下列类型：
1. 一个或多个 Kubernetes 集群，不同的环境可能需要不同规模和不同版本的 Kubernetes 集群。同时环境初始化还可以将多个 Kubernetes 集群注册到一个中央集群进行统一的多集群管控。
2. 任意类型的 Kubernetes 自定义资源（CRD）和系统插件，一个环境会拥有很多种不同的自定义资源来提供系统能力，比如不同的工作负载、不同的运维管理功能等等。初始化环境可以包含环境所依赖的一系列功能的初始化安装，比如各类中间件工作负载、流量管理、日志监控等各类运维系统。
3. 各类共享资源和服务，一个微服务在不同环境中测试验证时，除了自身所开发的组件以外，往往还会包含一系列其他团队维护的组件和一些公共资源。环境初始化功能可以将其他组件和公共资源统一部署，在无需使用时销毁。这些共享资源可以是一个微服务组件、云数据库、缓存、负载均衡、API网关等等。
4. 各类管理策略和流程，一个环境可能会配备不同的全局策略和流程，举例来说，环境策略可能会包括混沌测试、安全扫描、错误配置检测、SLO指标等等；而流程则可以是初始化一个数据库表、注册一个自动发现配置等。
不仅如此，KubeVela 的环境初始化能力还可以跟工作流、策略、依赖等功能相结合，做不同环境的差异化部署，依赖管理等。
若不同环境初始化存在依赖关系，可以初始化的公共资源分离出一个单独的 Application 作为依赖，这样可以形成可以被复用的初始化模块。
例如，测试环境和开发环境都依赖了一些相同的控制器，可以将这些控制器提取出来作为单独的环境初始化，在开发环境和测试环境中都指定依赖该环境初始化。
## 如何使用
### 直接使用应用部署计划完成环境初始化
> 请确保你的 KubeVela 版本在 v1.1.6 及以上。
如果我们希望在环境中使用一个自定义 CRD 控制器(如 [OpenKruise](https://github.com/openkruise/kruise))，那么，我们可以使用 Helm 组件初始化 kruise。
我们可以直接使用 KubeVela 的应用部署计划来初始化 kruise 的环境，该应用会帮你在集群中部署一个 OpenKruise 的控制器，给集群提供 kruise 的各种能力。
由于我们使用 Helm 组件完成 kruise 的部署，我们首先要在集群中使用 `fluxcd` 开启 helm 功能。
当环境初始化具备多个模块时，可以对初始化的内容进行拆分，同时使用工作流的 `depends-on-app` 步骤，描述不同初始化模块的依赖关系。
比如我们可以在这个例子里，使用 `depends-on-app` 表示环境初始化 kruise 依赖环境初始化 fluxcd 提供的能力。
> `depends-on-app` 会根据 `properties` 中的 `name` 及 `namespace`，去查询集群中是否存在对应的应用。
如果应用存在，则当该应用的状态可用时，才会进行下一个步骤；
若该应用不存在，则会去查询同名的 configMap，从中读取出应用的配置并部署到集群中。
> 更详细的说明，请查看 [depends-on-app](../end-user/workflow/built-in-workflow-defs#depends-on-app)。
部署如下文件：
```shell
cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: kruise
namespace: vela-system
spec:
components:
- name: kruise
type: helm
properties:
branch: master
chart: ./charts/kruise/v0.9.0
version: "*"
repoType: git
url: https://github.com/openkruise/kruise
workflow:
steps:
- name: check-flux
type: depends-on-app
properties:
name: fluxcd
namespace: vela-system
- name: apply-kruise
type: apply-component
properties:
component: kruise
EOF
```
查看集群中应用的状态：
```shell
$ vela ls -n vela-system
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
kruise ... raw running healthy 2021-09-24 20:59:06 +0800 CST
fluxcd ... raw running healthy 2021-09-24 20:59:06 +0800 CST
```
kruise 已经成功运行！之后，你可以在环境中使用 kruise 的能力。如果需要配置新的环境初始化，也只需要类似的定义一个部署计划。
### 在应用部署中加入初始化的工作流
在环境中，一些通用的 ConfigMap / PVC 等资源是十分常用的。
如果你希望在部署应用前内置一些通用资源，可以在应用部署中加入初始化的工作流来完成。
KubeVela 提供了一个内置的工作流步骤 `apply-object`，可以直接在组件的 `properties` 字段中填写创建到环境中的原生 Kubernetes 资源。
这种在 Application 中直接填写 Kubernetes 原生资源的方式，可以避免编写多余的组件定义（ComponentDefinition）。
部署如下应用，初始化一个带有 ConfigMap / PVC 的环境。同时，部署两个组件，第一个组件会不断向 PVC 中写入数据，第二个组件会读取 PVC 中的数据：
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: server-with-pvc-and-cm
namespace: default
spec:
components:
- name: log-gen-worker
type: worker
properties:
image: busybox
cmd:
- /bin/sh
- -c
- >
i=0;
while true;
do
echo "$i: $(date)" >> /test-pvc/date.log;
i=$((i+1));
sleep 1;
done
volumes:
- name: "my-pvc"
type: "pvc"
mountPath: "/test-pvc"
claimName: "my-claim"
- name: "my-configmap"
type: "configMap"
mountPath: "/test-cm"
cmName: "my-cm"
items:
- key: test-key
path: test-key
- name: log-read-worker
type: worker
properties:
name: count-log
image: busybox
cmd:
- /bin/sh
- -c
- 'tail -n+1 -f /test-pvc/date.log'
volumes:
- name: "my-pvc"
type: "pvc"
mountPath: "/test-pvc"
claimName: "my-claim"
- name: "my-configmap"
type: "configMap"
mountPath: "/test-cm"
cmName: "my-cm"
items:
- key: test-key
path: test-key
workflow:
steps:
- name: apply-pvc
type: apply-object
properties:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-claim
namespace: default
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 8Gi
storageClassName: standard
- name: apply-cm
type: apply-object
properties:
apiVersion: v1
kind: ConfigMap
metadata:
name: my-cm
namespace: default
data:
test-key: test-value
- name: apply-remaining
type: apply-remaining
```
查看集群中的 PVC 以及 ConfigMap：
```shell
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
my-claim Bound pvc-2621d7d7-453c-41df-87fb-58e6b3a8e136 8Gi RWO standard 2m53s
$ kubectl get cm
NAME DATA AGE
my-cm 1 3m8s
```
查看集群中应用的状态：
```shell
$ vela ls
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
server-with-pvc-and-cm log-gen-worker worker running healthy 2021-10-11 20:42:38 +0800 CST
└─ log-read-worker worker running 2021-10-11 20:42:38 +0800 CST
```
检查第二个组件的日志输出：
```shell
$ kubectl logs -f log-read-worker-774b58f565-ch8ch
0: Mon Oct 11 12:43:01 UTC 2021
1: Mon Oct 11 12:43:02 UTC 2021
2: Mon Oct 11 12:43:03 UTC 2021
3: Mon Oct 11 12:43:04 UTC 2021
4: Mon Oct 11 12:43:05 UTC 2021
5: Mon Oct 11 12:43:06 UTC 2021
6: Mon Oct 11 12:43:07 UTC 2021
7: Mon Oct 11 12:43:08 UTC 2021
```
可以看到，应用中的两个组件均已正常运行。同时，这两个组件共享同一个 PVC，并使用相同的 ConfigMap 进行配置。
## 如何销毁环境
因为我们已经通过应用（Application）这个统一的模型做了环境初始化，所以销毁环境变得非常简单，只需要删除这个应用即可。
```
vela delete server-with-pvc-and-cm
```
KubeVela 控制器会自动将资源删除。

153
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/case-studies/jenkins-cicd.md Normal file
View File

@ -0,0 +1,153 @@
---
title: Jenkins CI 集成
---
本文将介绍如何使用 KubeVela 同已有的 CI 工具（比如 Jenkins）共同协作来进行应用的持续交付，并解释这样集成的好处是什么。
## 简介
KubeVela 作为一个普适的应用交付控制平面，只需要一点点集成工作就可以同任何现有的 CI/CD 系统对接起来，并且为它们带来一系列现代云原生应用交付的能力，比如：
- 混合云/多云应用交付；
- 跨环境发布（Promotion）；
- 基于 Service Mesh 的发布与回滚；
- 处理部署过程中的各种依赖关系和拓扑结构；
- 统一进行云服务的声明、部署和服务绑定；
- 无需强迫你的团队采纳完整的 GitOps 协作方式即可享受 GitOps 技术本身的[一系列好处](https://www.weave.works/blog/what-is-gitops-really)；
- …… 以及更多。
接下来，本文将会以一个 HTTP 服务的开发部署为例，介绍 KubeVela + Jenkins 方式下应用的持续集成与持续交付步骤。这个应用的具体代码在[这个 GitHub 库中](https://github.com/Somefive/KubeVela-demo-CICD-app)。
## 准备工作
在对接之前，用户首先需要确保以下环境。
1. 已部署好 Jenkins 服务并配置了 Docker 在 Jenkins 中的环境，包括相关插件及镜像仓库的访问权限。
2. 已配置好的 Git 仓库并开启 Webhook。确保 Git 仓库对应分支的变化能够通过 Webhook 触发 Jenkins 流水线的运行。
3. 准备好需要部署的 Kubernetes 集群环境，并在环境中安装 KubeVela 基础组件及 apiserver，确保 KubeVela apiserver 能够从公网访问到。
## 对接 Jenkins 与 KubeVela apiserver
在 Jenkins 中以下面的 Groovy 脚本为例设置部署流水线。可以将流水线中的 Git 地址、镜像地址、apiserver 的地址、应用命名空间及应用替换成自己的配置，同时在自己的代码仓库中存放 Dockerfile 及 app.yaml，用来构建及部署 KubeVela 应用。
```groovy
pipeline {
agent any
environment {
GIT_BRANCH = 'prod'
GIT_URL = 'https://github.com/Somefive/KubeVela-demo-CICD-app.git'
DOCKER_REGISTRY = 'https://registry.hub.docker.com'
DOCKER_CREDENTIAL = 'DockerHubCredential'
DOCKER_IMAGE = 'somefive/kubevela-demo-cicd-app'
APISERVER_URL = 'http://47.88.24.19'
APPLICATION_YAML = 'app.yaml'
APPLICATION_NAMESPACE = 'kubevela-demo-namespace'
APPLICATION_NAME = 'cicd-demo-app'
}
stages {
stage('Prepare') {
steps {
script {
def checkout = git branch: env.GIT_BRANCH, url: env.GIT_URL
env.GIT_COMMIT = checkout.GIT_COMMIT
env.GIT_BRANCH = checkout.GIT_BRANCH
echo "env.GIT_BRANCH=${env.GIT_BRANCH},env.GIT_COMMIT=${env.GIT_COMMIT}"
}
}
}
stage('Build') {
steps {
script {
docker.withRegistry(env.DOCKER_REGISTRY, env.DOCKER_CREDENTIAL) {
def customImage = docker.build(env.DOCKER_IMAGE)
customImage.push()
}
}
}
}
stage('Deploy') {
steps {
sh 'wget -q "https://github.com/mikefarah/yq/releases/download/v4.12.1/yq_linux_amd64"'
sh 'chmod +x yq_linux_amd64'
script {
def app = sh (
script: "./yq_linux_amd64 eval -o=json '.spec' ${env.APPLICATION_YAML} | sed -e 's/GIT_COMMIT/$GIT_COMMIT/g'",
returnStdout: true
)
echo "app: ${app}"
def response = httpRequest acceptType: 'APPLICATION_JSON', contentType: 'APPLICATION_JSON', httpMode: 'POST', requestBody: app, url: "${env.APISERVER_URL}/v1/namespaces/${env.APPLICATION_NAMESPACE}/applications/${env.APPLICATION_NAME}"
println('Status: '+response.status)
println('Response: '+response.content)
}
}
}
}
}
```
之后向流水线中使用的 Git 仓库的分支推送代码变更，Git 仓库的 Webhook 会触发 Jenkins 中新创建的流水线。该流水线会自动构建代码镜像并推送至镜像仓库，然后对 KubeVela apiserver 发送 POST 请求，将仓库中的应用配置文件部署到 Kubernetes 集群中。其中 app.yaml 可以参照以下样例。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: kubevela-demo-app
spec:
components:
- name: kubevela-demo-app-web
type: webservice
properties:
image: somefive/kubevela-demo-cicd-app
imagePullPolicy: Always
port: 8080
traits:
- type: rollout
properties:
rolloutBatches:
- replicas: 2
- replicas: 3
batchPartition: 0
targetSize: 5
- type: labels
properties:
jenkins-build-commit: GIT_COMMIT
- type: ingress
properties:
domain: <your domain>
http:
"/": 8088
```
其中 GIT_COMMIT 会在 Jenkins 流水线中被替换为当前的 git commit id。这时可以通过 kubectl 命令查看 Kubernetes 集群中应用的部署情况。
```bash
$ kubectl get app -n kubevela-demo-namespace
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
cicd-demo-app kubevela-demo-app-web webservice running true 102s
$ kubectl get deployment -n kubevela-demo-namespace
NAME READY UP-TO-DATE AVAILABLE AGE
kubevela-demo-app-web-v1 2/2 2 2 111s
$ kubectl get ingress -n kubevela-demo-namespace
NAME CLASS HOSTS ADDRESS PORTS AGE
kubevela-demo-app-web <none> <your domain> 198.11.175.125 80 117s
```
在部署的应用文件中，我们使用了灰度发布(Rollout)的特性，应用初始发布先创建 2 个 Pod，以便进行金丝雀验证。待验证完毕，你可以将应用配置中 Rollout 特性的 `batchPatition: 0` 删去，以便完成剩余实例的更新发布。这个机制大大提高发布的安全性和稳定性，同时你也可以根据实际需要，调整 Rollout 发布策略。
```bash
$ kubectl edit app -n kubevela-demo-namespace
application.core.oam.dev/cicd-demo-app edited
$ kubectl get deployment -n kubevela-demo-namespace
NAME READY UP-TO-DATE AVAILABLE AGE
kubevela-demo-app-web-v1 5/5 5 5 4m16s
$ curl http://<your domain>/
Version: 0.1.2
```
## 更多
详细的环境部署流程以及更加完整的应用滚动更新可以参考[博客](/blog/2021/09/02/kubevela-jenkins-cicd)。
## 下一步
- 学习 KubeVela 在 [GitOps](./gitops) 场景下的对接和使用方式。

572
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/case-studies/li-auto-inc.md Normal file
View File

@ -0,0 +1,572 @@
---
title: 实践案例-理想汽车
---
## 背景
理想汽车后台服务采用的是微服务架构，虽然借助 Kubernetes 进行部署，但运维工作依然很复杂。并具有以下特点：
- 一个应用能运行起来并对外提供服务，正常情况下都需要配套的db实例以及 redis 集群支撑。
- 应用之间存在依赖关系，对于部署顺序有比较强的诉求。
- 应用部署流程中需要和外围系统（如：配置中心）交互。
下面以一个理想汽车的经典场景为例，介绍如何借助 KubeVela 实现以上诉求。
## 典型场景介绍
![场景架构](../resources/li-auto-inc.jpg)
这里面包含两个应用，分别是 `base-server` 和 `proxy-server`, 整体应用部署需要满足以下条件：
- base-server 成功启动（状态 ready）后需要往配置中心（apollo）注册信息。
- base-server 需要绑定到 service 和 ingress 进行负载均衡。
- proxy-server 需要在 base-server 成功运行后启动，并需要获取到 base-server 对应的 service 的 clusterIP。
- proxy-server 依赖 redis 中间件，需要在 redis 成功运行后启动。
- proxy-server 需要从配置中心（apollo）读取 base-server 的相关注册信息。
可见整个部署过程，如果人为操作，会变得异常困难以及容易出错。在借助 KubeVela 后，可以轻松实现场景的自动化和一键式运维。
## 解决方案
在 KubeVela 上，以上诉求可以拆解为以下 KubeVela 的模型：
- 组件部分: 包含三个分别是 base-server 、redis 、proxy-server。
- 运维特征: ingress (包括 service) 作为一个通用的负载均衡运维特征。
- 工作流: 实现组件按照依赖进行部署，并实现和配置中心的交互。
- 应用部署计划: 理想汽车的开发者可以通过 KubeVela 的应用部署计划完成应用发布。
详细过程如下:
## 平台的功能定制
理想汽车的平台工程师通过以下步骤完成方案中所涉及的能力，并向开发者用户透出（通过编写 definition 的方式实现）。
### 1.定义组件
- 编写 base-service 的组件定义，使用 `Deployment` 作为工作负载，并向终端用户透出参数 `image` 和 `cluster`。对于终端用户来说，之后在发布时只需要关注镜像以及部署的集群名称。
- 编写 proxy-service 的组件定义，使用 `argo rollout` 作为工作负载，同样向终端用户透出参数 `image` 和 `cluster`。
如下所示：
```
apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
name: base-service
spec:
workload:
definition:
apiVersion: apps/v1
kind: Deployment
schematic:
kube:
template:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
appId: BASE-SERVICE
appName: base-service
version: 0.0.1
name: base-service
spec:
replicas: 2
revisionHistoryLimit: 5
selector:
matchLabels:
app: base-service
template:
metadata:
labels:
antiAffinity: none
app: base-service
appId: BASE-SERVICE
version: 0.0.1
spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- base-service
- key: antiAffinity
operator: In
values:
- none
topologyKey: kubernetes.io/hostname
weight: 100
containers:
- env:
- name: NODE_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: APP_NAME
value: base-service
- name: LOG_BASE
value: /data/log
- name: RUNTIME_CLUSTER
value: default
image: base-service
imagePullPolicy: Always
name: base-service
ports:
- containerPort: 11223
protocol: TCP
- containerPort: 11224
protocol: TCP
volumeMounts:
- mountPath: /tmp/data/log/base-service
name: log-volume
- mountPath: /data
name: sidecar-sre
- mountPath: /app/skywalking
name: skywalking
initContainers:
- args:
- 'echo "do something" '
command:
- /bin/sh
- -c
env:
- name: NODE_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: APP_NAME
value: base-service
image: busybox
imagePullPolicy: Always
name: sidecar-sre
resources:
limits:
cpu: 100m
memory: 100Mi
volumeMounts:
- mountPath: /tmp/data/log/base-service
name: log-volume
- mountPath: /scratch
name: sidecar-sre
terminationGracePeriodSeconds: 120
volumes:
- hostPath:
path: /logs/dev/base-service
type: DirectoryOrCreate
name: log-volume
- emptyDir: {}
name: sidecar-sre
- emptyDir: {}
name: skywalking
parameters:
- name: image
required: true
type: string
fieldPaths:
- "spec.template.spec.containers[0].image"
- name: cluster
required: true
type: string
fieldPaths:
- "spec.template.spec.containers[0].env[6].value"
- "spec.template.metadata.labels.cluster"
---
apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
name: proxy-service
spec:
workload:
definition:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
schematic:
kube:
template:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
labels:
appId: PROXY-SERVICE
appName: proxy-service
version: 0.0.0
name: proxy-service
spec:
replicas: 1
revisionHistoryLimit: 1
selector:
matchLabels:
app: proxy-service
strategy:
canary:
steps:
- setWeight: 50
- pause: {}
template:
metadata:
labels:
app: proxy-service
appId: PROXY-SERVICE
cluster: default
version: 0.0.1
spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- proxy-service
topologyKey: kubernetes.io/hostname
weight: 100
containers:
- env:
- name: NODE_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: APP_NAME
value: proxy-service
- name: LOG_BASE
value: /app/data/log
- name: RUNTIME_CLUSTER
value: default
image: proxy-service:0.1
imagePullPolicy: Always
name: proxy-service
ports:
- containerPort: 11024
protocol: TCP
- containerPort: 11025
protocol: TCP
volumeMounts:
- mountPath: /tmp/data/log/proxy-service
name: log-volume
- mountPath: /app/data
name: sidecar-sre
- mountPath: /app/skywalking
name: skywalking
initContainers:
- args:
- 'echo "do something" '
command:
- /bin/sh
- -c
env:
- name: NODE_IP
valueFrom:
fieldRef:
fieldPath: status.hostIP
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: APP_NAME
value: proxy-service
image: busybox
imagePullPolicy: Always
name: sidecar-sre
resources:
limits:
cpu: 100m
memory: 100Mi
volumeMounts:
- mountPath: /tmp/data/log/proxy-service
name: log-volume
- mountPath: /scratch
name: sidecar-sre
terminationGracePeriodSeconds: 120
volumes:
- hostPath:
path: /app/logs/dev/proxy-service
type: DirectoryOrCreate
name: log-volume
- emptyDir: {}
name: sidecar-sre
- emptyDir: {}
name: skywalking
parameters:
- name: image
required: true
type: string
fieldPaths:
- "spec.template.spec.containers[0].image"
- name: cluster
required: true
type: string
fieldPaths:
- "spec.template.spec.containers[0].env[5].value"
- "spec.template.metadata.labels.cluster"
```
### 2.定义运维特征
编写用于负载均衡的运维特征的定义，其通过生成 Kubernetes 中的原生资源 `Service` 和 `Ingress` 实现负载均衡。
向终端用户透出的参数包括 domain 和 http ，其中 domain 可以指定域名，http 用来设定路由，具体将部署服务的端口映射为不同的 url path。
如下所示：
```
apiVersion: core.oam.dev/v1beta1
kind: TraitDefinition
metadata:
name: ingress
spec:
schematic:
cue:
template: |
parameter: {
domain: string
http: [string]: int
}
outputs: {
"service": {
apiVersion: "v1"
kind: "Service"
metadata: {
name: context.name
namespace: context.namespace
}
spec: {
selector: app: context.name
ports: [for ph, pt in parameter.http{
protocol: "TCP"
port: pt
targetPort: pt
}]
}
}
"ingress": {
apiVersion: "networking.k8s.io/v1"
kind: "Ingress"
metadata: {
name: "\(context.name)-ingress"
namespace: context.namespace
}
spec: rules: [{
host: parameter.domain
http: paths: [for ph, pt in parameter.http {
path: ph
pathType: "Prefix"
backend: service: {
name: context.name
port: number: pt
}
}]
}]
}
}
```
### 3.定义工作流的步骤
- 定义 apply-base 工作流步骤: 完成部署 base-server，等待组件成功启动后，往注册中心注册信息。透出参数为 component，终端用户在流水线中使用步骤 apply-base 时只需要指定组件名称。
- 定义 apply-helm 工作流步骤: 完成部署 redis helm chart，并等待 redis 成功启动。透出参数为 component，终端用户在流水线中使用步骤 apply-helm 时只需要指定组件名称。
- 定义 apply-proxy 工作流步骤: 完成部署 proxy-server，并等待组件成功启动。透出参数为 component 和 backendIP，其中 component 为组件名称，backendIP 为 proxy-server 服务依赖组件的 IP。
如下所示：
```
apiVersion: core.oam.dev/v1beta1
kind: WorkflowStepDefinition
metadata:
name: apply-base
namespace: vela-system
spec:
schematic:
cue:
template: |-
import ("vela/op")
parameter: {
component: string
}
apply: op.#ApplyComponent & {
component: parameter.component
}
// 等待 deployment 可用
wait: op.#ConditionalWait & {
continue: apply.workload.status.readyReplicas == apply.workload.status.replicas && apply.workload.status.observedGeneration == apply.workload.metadata.generation
}
message: {...}
// 往三方配置中心apollo写配置
notify: op.#HTTPPost & {
url: "appolo-address"
request: body: json.Marshal(message)
}
// 暴露 service 的 ClusterIP
clusterIP: apply.traits["service"].value.spec.clusterIP
---
apiVersion: core.oam.dev/v1beta1
kind: WorkflowStepDefinition
metadata:
name: apply-helm
namespace: vela-system
spec:
schematic:
cue:
template: |-
import ("vela/op")
parameter: {
component: string
}
apply: op.#ApplyComponent & {
component: parameter.component
}
chart: op.#Read & {
value: {
// redis 的元数据
...
}
}
// 等待 redis 可用
wait: op.#ConditionalWait & {
// todo
continue: chart.value.status.phase=="ready"
}
---
apiVersion: core.oam.dev/v1beta1
kind: WorkflowStepDefinition
metadata:
name: apply-proxy
namespace: vela-system
spec:
schematic:
cue:
template: |-
import (
"vela/op"
"encoding/json"
)
parameter: {
component: string
backendIP: string
}
// 往三方配置中心apollo读取配置
// config: op.#HTTPGet
apply: op.#ApplyComponent & {
component: parameter.component
// 给环境变量中注入BackendIP
workload: patch: spec: template: spec: {
containers: [{
// patchKey=name
env: [{name: "BackendIP",value: parameter.backendIP}]
},...]
}
}
// 等待 argo.rollout 可用
wait: op.#ConditionalWait & {
continue: apply.workload.status.readyReplicas == apply.workload.status.replicas && apply.workload.status.observedGeneration == apply.workload.metadata.generation
}
```
### 用户使用
理想汽车的开发工程师接下来就可以使用 Application 完成应用的发布。
开发工程师可以直接使用如上平台工程师在 KubeVela 上定制的通用能力，轻松完成应用部署计划的编写。
> 在下面例子中通过 workflow 的数据传递机制 input/output，将 base-server 的 clusterIP 传递给 proxy-server。
```
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: lixiang-app
spec:
components:
- name: base-service
type: base-service
properties:
image: nginx:1.14.2
# 用于区分appollo环境
cluster: default
traits:
- type: ingress
properties:
domain: base-service.dev.example.com
http:
"/": 11001
# redis无依赖，启动后service的endpionts 需要通过http接口写入信息写入到apollo
- name: "redis"
type: helm
properties:
chart: "redis-cluster"
version: "6.2.7"
repoUrl: "https://charts.bitnami.com/bitnami"
repoType: helm
- name: proxy-service
type: proxy-service
properties:
image: nginx:1.14.2
# 用于区分appollo环境
cluster: default
traits:
- type: ingress
properties:
domain: proxy-service.dev.example.com
http:
"/": 11002
workflow:
steps:
- name: apply-base-service
type: apply-base
outputs:
- name: baseIP
exportKey: clusterIP
properties:
component: base-service
- name: apply-redis
type: apply-helm
properties:
component: redis
- name: apply-proxy-service
type: apply-proxy
inputs:
- from: baseIP
parameterKey: backendIP
properties:
component: proxy-service
```

515
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/case-studies/multi-cluster.md Normal file
View File

@ -0,0 +1,515 @@
---
title: 多集群应用交付
---
本章节将会介绍如何使用 KubeVela 分发多集群应用。
## 简介
如今，在越来越多的场景下，开发者和系统运维人员开始将应用部署在多个集群中：
* 由于 Kubernetes 集群存在着部署规模的局限性（单一集群最多容纳 5k 节点），需要应用多集群技术来部署、管理海量的应用。
* 考虑到稳定性及高可用性，同一个应用可以部署在多个集群中，以实现容灾、异地多活等需求。
* 应用可能需要部署在不同的区域来满足不同政府对于数据安全性的政策需求。
下文将会介绍如何在 KubeVela 中进行使用管理多集群应用。
## 准备工作
在使用多集群应用部署之前，你需要将子集群通过 KubeConfig 加入到 KubeVela 的管控中来。Vela CLI 可以帮你实现这一点。
```shell script
vela cluster join <your kubeconfig path>
```
该命令会自动使用 KubeConfig 中的 `context.cluster` 字段作为集群名称，你也可以使用 `--name` 参数来指定，如
```shell
$ vela cluster join beijing.kubeconfig --name beijing
$ vela cluster join hangzhou-1.kubeconfig --name hangzhou-1
$ vela cluster join hangzhou-2.kubeconfig --name hangzhou-2
```
在子集群加入 KubeVela 中后，你同样可以使用 CLI 命令来查看当前正在被 KubeVela 管控的所有集群。
```bash
$ vela cluster list
CLUSTER TYPE ENDPOINT ACCEPTED LABELS
local Internal - true
cluster-beijing X509Certificate <ENDPOINT_BEIJING> true
cluster-hangzhou-1 X509Certificate <ENDPOINT_HANGZHOU_1> true
cluster-hangzhou-2 X509Certificate <ENDPOINT_HANGZHOU_2> true
```
> 默认情况下，KubeVela 控制面所在的管控集群会被作为 `local` 集群进行注册。你可以通过它将应用资源部署在管控集群中。该 `local` 集群不能被修改或者删除。
如果你不需要某个子集群了，还可以将子集群从 KubeVela 管控中移除。
```shell script
$ vela cluster detach beijing
```
> 移除一个正在使用的集群是危险行为。不过如果你想要对集群的认证信息做修改，比如轮转证书，你可以强行删除它。
你也可以给你的集群打标签，帮助你选择要部署的集群。
```bash
$ vela cluster labels add cluster-hangzhou-1 region=hangzhou
$ vela cluster labels add cluster-hangzhou-2 region=hangzhou
$ vela cluster list
CLUSTER TYPE ENDPOINT ACCEPTED LABELS
local Internal - true
cluster-beijing X509Certificate <ENDPOINT_BEIJING> true
cluster-hangzhou-1 X509Certificate <ENDPOINT_HANGZHOU_1> true region=hangzhou
cluster-hangzhou-2 X509Certificate <ENDPOINT_HANGZHOU_2> true region=hangzhou
```
## 部署多集群应用
你只需要使用 `topology` 策略来声明要部署的集群，就可以部署多集群应用了。例如，你可以使用下面这个样例将 nginx webservice 部署在两个杭州集群中，
```bash
$ cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: basic-topology
namespace: examples
spec:
components:
- name: nginx-basic
type: webservice
properties:
image: nginx
traits:
- type: expose
properties:
port: [80]
policies:
- name: topology-hangzhou-clusters
type: topology
properties:
clusters: ["cluster-hangzhou-1", "cluster-hangzhou-2"]
EOF
```
你可以通过运行 `vela status` 来查看部署状态。
```bash
$ vela status basic-topology -n examples
About:
Name: basic-topology
Namespace: examples
Created at: 2022-04-08 14:37:54 +0800 CST
Status: workflowFinished
Workflow:
mode: DAG
finished: true
Suspend: false
Terminated: false
Steps
- id:3mvz5i8elj
name:deploy-topology-hangzhou-clusters
type:deploy
phase:succeeded
message:
Services:
- Name: nginx-basic
Cluster: cluster-hangzhou-1 Namespace: examples
Type: webservice
Healthy Ready:1/1
Traits:
✅ expose
- Name: nginx-basic
Cluster: cluster-hangzhou-2 Namespace: examples
Type: webservice
Healthy Ready:1/1
Traits:
✅ expose
```
### 调试多集群应用
你可以运行以下 CLI 命令调试上述的多集群应用。通过这些 CLI 命令，你可以在管控集群上直接操纵子集群中的资源，而不需要切换 KubeConfig 等集群配置。如果你的应用使用了多个集群，CLI 向你询问你希望操纵的集群。
- `vela status` 如上文所示，为你展示多集群应用的整体部署情况。
- `vela logs` 查询子集群中的 Pod 日志。
```bash
$ vela logs basic-topology -n examples
? You have 2 deployed resources in your app. Please choose one: Cluster: cluster-hangzhou-1 | Namespace: examples | Kind: Deployment | Name: nginx-basic
+ nginx-basic-dfb6dcf8d-km5vk › nginx-basic
nginx-basic-dfb6dcf8d-km5vk nginx-basic 2022-04-08T06:38:10.540430392Z /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
nginx-basic-dfb6dcf8d-km5vk nginx-basic 2022-04-08T06:38:10.540742240Z /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
```
- `vela port-forward` 将子集群中的 Pod 或者 Service 通过端口映射到本地使其可以在本地被访问。
```bash
$ vela exec basic-topology -n examples -it -- ls
? You have 2 deployed resources in your app. Please choose one: Cluster: cluster-hangzhou-1 | Namespace: examples | Kind: Deployment | Name: nginx-basic
bin docker-entrypoint.d home media proc sbin tmp
boot docker-entrypoint.sh lib mnt root srv usr
dev etc lib64 opt run sys var
```
- `vela exec` 帮助你在子集群的 Pod 里执行命令。
```bash
$ vela port-forward basic-topology -n examples 8080:80
? You have 4 deployed resources in your app. Please choose one: Cluster: cluster-hangzhou-1 | Namespace: examples | Kind: Deployment | Name: nginx-basic
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
Forward successfully! Opening browser ...
Handling connection for 8080
```
## 进阶使用
### 配置部署目标
选择部署目标的最直接的方法就是在 `topology` 策略中声明你想要部署的集群名称。有的时候，使用标签来筛选要部署的集群会更方便，比如下面这个例子通过标签筛选出所有的杭州集群：
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: label-selector-topology
namespace: examples
spec:
components:
- name: nginx-label-selector
type: webservice
properties:
image: nginx
policies:
- name: topology-hangzhou-clusters
type: topology
properties:
clusterLabelSelector:
region: hangzhou
```
如果你想要在管控集群中部署应用，你也可以使用 `local` 集群。除此之外，你还可以选择希望部署的命名空间，取代应用原有的命名空间。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: local-ns-topology
namespace: examples
spec:
components:
- name: nginx-local-ns
type: webservice
properties:
image: nginx
policies:
- name: topology-local
type: topology
properties:
clusters: ["local"]
namespace: examples-alternative
```
> 有时，出于安全考虑，你可能希望限制应用使其只能在自己的命名空间中部署资源。你可以通过在 KubeVela 控制器的启动参数中配置 `--allow-cross-namespace-resource=false` 来禁用跨集群部署。
### 控制部署工作流
默认情况下，如果你在应用中声明了多个 `topology` 策略，应用组件将会依次分发到这些目标位置上。
如果你想要控制整个部署流程，比如更改默认的部署顺序，或者是添加人工审核步骤，你可以显式使用 `deploy` 工作流步骤来实现。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: deploy-workflowstep
namespace: examples
spec:
components:
- name: nginx-deploy-workflowstep
type: webservice
properties:
image: nginx
policies:
- name: topology-hangzhou-clusters
type: topology
properties:
clusterLabelSelector:
region: hangzhou
- name: topology-local
type: topology
properties:
clusters: ["local"]
namespace: examples-alternative
workflow:
steps:
- type: deploy
name: deploy-local
properties:
policies: ["topology-local"]
- type: deploy
name: deploy-hangzhou
properties:
# require manual approval before running this step
auto: false
policies: ["topology-hangzhou-clusters"]
```
如果你希望并行地部署所有集群，你可以在一个 `deploy` 工作流步骤中使用所有的 `topology` 策略。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: deploy-concurrently
namespace: examples
spec:
components:
- name: nginx-deploy-concurrently
type: webservice
properties:
image: nginx
policies:
- name: topology-hangzhou-clusters
type: topology
properties:
clusterLabelSelector:
region: hangzhou
- name: topology-local
type: topology
properties:
clusters: ["local"]
namespace: examples-alternative
workflow:
steps:
- type: deploy
name: deploy-all
properties:
policies: ["topology-local", "topology-hangzhou-clusters"]
```
### 使用差异化配置
在一些情况下，你可能希望应用在不同的集群中有不一样的配置，而不是全都使用完全相同的默认配置。比如使用不同的镜像或者配置不同的副本数量。
`override` 策略可以帮助你实现差异化配置。你可以在 `deploy` 工作流步骤中，配合 `topology` 策略来使用它。
在下面的样例中，应用会在 `local` 集群中部署一个默认的 nginx webservcie，然后在杭州集群中部署含有 3 副本的高可用 nginx webservice，并且使用 `nginx:1.20` 镜像。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: deploy-with-override
namespace: examples
spec:
components:
- name: nginx-with-override
type: webservice
properties:
image: nginx
policies:
- name: topology-hangzhou-clusters
type: topology
properties:
clusterLabelSelector:
region: hangzhou
- name: topology-local
type: topology
properties:
clusters: ["local"]
namespace: examples-alternative
- name: override-nginx-legacy-image
type: override
properties:
components:
- name: nginx-with-override
properties:
image: nginx:1.20
- name: override-high-availability
type: override
properties:
components:
- type: webservice
traits:
- type: scaler
properties:
replicas: 3
workflow:
steps:
- type: deploy
name: deploy-local
properties:
policies: ["topology-local"]
- type: deploy
name: deploy-hangzhou
properties:
policies: ["topology-hangzhou-clusters", "override-nginx-legacy-image", "override-high-availability"]
```
差异化配置有一些高级配置能力，比如添加额外的组件，或者选择部分组件。下面的样例中，应用会首先在 `local` 集群中部署一个镜像为 `nginx:1.20` 的 webservice，然后再将 `nginx` 和 `nginx:stable` 两个 webservice 部署到杭州集群中
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: advance-override
namespace: examples
spec:
components:
- name: nginx-advance-override-legacy
type: webservice
properties:
image: nginx:1.20
- name: nginx-advance-override-latest
type: webservice
properties:
image: nginx
policies:
- name: topology-hangzhou-clusters
type: topology
properties:
clusterLabelSelector:
region: hangzhou
- name: topology-local
type: topology
properties:
clusters: ["local"]
namespace: examples-alternative
- name: override-nginx-legacy
type: override
properties:
selector: ["nginx-advance-override-legacy"]
- name: override-nginx-latest
type: override
properties:
selector: ["nginx-advance-override-latest", "nginx-advance-override-stable"]
components:
- name: nginx-advance-override-stable
type: webservice
properties:
image: nginx:stable
workflow:
steps:
- type: deploy
name: deploy-local
properties:
policies: ["topology-local", "override-nginx-legacy"]
- type: deploy
name: deploy-hangzhou
properties:
policies: ["topology-hangzhou-clusters", "override-nginx-latest"]
```
### 使用外置策略和工作流
有时，你可能希望在不同的应用之间使用相同的策略，或者在部署资源的时候复用之前的工作流配置。
为了减少重复的配置，你可以使用外置的策略和工作流，并在应用中引用它们。
> 注意：你只能在应用中引用相同命名空间下的策略和工作流。
```yaml
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
name: topology-hangzhou-clusters
namespace: examples
type: topology
properties:
clusterLabelSelector:
region: hangzhou
---
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
name: override-high-availability-webservice
namespace: examples
type: override
properties:
components:
- type: webservice
traits:
- type: scaler
properties:
replicas: 3
---
apiVersion: core.oam.dev/v1alpha1
kind: Workflow
metadata:
name: make-release-in-hangzhou
namespace: examples
steps:
- type: deploy
name: deploy-hangzhou
properties:
auto: false
policies: ["override-high-availability-webservice", "topology-hangzhou-clusters"]
```
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: external-policies-and-workflow
namespace: examples
spec:
components:
- name: nginx-external-policies-and-workflow
type: webservice
properties:
image: nginx
workflow:
ref: make-release-in-hangzhou
```
> 注意：内置的策略会被优先使用。只有当工作流使用的策略不存在于内置策略中时才会使用外置策略。在下面的样例中，你可以复用 `topology-hangzhou-clusters` 策略以及 `make-release-in-hangzhou` 工作流，但是通过在应用中声明 `override-high-availability-webservice` 策略来覆盖同名的外置策略。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: nginx-stable-ultra
namespace: examples
spec:
components:
- name: nginx-stable-ultra
type: webservice
properties:
image: nginx:stable
policies:
- name: override-high-availability-webservice
type: override
properties:
components:
- type: webservice
traits:
- type: scaler
properties:
replicas: 5
workflow:
ref: make-release-in-hangzhou
```
## 兼容性
KubeVela 的 v1.3 应用相较于之前的版本使用了不同的策略和工作流步骤来分发、管理多集群应用。
旧版本中的 `env-binding` 策略以及 `deploy2env` 工作流步骤在目前版本中仍保留并兼容，但可能会在未来的版本中逐步废弃。
新的策略和工作流步骤可以完全覆盖旧版本中多集群应用的所有使用场景，而且提供了更强的能力。自动化升级工具将会在废弃旧版本之前提供给用户。
如果你已经在生产环境中使用了旧版本的多集群应用，并且不希望改变他们，KubeVela v1.3 可以完全兼容它们，而不需要对应用进行升级。

174
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/case-studies/workflow-with-ocm.md Normal file
View File

@ -0,0 +1,174 @@
---
title: 使用工作流实现多集群部署
---
本案例，将为你讲述如何使用 KubeVela 做多集群应用部署，将包含从集群创建、集群注册、环境初始化、多集群调度，一直到应用多集群部署的完整流程。
- 通过 KubeVela 中的环境初始化（Initializer）功能，我们可以创建一个 Kubernetes 集群并注册到中央管控集群，同样通过环境初始化功能，可以将应用管理所需的系统依赖一并安装。
- 通过 KubeVela 的多集群多环境部署（EnvBinding）功能，可以对应用进行差异化配置，并选择资源下发到哪些集群。
## 开始之前
- 首先你需要有一个 Kubernetes 版本为 1.20+ 的集群作为管控集群，并且已经安装好 KubeVela ，管控集群需要有一个可以通过公网访问的 APIServer
的地址。如果不做特殊说明，实践案例上的所有步骤都在管控集群上操作。
- 在这个场景中，KubeVela 背后采用[OCM(open-cluster-management)](https://open-cluster-management.io/getting-started/quick-start/)技术做实际的多集群资源分发。
- 本实践案例相关的 YAML 描述和 Shell 脚本都在 KubeVela 项目的 [docs/examples/workflow-with-ocm](https://github.com/oam-dev/kubevela/tree/master/docs/examples/workflow-with-ocm) 下，
请下载该案例，在该目录执行下面的终端命令。
- 本实践案例将以阿里云的 ACK 集群作为例子，创建阿里云资源需要使用相应的鉴权，需要保存你阿里云账号的 AK/SK 到管控集群的 Secret 中。
```shell
export ALICLOUD_ACCESS_KEY=xxx; export ALICLOUD_SECRET_KEY=yyy
```
```shell
# 如果你想使用阿里云安全令牌服务，还要导出环境变量 ALICLOUD_SECURITY_TOKEN 。
export ALICLOUD_SECURITY_TOKEN=zzz
```
```shell
# prepare-alibaba-credentials.sh 脚本会读取环境变量并创建 secret 到当前集群。
sh hack/prepare-alibaba-credentials.sh
```
```shell
$ kubectl get secret -n vela-system
NAME TYPE DATA AGE
alibaba-account-creds Opaque 1 11s
```
## 初始化阿里云资源创建功能
我们可以使用 KubeVela 的环境初始化功能，开启阿里云资源创建的系统功能，这个初始化过程主要是将之前配置的鉴权信息提供出来，并初始化 Terraform 系统插件。我们将这个初始化对象命名为：`terraform-alibaba`，并部署：
```shell
kubectl apply -f initializers/init-terraform-alibaba.yaml
```
### 创建环境初始化 `terraform-alibaba`
```shell
kubectl apply -f initializers/init-terraform-alibaba.yaml
```
当环境初始化 `terraform-alibaba` 的 `PHASE` 字段为 `success` 表示环境初始化成功，这可能需要等待1分钟左右的时间。
```shell
$ kubectl get initializers.core.oam.dev -n vela-system
NAMESPACE NAME PHASE AGE
vela-system terraform-alibaba success 94s
```
## 初始化多集群调度功能
我们使用 KubeVela 的环境初始化功能，开启多集群调度的系统功能，这个初始化过程主要是创建一个新的 ACK 集群，使用 OCM 多集群管理方案管理新创建的集群，我们将这个初始化对象命名为：`managed-cluster`，并部署：
```shell
kubectl apply -f initializers/init-managed-cluster.yaml
```
除此之外，为了让创建好的集群可以被管控集群所使用，我们还需要将创建的集群注册到管控集群。我们通过定义一个工作流节点来传递新创建集群的证书信息，再定义一个工作流节点来完成集群注册。
**自定义执行集群创建的工作流节点，命名为 `create-ack`**，进行部署：
```shell
kubectl apply -f definitions/create-ack.yaml
```
**自定义集群注册的工作流节点，命名为 `register-cluster`**，进行部署：
```shell
kubectl apply -f definitions/register-cluster.yaml
```
### 创建环境初始化
1. 安装工作流节点定义 `create-ack` 和 `register-cluster`：
```shell
kubectl apply -f definitions/create-ack.yaml.yaml
kubectl apply -f definitions/register-cluster.yaml
```
2. 修改工作流节点 `register-ack` 的 hubAPIServer 的参数为管控集群的 APIServer 的公网地址。
```yaml
- name: register-ack
type: register-cluster
inputs:
- from: connInfo
parameterKey: connInfo
properties:
# 用户需要填写管控集群的 APIServer 的公网地址
hubAPIServer: {{ public network address of APIServer }}
env: prod
initNameSpace: default
patchLabels:
purpose: test
```
3. 创建环境初始化 `managed-cluster`。
```
kubectl apply -f initializers/init-managed-cluster.yaml
```
当环境初始化 `managed-cluster` 的 `PHASE` 字段为 `success` 表示环境初始化成功，你可能需要等待 15-20 分钟左右的时间（阿里云创建一个ack集群需要 15 分钟左右）。
```shell
$ kubectl get initializers.core.oam.dev -n vela-system
NAMESPACE NAME PHASE AGE
vela-system managed-cluster success 20m
```
当环境初始化 `managed-cluster` 初始化成功后，你可以看到新集群 `poc-01` 已经被被注册到管控集群中。
```shell
$ kubectl get managedclusters.cluster.open-cluster-management.io
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE
poc-01 true {{ APIServer address }} True True 30s
```
## 部署应用到指定集群
管理员完成多集群的注册之后，用户可以在应用部署计划中指定将资源部署到哪个集群中。
```shell
kubectl apply -f app.yaml
```
检查应用部署计划 `workflow-demo` 是否成功创建。
```shell
$ kubectl get app workflow-demo
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
workflow-demo podinfo-server webservice running true 7s
```
你可以切换到新创建的 ACK 集群上，查看资源是否被成功地部署。
```shell
$ kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
podinfo-server 1/1 1 1 40s
```
```shell
$ kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
podinfo-server-auxiliaryworkload-85d7b756f9 LoadBalancer 192.168.57.21 < EIP > 9898:31132/TCP 50s
```
Service `podinfo-server` 绑定了一个 EXTERNAL-IP，允许用户通过公网访问应用，用户可以在浏览器中输入 `http://<EIP>:9898` 来访问刚刚创建的应用。
![workflow-with-ocm-demo](../resources/workflow-with-ocm-demo.png)
上述应用部署计划 `workflow-demo` 中使用了内置的应用策略 `env-binding` 对应用部署计划进行差异化配置，修改了组件 `podinfo-server` 的镜像，
以及运维特征 `expose` 的类型以允许集群外部的请求访问，同时应用策略 `env-binding` 指定了资源调度策略，将资源部署到新注册的 ACK 集群内。
应用部署计划的交付工作流也使用了内置的 `multi-env` 交付工作流定义，指定具体哪一个配置后的组件部署到集群中。

47
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela.md Normal file
View File

@ -0,0 +1,47 @@
---
title: CLI Commands
---
## Getting Started
* [vela env](vela_env) - Manage environments for vela applications to run.
* [vela init](vela_init) - Create scaffold for vela application.
* [vela up](vela_up) - Create or update vela application from file or URL, both appfile or application object format are supported.
* [vela show](vela_show) - Show the reference doc for component, trait or workflow types.
## Managing Applications
* [vela ls](vela_ls) - List all vela applications.
* [vela status](vela_status) - Show status of vela application.
* [vela delete](vela_delete) - Delete an application.
* [vela exec](vela_exec) - Execute command inside container based vela application.
* [vela port-forward](vela_port-forward) - Forward local ports to container/service port of vela application.
* [vela logs](vela_logs) - Tail logs for vela application.
* [vela live-diff](vela_live-diff) - Dry-run application locally, and diff with a deployed application version.
* [vela dry-run](vela_dry-run) - Dry-run application locally, render the Kubernetes resources as result to stdout.
## Continuous Delivery
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters for Continuous Delivery.
* [vela workflow](vela_workflow) - Operate the Workflow during Application Delivery.
## Managing Extension
* [vela addon](vela_addon) - Manage addons for extension.
* [vela uischema](vela_uischema) - Manage UI schema for addons.
* [vela def](vela_def) - Manage X-Definitions for extension.
* [vela registry](vela_registry) - Manage Registry of X-Definitions for extension.
* [vela component](vela_component) - List component types installed and discover more in registry.
* [vela trait](vela_trait) - List trait types installed and discover more in registry.
## Others
* [vela uninstall](vela_uninstall) - Uninstalls KubeVela from a Kubernetes cluster.
* [vela install](vela_install) - The Kubevela CLI allows installing Kubevela on any Kubernetes derivative to which your kube config is pointing to.
* [vela completion](vela_completion) - Output shell completion code for the specified shell (bash or zsh).
The shell code must be evaluated to provide interactive completion of vela commands.
* [vela export](vela_export) - Export deploy manifests from appfile or application.
* [vela version](vela_version) - Prints vela build version information.
###### Auto generated by [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

36
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_addon.md Normal file
View File

@ -0,0 +1,36 @@
---
title: vela addon
---
Manage addons for extension.
### Synopsis
Manage addons for extension.
### Options
```
-h, --help help for addon
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon disable](vela_addon_disable) - disable an addon
* [vela addon enable](vela_addon_enable) - enable an addon
* [vela addon list](vela_addon_list) - List addons
* [vela addon registry](vela_addon_registry) - Manage addon registry.
* [vela addon status](vela_addon_status) - get an addon's status.
* [vela addon upgrade](vela_addon_upgrade) - upgrade an addon
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_addon_disable.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela addon disable
---
disable an addon
### Synopsis
disable an addon in cluster.
```
vela addon disable [flags]
```
### Examples
```
vela addon disable <addon-name>
```
### Options
```
-h, --help help for disable
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_addon_enable.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela addon enable
---
enable an addon
### Synopsis
enable an addon in cluster.
```
vela addon enable [flags]
```
### Examples
```
vela addon enable <addon-name>
```
### Options
```
-h, --help help for enable
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_addon_list.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela addon list
---
List addons
### Synopsis
List addons in KubeVela
```
vela addon list [flags]
```
### Options
```
-h, --help help for list
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

35
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_addon_registry.md Normal file
View File

@ -0,0 +1,35 @@
---
title: vela addon registry
---
Manage addon registry.
### Synopsis
Manage addon registry.
### Options
```
-h, --help help for registry
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
* [vela addon registry add](vela_addon_registry_add) - Add an addon registry.
* [vela addon registry delete](vela_addon_registry_delete) - Delete an addon registry
* [vela addon registry get](vela_addon_registry_get) - Get an addon registry.
* [vela addon registry list](vela_addon_registry_list) - List addon registries.
* [vela addon registry update](vela_addon_registry_update) - Update an addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

45
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_addon_registry_add.md Normal file
View File

@ -0,0 +1,45 @@
---
title: vela addon registry add
---
Add an addon registry.
### Synopsis
Add an addon registry.
```
vela addon registry add [flags]
```
### Examples
```
"vela addon registry add <my-registry-name> --type OSS --endpoint=<URL> --bucket=<bukect-name> or vela addon registry add my-repo --type git --endpoint=<URL> --path=<OSS-ptah> --gitToken=<git token>"
```
### Options
```
--bucket string specify the OSS bucket name
--endpoint string specify the addon registry endpoint
--gitToken string specify the github repo token
-h, --help help for add
--path string specify the addon registry OSS path
--type string specify the addon registry type
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon registry](vela_addon_registry) - Manage addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_addon_registry_delete.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela addon registry delete
---
Delete an addon registry
### Synopsis
Delete an addon registry
```
vela addon registry delete [flags]
```
### Examples
```
vela addon registry delete <registry-name>
```
### Options
```
-h, --help help for delete
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon registry](vela_addon_registry) - Manage addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_addon_registry_get.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela addon registry get
---
Get an addon registry.
### Synopsis
Get an addon registry.
```
vela addon registry get [flags]
```
### Examples
```
vela addon registry get <registry name>
```
### Options
```
-h, --help help for get
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon registry](vela_addon_registry) - Manage addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_addon_registry_list.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela addon registry list
---
List addon registries.
### Synopsis
List addon registries.
```
vela addon registry list [flags]
```
### Examples
```
vela addon registry list
```
### Options
```
-h, --help help for list
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon registry](vela_addon_registry) - Manage addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

45
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_addon_registry_update.md Normal file
View File

@ -0,0 +1,45 @@
---
title: vela addon registry update
---
Update an addon registry.
### Synopsis
Update an addon registry.
```
vela addon registry update [flags]
```
### Examples
```
vela addon registry update <registry-name> --type OSS --endpoint=<URL> --bucket=<bucket name>
```
### Options
```
--bucket string specify the OSS bucket name
--endpoint string specify the addon registry endpoint
--gitToken string specify the github repo token
-h, --help help for update
--path string specify the addon registry OSS path
--type string specify the addon registry type
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon registry](vela_addon_registry) - Manage addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_addon_status.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela addon status
---
get an addon's status.
### Synopsis
get an addon's status from cluster.
```
vela addon status [flags]
```
### Examples
```
vela addon status <addon-name>
```
### Options
```
-h, --help help for status
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_addon_upgrade.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela addon upgrade
---
upgrade an addon
### Synopsis
upgrade an addon in cluster.
```
vela addon upgrade [flags]
```
### Examples
```
vela addon upgrade <addon-name>
```
### Options
```
-h, --help help for upgrade
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

35
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_cluster.md Normal file
View File

@ -0,0 +1,35 @@
---
title: vela cluster
---
Manage Kubernetes Clusters
### Synopsis
Manage Kubernetes Clusters for Continuous Delivery.
### Options
```
-h, --help help for cluster
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster detach](vela_cluster_detach) - detach managed cluster.
* [vela cluster join](vela_cluster_join) - join managed cluster.
* [vela cluster list](vela_cluster_list) - list managed clusters
* [vela cluster probe](vela_cluster_probe) - health probe managed cluster.
* [vela cluster rename](vela_cluster_rename) - rename managed cluster.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

35
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_cluster_detach.md Normal file
View File

@ -0,0 +1,35 @@
---
title: vela cluster detach
---
detach managed cluster.
### Synopsis
detach managed cluster.
```
vela cluster detach [CLUSTER_NAME] [flags]
```
### Options
```
-h, --help help for detach
-p, --kubeconfig-path string Specify the kubeconfig path of managed cluster. If you use ocm to manage your cluster, you must set the kubeconfig-path.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

45
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_cluster_join.md Normal file
View File

@ -0,0 +1,45 @@
---
title: vela cluster join
---
join managed cluster.
### Synopsis
join managed cluster by kubeconfig.
```
vela cluster join [KUBECONFIG] [flags]
```
### Examples
```
# Join cluster declared in my-child-cluster.kubeconfig
> vela cluster join my-child-cluster.kubeconfig --name example-cluster
```
### Options
```
--create-namespace string Specifies the namespace need to create in managedCluster
-t, --engine string Specify the cluster management engine. If empty, it will use cluster-gateway cluster management solution. Default to be empty.
-h, --help help for join
--in-cluster-boostrap If true, the registering managed cluster will use the internal endpoint prescribed in the hub cluster's configmap "kube-public/cluster-info to register "itself to the hub cluster. Otherwise use the original endpoint from the hub kubeconfig. (default true)
-n, --name string Specify the cluster name. If empty, it will use the cluster name in config file. Default to be empty.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_cluster_list.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela cluster list
---
list managed clusters
### Synopsis
list worker clusters managed by KubeVela.
```
vela cluster list [flags]
```
### Options
```
-h, --help help for list
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_cluster_probe.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela cluster probe
---
health probe managed cluster.
### Synopsis
health probe managed cluster.
```
vela cluster probe [CLUSTER_NAME] [flags]
```
### Options
```
-h, --help help for probe
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_cluster_rename.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela cluster rename
---
rename managed cluster.
### Synopsis
rename managed cluster.
```
vela cluster rename [OLD_NAME] [NEW_NAME] [flags]
```
### Options
```
-h, --help help for rename
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

33
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_completion.md Normal file
View File

@ -0,0 +1,33 @@
---
title: vela completion
---
Output shell completion code for the specified shell (bash or zsh)
### Synopsis
Output shell completion code for the specified shell (bash or zsh).
The shell code must be evaluated to provide interactive completion of vela commands.
### Options
```
-h, --help help for completion
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela completion bash](vela_completion_bash) - generate autocompletions script for bash
* [vela completion zsh](vela_completion_zsh) - generate autocompletions script for zsh
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

44
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_completion_bash.md Normal file
View File

@ -0,0 +1,44 @@
---
title: vela completion bash
---
generate autocompletions script for bash
### Synopsis
Generate the autocompletion script for Vela for the bash shell.
To load completions in your current shell session:
$ source <(vela completion bash)
To load completions for every new session, execute once:
Linux:
$ vela completion bash > /etc/bash_completion.d/vela
MacOS:
$ vela completion bash > /usr/local/etc/bash_completion.d/vela
```
vela completion bash
```
### Options
```
-h, --help help for bash
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela completion](vela_completion) - Output shell completion code for the specified shell (bash or zsh)
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

41
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_completion_zsh.md Normal file
View File

@ -0,0 +1,41 @@
---
title: vela completion zsh
---
generate autocompletions script for zsh
### Synopsis
Generate the autocompletion script for Vela for the zsh shell.
To load completions in your current shell session:
$ source <(vela completion zsh)
To load completions for every new session, execute once:
$ vela completion zsh > "${fpath[1]}/_vela"
```
vela completion zsh
```
### Options
```
-h, --help help for zsh
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela completion](vela_completion) - Output shell completion code for the specified shell (bash or zsh)
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

46
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_component.md Normal file
View File

@ -0,0 +1,46 @@
---
title: vela component
---
List/get components
### Synopsis
List component types installed and discover more in registry.
```
vela component [flags]
```
### Examples
```
vela comp
```
### Options
```
--discover discover traits in registries
-h, --help help for component
--label --label type=terraform a label to filter components, the format is --label type=terraform
--registry string specify the registry name (default "default")
--token string specify token when using --url to specify registry url
--url string specify the registry URL
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela component get](vela_component_get) - get component from registry
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

43
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_component_get.md Normal file
View File

@ -0,0 +1,43 @@
---
title: vela component get
---
get component from registry
### Synopsis
get/download/install component from registry.
```
vela component get <component> [flags]
```
### Examples
```
vela comp get <component>
```
### Options
```
-h, --help help for get
```
### Options inherited from parent commands
```
--registry string specify the registry name (default "default")
--token string specify token when using --url to specify registry url
--url string specify the registry URL
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela component](vela_component) - List/get components
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

39
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_def.md Normal file
View File

@ -0,0 +1,39 @@
---
title: vela def
---
Manage Definitions
### Synopsis
Manage X-Definitions for extension.
### Options
```
-h, --help help for def
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def apply](vela_def_apply) - Apply X-Definition.
* [vela def del](vela_def_del) - Delete X-Definition.
* [vela def doc-gen](vela_def_doc-gen) - Generate documentation of definitions (Only Terraform typed definitions are supported)
* [vela def edit](vela_def_edit) - Edit X-Definition.
* [vela def get](vela_def_get) - Get definition
* [vela def init](vela_def_init) - Init a new definition
* [vela def list](vela_def_list) - List definitions.
* [vela def render](vela_def_render) - Render X-Definition.
* [vela def vet](vela_def_vet) - Validate X-Definition.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

46
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_def_apply.md Normal file
View File

@ -0,0 +1,46 @@
---
title: vela def apply
---
Apply X-Definition.
### Synopsis
Apply X-Definition from local storage to kubernetes cluster. It will apply file to vela-system namespace by default.
```
vela def apply DEFINITION.cue [flags]
```
### Examples
```
# Command below will apply the local my-webservice.cue file to kubernetes vela-system namespace
> vela def apply my-webservice.cue
# Command below will apply the ./defs/my-trait.cue file to kubernetes default namespace
> vela def apply ./defs/my-trait.cue --namespace default# Command below will convert the ./defs/my-trait.cue file to kubernetes CRD object and print it without applying it to kubernetes
> vela def apply ./defs/my-trait.cue --dry-run
```
### Options
```
--dry-run only build definition from CUE into CRB object without applying it to kubernetes clusters
-h, --help help for apply
-n, --namespace string Specify which namespace to apply. (default "vela-system")
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

43
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_def_del.md Normal file
View File

@ -0,0 +1,43 @@
---
title: vela def del
---
Delete X-Definition.
### Synopsis
Delete X-Definition in kubernetes cluster.
```
vela def del DEFINITION_NAME [flags]
```
### Examples
```
# Command below will delete TraitDefinition of annotations in default namespace
> vela def del annotations -t trait -n default
```
### Options
```
-h, --help help for del
-n, --namespace string Specify which namespace the definition locates.
-t, --type string Specify the definition type of target. Valid types: trait, policy, workload, scope, workflow-step, component
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

43
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_def_doc-gen.md Normal file
View File

@ -0,0 +1,43 @@
---
title: vela def doc-gen
---
Generate documentation of definitions (Only Terraform typed definitions are supported)
### Synopsis
Generate documentation of definitions
```
vela def doc-gen NAME [flags]
```
### Examples
```
1. Generate documentation for ComponentDefinition alibaba-vpc:
> vela def doc-gen alibaba-vpc -n vela-system
```
### Options
```
-h, --help help for doc-gen
-n, --namespace string Specify the namespace of the definition.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

46
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_def_edit.md Normal file
View File

@ -0,0 +1,46 @@
---
title: vela def edit
---
Edit X-Definition.
### Synopsis
Edit X-Definition in kubernetes. If type and namespace are not specified, the command will automatically search all possible results.
By default, this command will use the vi editor and can be altered by setting EDITOR environment variable.
```
vela def edit NAME [flags]
```
### Examples
```
# Command below will edit the ComponentDefinition (and other definitions if exists) of webservice in kubernetes
> vela def edit webservice
# Command below will edit the TraitDefinition of ingress in vela-system namespace
> vela def edit ingress --type trait --namespace vela-system
```
### Options
```
-h, --help help for edit
-n, --namespace string Specify which namespace to get. If empty, all namespaces will be searched.
-t, --type string Specify which definition type to get. If empty, all types will be searched. Valid types: component, trait, policy, workload, scope, workflow-step
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

45
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_def_get.md Normal file
View File

@ -0,0 +1,45 @@
---
title: vela def get
---
Get definition
### Synopsis
Get definition from kubernetes cluster
```
vela def get NAME [flags]
```
### Examples
```
# Command below will get the ComponentDefinition(or other definitions if exists) of webservice in all namespaces
> vela def get webservice
# Command below will get the TraitDefinition of annotations in namespace vela-system
> vela def get annotations --type trait --namespace vela-system
```
### Options
```
-h, --help help for get
-n, --namespace string Specify which namespace to get. If empty, all namespaces will be searched.
-t, --type string Specify which definition type to get. If empty, all types will be searched. Valid types: trait, policy, workload, scope, workflow-step, component
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

61
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_def_init.md Normal file
View File

@ -0,0 +1,61 @@
---
title: vela def init
---
Init a new definition
### Synopsis
Init a new definition with given arguments or interactively
* We support parsing a single YAML file (like kubernetes objects) into the cue-style template.
However, we do not support variables in YAML file currently, which prevents users from directly feeding files like helm chart directly.
We may introduce such features in the future.
```
vela def init DEF_NAME [flags]
```
### Examples
```
# Command below initiate an empty TraitDefinition named my-ingress
> vela def init my-ingress -t trait --desc "My ingress trait definition." > ./my-ingress.cue
# Command below initiate a definition named my-def interactively and save it to ./my-def.cue
> vela def init my-def -i --output ./my-def.cue
# Command below initiate a ComponentDefinition named my-webservice with the template parsed from ./template.yaml.
> vela def init my-webservice -i --template-yaml ./template.yaml
# Initiate a Terraform ComponentDefinition named vswitch from Github for Alibaba Cloud.
> vela def init vswitch --type component --provider alibaba --desc xxx --git https://github.com/kubevela-contrib/terraform-modules.git --path alibaba/vswitch
# Initiate a Terraform ComponentDefinition named redis from local file for AWS.
> vela def init redis --type component --provider aws --desc "Terraform configuration for AWS Redis" --local redis.tf
```
### Options
```
-d, --desc string Specify the description of the new definition.
--git string Specify which git repository the configuration(HCL) is stored in. Valid when --provider/-p is set.
-h, --help help for init
-i, --interactive Specify whether use interactive process to help generate definitions.
--local string Specify the local path of the configuration(HCL) file. Valid when --provider/-p is set.
-o, --output string Specify the output path of the generated definition. If empty, the definition will be printed in the console.
--path string Specify which path the configuration(HCL) is stored in the Git repository. Valid when --git is set.
-p, --provider alibaba Specify which provider the cloud resource definition belongs to. Only alibaba, `aws`, `azure` are supported.
-f, --template-yaml string Specify the template yaml file that definition will use to build the schema. If empty, a default template for the given definition type will be used.
-t, --type string Specify the type of the new definition. Valid types: scope, workflow-step, component, trait, policy, workload
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

45
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_def_list.md Normal file
View File

@ -0,0 +1,45 @@
---
title: vela def list
---
List definitions.
### Synopsis
List definitions in kubernetes cluster.
```
vela def list [flags]
```
### Examples
```
# Command below will list all definitions in all namespaces
> vela def list
# Command below will list all definitions in the vela-system namespace
> vela def get annotations --type trait --namespace vela-system
```
### Options
```
-h, --help help for list
-n, --namespace string Specify which namespace to list. If empty, all namespaces will be searched.
-t, --type string Specify which definition type to list. If empty, all types will be searched. Valid types: policy, workload, scope, workflow-step, component, trait
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

46
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_def_render.md Normal file
View File

@ -0,0 +1,46 @@
---
title: vela def render
---
Render X-Definition.
### Synopsis
Render X-Definition with cue format into kubernetes YAML format. Could be used to check whether the cue format definition is working as expected. If a directory is used as input, all cue definitions in the directory will be rendered.
```
vela def render DEFINITION.cue [flags]
```
### Examples
```
# Command below will render my-webservice.cue into YAML format and print it out.
> vela def render my-webservice.cue
# Command below will render my-webservice.cue and save it in my-webservice.yaml.
> vela def render my-webservice.cue -o my-webservice.yaml# Command below will render all cue format definitions in the ./defs/cue/ directory and save the YAML objects in ./defs/yaml/.
> vela def render ./defs/cue/ -o ./defs/yaml/
```
### Options
```
-h, --help help for render
--message string Specify the header message of the generated YAML file. For example, declaring author information.
-o, --output string Specify the output path of the rendered definition YAML. If empty, the definition will be printed in the console. If input is a directory, the output path is expected to be a directory as well.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

42
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_def_vet.md Normal file
View File

@ -0,0 +1,42 @@
---
title: vela def vet
---
Validate X-Definition.
### Synopsis
Validate definition file by checking whether it has the valid cue format with fields set correctly
* Currently, this command only checks the cue format. This function is still working in progress and we will support more functional validation mechanism in the future.
```
vela def vet DEFINITION.cue [flags]
```
### Examples
```
# Command below will validate the my-def.cue file.
> vela def vet my-def.cue
```
### Options
```
-h, --help help for vet
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

45
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_delete.md Normal file
View File

@ -0,0 +1,45 @@
---
title: vela delete
---
Delete an application
### Synopsis
Delete an application.
```
vela delete APP_NAME
```
### Examples
```
vela delete frontend
```
### Options
```
-e, --env string specify environment name for application
-f, --force force to delete the application
-h, --help help for delete
-n, --namespace string specify the Kubernetes namespace to use
--svc string delete only the specified service in this app
-w, --wait wait util the application is deleted completely
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

44
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_dry-run.md Normal file
View File

@ -0,0 +1,44 @@
---
title: vela dry-run
---
Dry Run an application, and output the K8s resources as result to stdout
### Synopsis
Dry-run application locally, render the Kubernetes resources as result to stdout.
```
vela dry-run
```
### Examples
```
vela dry-run
```
### Options
```
-d, --definition string specify a definition file or directory, it will only be used in dry-run rather than applied to K8s cluster
-e, --env string specify environment name for application
-f, --file string application file name (default "./app.yaml")
-h, --help help for dry-run
-n, --namespace string specify the Kubernetes namespace to use
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_env.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela env
---
Manage environments for vela applications to run.
### Synopsis
Manage environments for vela applications to run.
### Options
```
-h, --help help for env
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela env delete](vela_env_delete) - Delete an environment.
* [vela env init](vela_env_init) - Create environment for vela applications to run.
* [vela env ls](vela_env_ls) - List environments for vela applications to run.
* [vela env set](vela_env_set) - Set an environment.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_env_delete.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela env delete
---
Delete an environment.
### Synopsis
Delete an environment.
```
vela env delete
```
### Examples
```
vela env delete test
```
### Options
```
-h, --help help for delete
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela env](vela_env) - Manage environments for vela applications to run.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

41
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_env_init.md Normal file
View File

@ -0,0 +1,41 @@
---
title: vela env init
---
Create environment for vela applications to run.
### Synopsis
Create environment for vela applications to run.
```
vela env init <envName>
```
### Examples
```
vela env init test --namespace test
```
### Options
```
-h, --help help for init
--namespace string specify K8s namespace for env
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela env](vela_env) - Manage environments for vela applications to run.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_env_ls.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela env ls
---
List environments for vela applications to run.
### Synopsis
List all environments for vela applications to run.
```
vela env ls
```
### Examples
```
vela env ls [env-name]
```
### Options
```
-h, --help help for ls
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela env](vela_env) - Manage environments for vela applications to run.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_env_set.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela env set
---
Set an environment.
### Synopsis
Set an environment as the default one for running vela applications.
```
vela env set
```
### Examples
```
vela env set test
```
### Options
```
-h, --help help for set
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela env](vela_env) - Manage environments for vela applications to run.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

52
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_exec.md Normal file
View File

@ -0,0 +1,52 @@
---
title: vela exec
---
Execute command in a container
### Synopsis
Execute command inside container based vela application.
```
vela exec [flags] APP_NAME -- COMMAND [args...]
```
### Examples
```
# Get output from running 'date' command from app pod, using the first container by default
vela exec my-app -- date
# Switch to raw terminal mode, sends stdin to 'bash' in containers of application my-app
# and sends stdout/stderr from 'bash' back to the client
vela exec my-app -i -t -- bash -il
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for exec
-n, --namespace string specify the Kubernetes namespace to use
--pod-running-timeout duration The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running (default 1m0s)
-i, --stdin Pass stdin to the container (default true)
-t, --tty Stdin is a TTY (default true)
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

37
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_export.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela export
---
Export deploy manifests from appfile
### Synopsis
Export deploy manifests from appfile or application.
```
vela export
```
### Options
```
-e, --env string specify environment name for application
-f, --file string specify file path for appfile
-h, --help help for export
-n, --namespace string specify the Kubernetes namespace to use
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

30
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_help.md Normal file
View File

@ -0,0 +1,30 @@
---
title: vela help
---
Help about any command
```
vela help [command]
```
### Options
```
-h, --help help for help
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

43
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_init.md Normal file
View File

@ -0,0 +1,43 @@
---
title: vela init
---
Create scaffold for an application.
### Synopsis
Create scaffold for vela application.
```
vela init
```
### Examples
```
vela init
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for init
-n, --namespace string specify the Kubernetes namespace to use
--render-only Rendering vela.yaml in current dir and do not deploy
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_install.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela install
---
Installs or Upgrades Kubevela control plane on a Kubernetes cluster.
### Synopsis
The Kubevela CLI allows installing Kubevela on any Kubernetes derivative to which your kube config is pointing to.
```
vela install [flags]
```
### Options
```
-d, --detail show detail log of installation (default true)
-f, --file string custom the chart path of KubeVela control plane
-h, --help help for install
-n, --namespace string namespace scope for installing KubeVela Core (default "vela-system")
-r, --reuse will re-use the user's last supplied values. (default true)
--set stringArray set values on the command line (can specify multiple or separate values with commas: key1=val1,key2=val2)
-v, --version string (default "UNKNOWN")
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

46
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_live-diff.md Normal file
View File

@ -0,0 +1,46 @@
---
title: vela live-diff
---
Dry-run application locally, and diff with a deployed application version
### Synopsis
Dry-run application locally, and diff with a deployed application version.
```
vela live-diff
```
### Examples
```
vela live-diff -f app-v2.yaml -r app-v1 --context 10
```
### Options
```
-r, --Revision string specify an application Revision name, by default, it will compare with the latest Revision
-c, --context int output number lines of context around changes, by default show all unchanged lines (default -1)
-d, --definition string specify a file or directory containing capability definitions, they will only be used in dry-run rather than applied to K8s cluster
-e, --env string specify environment name for application
-f, --file string application file name (default "./app.yaml")
-h, --help help for live-diff
-n, --namespace string specify the Kubernetes namespace to use
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

38
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_logs.md Normal file
View File

@ -0,0 +1,38 @@
---
title: vela logs
---
Tail logs for application.
### Synopsis
Tail logs for vela application.
```
vela logs APP_NAME [flags]
```
### Options
```
-c, --container string specify container name for output
-e, --env string specify environment name for application
-h, --help help for logs
-n, --namespace string specify the Kubernetes namespace to use
-o, --output string output format for logs, support: [default, raw, json] (default "default")
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

43
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_ls.md Normal file
View File

@ -0,0 +1,43 @@
---
title: vela ls
---
List applications
### Synopsis
List all vela applications.
```
vela ls
```
### Examples
```
vela ls
```
### Options
```
-A, --all-namespaces If true, check the specified action in all namespaces.
-e, --env string specify environment name for application
-h, --help help for ls
-n, --namespace string specify the Kubernetes namespace to use
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

45
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_port-forward.md Normal file
View File

@ -0,0 +1,45 @@
---
title: vela port-forward
---
Forward local ports to container/service port of vela application.
### Synopsis
Forward local ports to container/service port of vela application.
```
vela port-forward APP_NAME [flags]
```
### Examples
```
port-forward APP_NAME [options] [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N]
```
### Options
```
--address strings Addresses to listen on (comma separated). Only accepts IP addresses or localhost as a value. When localhost is supplied, vela will try to bind on both 127.0.0.1 and ::1 and will fail if neither of these addresses are available to bind. (default [localhost])
-e, --env string specify environment name for application
-h, --help help for port-forward
-n, --namespace string specify the Kubernetes namespace to use
--pod-running-timeout duration The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running (default 1m0s)
--route forward ports from route trait service
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

33
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_registry.md Normal file
View File

@ -0,0 +1,33 @@
---
title: vela registry
---
Manage Registry
### Synopsis
Manage Registry of X-Definitions for extension.
### Options
```
-h, --help help for registry
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela registry config](vela_registry_config) - Configure (add if not exist) a registry, default is local (built-in capabilities)
* [vela registry ls](vela_registry_ls) - List all registry
* [vela registry remove](vela_registry_remove) - Remove specified registry
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

41
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_registry_config.md Normal file
View File

@ -0,0 +1,41 @@
---
title: vela registry config
---
Configure (add if not exist) a registry, default is local (built-in capabilities)
### Synopsis
Configure (add if not exist) a registry, default is local (built-in capabilities)
```
vela registry config <registryName> <centerURL> [flags]
```
### Examples
```
vela registry config my-registry https://github.com/oam-dev/catalog/tree/master/registry
```
### Options
```
-h, --help help for config
-t, --token string Github Repo token
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela registry](vela_registry) - Manage Registry
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_registry_ls.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela registry ls
---
List all registry
### Synopsis
List all configured registry
```
vela registry ls [flags]
```
### Examples
```
vela registry ls
```
### Options
```
-h, --help help for ls
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela registry](vela_registry) - Manage Registry
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_registry_remove.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela registry remove
---
Remove specified registry
### Synopsis
Remove specified registry
```
vela registry remove <centerName> [flags]
```
### Examples
```
vela registry remove mycenter
```
### Options
```
-h, --help help for remove
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela registry](vela_registry) - Manage Registry
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

43
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_show.md Normal file
View File

@ -0,0 +1,43 @@
---
title: vela show
---
Show the reference doc for a component, trait or workflow.
### Synopsis
Show the reference doc for component, trait or workflow types.
```
vela show [flags]
```
### Examples
```
show webservice
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for show
-n, --namespace string specify the Kubernetes namespace to use
--web start web doc site
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

44
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_status.md Normal file
View File

@ -0,0 +1,44 @@
---
title: vela status
---
Show status of an application.
### Synopsis
Show status of vela application.
```
vela status APP_NAME [flags]
```
### Examples
```
vela status APP_NAME
```
### Options
```
-p, --endpoint show all service endpoints of the application
-e, --env string specify environment name for application
-h, --help help for status
-n, --namespace string specify the Kubernetes namespace to use
-s, --svc string service name
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

46
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_trait.md Normal file
View File

@ -0,0 +1,46 @@
---
title: vela trait
---
List/get traits.
### Synopsis
List trait types installed and discover more in registry.
```
vela trait [flags]
```
### Examples
```
vela trait
```
### Options
```
--discover discover traits in registries
-h, --help help for trait
--label --label type=terraform a label to filter components, the format is --label type=terraform
--registry string specify the registry name (default "default")
--token string specify token when using --url to specify registry url
--url string specify the registry URL
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela trait get](vela_trait_get) - get trait from registry
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

43
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_trait_get.md Normal file
View File

@ -0,0 +1,43 @@
---
title: vela trait get
---
get trait from registry
### Synopsis
get trait from registry
```
vela trait get <trait> [flags]
```
### Examples
```
vela trait get <trait>
```
### Options
```
-h, --help help for get
```
### Options inherited from parent commands
```
--registry string specify the registry name (default "default")
--token string specify token when using --url to specify registry url
--url string specify the registry URL
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela trait](vela_trait) - List/get traits.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

31
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_uischema.md Normal file
View File

@ -0,0 +1,31 @@
---
title: vela uischema
---
Manage UI schema for addons.
### Synopsis
Manage UI schema for addons.
### Options
```
-h, --help help for uischema
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela uischema apply](vela_uischema_apply) - apply <ui schema file/dir path>
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

34
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_uischema_apply.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela uischema apply
---
apply <ui schema file/dir path>
### Synopsis
apply UI schema from a file or dir
```
vela uischema apply [flags]
```
### Options
```
-h, --help help for apply
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela uischema](vela_uischema) - Manage UI schema for addons.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

42
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_uninstall.md Normal file
View File

@ -0,0 +1,42 @@
---
title: vela uninstall
---
Uninstalls KubeVela from a Kubernetes cluster
### Synopsis
Uninstalls KubeVela from a Kubernetes cluster.
```
vela uninstall [flags]
```
### Examples
```
vela uninstall
```
### Options
```
-d, --detail show detail log of installation (default true)
-h, --help help for uninstall
-n, --namespace string namespace scope for installing KubeVela Core (default "vela-system")
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

37
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_up.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela up
---
Apply an appfile or application from file
### Synopsis
Create or update vela application from file or URL, both appfile or application object format are supported.
```
vela up
```
### Options
```
-e, --env string specify environment name for application
-f, --file string specify file path for appfile or application, it could be a remote url.
-h, --help help for up
-n, --namespace string specify the Kubernetes namespace to use
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

35
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_version.md Normal file
View File

@ -0,0 +1,35 @@
---
title: vela version
---
Prints vela build version information
### Synopsis
Prints vela build version information.
```
vela version [flags]
```
### Options
```
-h, --help help for version
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela version list](vela_version_list) - List all available versions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

35
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_version_list.md Normal file
View File

@ -0,0 +1,35 @@
---
title: vela version list
---
List all available versions
### Synopsis
Query all available versions from remote server.
```
vela version list [flags]
```
### Options
```
-a, --all List all available versions, if not, only list newer version
-h, --help help for list
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela version](vela_version) - Prints vela build version information
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

35
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_workflow.md Normal file
View File

@ -0,0 +1,35 @@
---
title: vela workflow
---
Operate application delivery workflow.
### Synopsis
Operate the Workflow during Application Delivery.
### Options
```
-h, --help help for workflow
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela workflow restart](vela_workflow_restart) - Restart an application workflow.
* [vela workflow resume](vela_workflow_resume) - Resume a suspend application workflow.
* [vela workflow rollback](vela_workflow_rollback) - Rollback an application workflow to the latest revision.
* [vela workflow suspend](vela_workflow_suspend) - Suspend an application workflow.
* [vela workflow terminate](vela_workflow_terminate) - Terminate an application workflow.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

42
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_workflow_restart.md Normal file
View File

@ -0,0 +1,42 @@
---
title: vela workflow restart
---
Restart an application workflow.
### Synopsis
Restart an application workflow in cluster.
```
vela workflow restart [flags]
```
### Examples
```
vela workflow restart <application-name>
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for restart
-n, --namespace string specify the Kubernetes namespace to use
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela workflow](vela_workflow) - Operate application delivery workflow.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

42
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_workflow_resume.md Normal file
View File

@ -0,0 +1,42 @@
---
title: vela workflow resume
---
Resume a suspend application workflow.
### Synopsis
Resume a suspend application workflow in cluster.
```
vela workflow resume [flags]
```
### Examples
```
vela workflow resume <application-name>
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for resume
-n, --namespace string specify the Kubernetes namespace to use
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela workflow](vela_workflow) - Operate application delivery workflow.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

42
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_workflow_rollback.md Normal file
View File

@ -0,0 +1,42 @@
---
title: vela workflow rollback
---
Rollback an application workflow to the latest revision.
### Synopsis
Rollback an application workflow to the latest revision.
```
vela workflow rollback [flags]
```
### Examples
```
vela workflow rollback <application-name>
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for rollback
-n, --namespace string specify the Kubernetes namespace to use
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela workflow](vela_workflow) - Operate application delivery workflow.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

42
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_workflow_suspend.md Normal file
View File

@ -0,0 +1,42 @@
---
title: vela workflow suspend
---
Suspend an application workflow.
### Synopsis
Suspend an application workflow in cluster.
```
vela workflow suspend [flags]
```
### Examples
```
vela workflow suspend <application-name>
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for suspend
-n, --namespace string specify the Kubernetes namespace to use
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela workflow](vela_workflow) - Operate application delivery workflow.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

42
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/cli/vela_workflow_terminate.md Normal file
View File

@ -0,0 +1,42 @@
---
title: vela workflow terminate
---
Terminate an application workflow.
### Synopsis
Terminate an application workflow in cluster.
```
vela workflow terminate [flags]
```
### Examples
```
vela workflow terminate <application-name>
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for terminate
-n, --namespace string specify the Kubernetes namespace to use
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela workflow](vela_workflow) - Operate application delivery workflow.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 9-Feb-2022, refer to [script in KubeVela](https://github.com/oam-dev/kubevela/tree/master/hack/docgen).

105
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/concepts.md Normal file
View File

@ -0,0 +1,105 @@
---
title: 核心概念
---
*"KubeVela 是一个面向混合环境的、简单易用、同时高可扩展的应用交付与管理引擎。"*
在本部分中，我们会对 KubeVela 的核心思想进行详细解释，并进一步阐清一些在本项目中被广泛使用的技术术语。
## 综述
首先，KubeVela 引入了下面所述的带有关注点分离思想的工作流：
- **平台团队**
- 通过给部署环境和可重复使用的能力模块编写模板来构建应用，并将他们注册到集群中。
- **业务用户**
- 选择部署环境、模型和可用模块来组装应用，并把应用部署到目标环境中。
工作流如下图所示:
![alt](resources/how-it-works.png)
这种基于模板的工作流使得平台团队能够在一系列的 Kubernetes CRD 之上，引导用户遵守他们构建的最佳实践和 部署经验，并且可以很自然地为业务用户提供 PaaS 级别的体验（比如：“以应用为中心”，“高层次的抽象”，“自助式运维操作”等等）。
![alt](resources/what-is-kubevela.png)
下面开始介绍 KubeVela 的核心概念
## `Application`
应用（*Application*），是 KubeVela 的核心 API。它使得业务开发者只需要基于一个单一的制品和一些简单的原语就可以构建完整的应用。
在应用交付平台中，有一个 *Application* 的概念尤为重要，因为这可以很大程度上简化运维任务，并且作为一个锚点避免操作过程中产生配置漂移的问题。同时，它也帮助应用交付过程中引入 Kubernetes的能力提供了一个更简单的、且不用依赖底层细节的途径。 举个例子，开发者能够不需要每次都定义一个详细的 Kubernetes Deployment + Service 的组合来建模一个 web service ，或者不用依靠底层的 KEDA ScaleObject 来获取自动扩容的需求。
### 举例
一个需要两个组件（比如 `frontend` 和 `backend` ）的 `website` 应用可以如下建模：
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: website
spec:
components:
- name: backend
type: worker
properties:
image: busybox
cmd:
- sleep
- '1000'
- name: frontend
type: webservice
properties:
image: nginx
traits:
- type: autoscaler
properties:
min: 1
max: 10
- type: sidecar
properties:
name: "sidecar-test"
image: "fluentd"
```
## 构建抽象
不像大多数的高层次的抽象，KubeVela 中的 `Application` 资源是一种积木风格的对象，而且它甚至没有固定的 schema。相反，它由构建模块，比如app components（应用组件）和 traits（运维能力）等，构成。这种构建模块允许开发者通过自己定义的抽象来集成平台的能力到此应用定义。
定义抽象和建模平台能力的构建模块是 `ComponentDefinition` 和 `TraitDefinition` 。
### ComponentDefinition
`ComponentDefinition` ，组件定义，是一个预先定义好的，用于可部署的工作负载的*模板*。它包括了模板，参数化的和工作负载特性的信息作为一种声明式API资源。
因此，`Application` 抽象本质上定义了在目标集群中，用户想要如何来**实例化**给定 component definition。特别地，`.type` 字段引用安装了的 `ComponentDefinition` 的名字; `.properties` 字段是用户设置的用来实例化它的值。
一些主要的 component definition 有：长期运行的 web service、一次性的 task 和 Redis数据库。所有的 component definition 均应在平台提前安装，或由组件提供商，比如第三方软件供应商，来提供。
### TraitDefinition
可选的，每一个组件都有一个 `.traits` 部分。这个部分通过使用操作类行为，比如负载均衡策略、网络入口路由、自动扩容策略，和升级策略等，来增强组件实例。
*Trait*，运维能力，是由平台提供的操作性质的特性。为了给组件实例附加运维能力，用户需要声明 `.type` 字段来引用特定的 `TraitDefinition` 和 `.properties` ，以此来设置给定运维能力的属性值。相似的，`TraitDefiniton` 同样允许用户来给这些操作特性定义*模板*。
在 KubeVela 中，我们还将 component definition 和 trait definitions 定义称为 *“capability definitions”* 。
## Environment
在将应用发布到生产环境之前，在 testing/staging workspace 中测试代码很重要。在 KubeVela，我们将这些 workspace 描述为 “deployment environments”，部署环境，或者简称为 “environments”，环境。每一个环境都有属于自己的配置（比如说，domain，Kubernetes集群，命名空间，配置数据和访问控制策略等）来允许用户创建不同的部署环境，比如 “test”，和 “production”。
到目前为止，一个 KubeVela 的 `environment` 只映射到一个 Kubernetes 的命名空间。集群级环境正在开发中。
### 总结
KubeVela的主要概念由下图所示：
![alt](resources/concepts.png)
## 架构
KubeVela的整体架构由下图所示：
![alt](resources/arch.png)
特别的，application controller 负责应用的抽象和封装（比如负责 `Application` 和 `Definition` 的 controller ）。Rollout contoller 负责以整个应用为单位处理渐进式 rollout 策略。多集群部署引擎，在流量切分和 rollout 特性的支持下，负责跨多集群和环境部署应用。

125
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/developers/cap-center.md Normal file
View File

@ -0,0 +1,125 @@
---
title: 能力管理
---
在 KubeVela 中，开发者可以从任何包含 OAM 抽象文件的 GitHub 仓库中安装更多的能力（例如：新 component 类型或者 traits ）。我们将这些 GitHub 仓库称为 _Capability Centers_ 。
KubeVela 可以从这些仓库中自动发现 OAM 抽象文件，并且同步这些能力到我们的 KubeVela 平台中。
## 添加能力中心
新增能力中心到 KubeVela：
```bash
vela registry config my-center https://github.com/oam-dev/catalog/tree/master/registry
Successfully configured registry my-center
```
现在，该能力中心 `my-center` 已经可以使用。
## 列出能力中心
你可以列出或者添加更多能力中心。
```bash
vela registry ls
NAME URL
default oss://registry.kubevela.net/
my-center https://github.com/oam-dev/catalog/tree/master/registry
```
## [可选] 删除能力中心
删除一个
```bash
vela registry remove my-center
```
## 列出所有可用的能力中心
列出某个中心所有可用的 ComponentDefinition/TraitDefinition。
```bash
vela trait --discover --registry=my-center
vela comp --discover --registry=my-center
```
## 从能力中心安装能力
我们开始从 `my-center` 安装新 component `clonesetservice` 到你的 KubeVela 平台。
你可以先安装 OpenKruise 。
```shell
helm install kruise https://github.com/openkruise/kruise/releases/download/v0.7.0/kruise-chart.tgz
```
从 `my-center` 中安装 `clonesetservice` component 。
```bash
vela comp get clonesetservice --registry=my-center
```
## 使用新安装的能力
我们先检查 `clonesetservice` component 是否已经被安装到平台：
```bash
$ vela components
NAME NAMESPACE WORKLOAD DESCRIPTION
clonesetservice vela-system clonesets.apps.kruise.io Describes long-running, scalable, containerized services
that have a stable network endpoint to receive external
network traffic from customers. If workload type is skipped
for any service defined in Appfile, it will be defaulted to
`webservice` type.
```
很棒！现在我们部署使用 Appfile 部署一个应用。
```bash
$ cat << EOF > vela.yaml
name: testapp
services:
testsvc:
type: clonesetservice
image: crccheck/hello-world
port: 8000
EOF
```
```bash
$ vela up
Parsing vela appfile ...
Load Template ...
Rendering configs for service (testsvc)...
Writing deploy config to (.vela/deploy.yaml)
Applying application ...
Checking if app has been deployed...
App has not been deployed, creating a new deployment...
Updating: core.oam.dev/v1alpha2, Kind=HealthScope in default
✅ App has been deployed 🚀🚀🚀
Port forward: vela port-forward testapp
SSH: vela exec testapp
Logging: vela logs testapp
App status: vela status testapp
Service status: vela status testapp --svc testsvc
```
随后，该 cloneset 已经被部署到你的环境。
```shell
$ kubectl get clonesets.apps.kruise.io
NAME DESIRED UPDATED UPDATED_READY READY TOTAL AGE
testsvc 1 1 1 1 1 46s
```
## 删除能力
> 注意，删除能力前请先确认没有被应用引用。
```bash
kubectl delete componentdefinition -n vela-system clonesetservice
```

9
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/developers/check-logs.md Normal file
View File

@ -0,0 +1,9 @@
---
title: 查看应用的日志
---
```bash
$ vela logs testapp
```
执行如上命令后就能查看指定的 testapp 容器的日志。如果只有一个容器，则默认会查看该容器的日志

103
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/developers/check-ref-doc.md Normal file
View File

@ -0,0 +1,103 @@
---
title: The Reference Documentation Guide of Capabilities
---
In this documentation, we will show how to check the detailed schema of a given capability (i.e. workload type or trait).
This may sound challenging because every capability is a "plug-in" in KubeVela (even for the built-in ones), also, it's by design that KubeVela allows platform platform-engineerss to modify the capability templates at any time. In this case, do we need to manually write documentation for every newly installed capability? And how can we ensure those documentations for the system is up-to-date?
## Using Browser
Actually, as a important part of its "extensibility" design, KubeVela will always **automatically generate** reference documentation for every workload type or trait registered in your Kubernetes cluster, based on its template in definition of course. This feature works for any capability: either built-in ones or your own workload types/traits.
Thus, as an end user, the only thing you need to do is:
```console
$ vela show WORKLOAD_TYPE or TRAIT --web
```
This command will automatically open the reference documentation for given workload type or trait in your default browser.
### For Workload Types
Let's take `$ vela show webservice --web` as example. The detailed schema documentation for `Web Service` workload type will show up immediately as below:
![](../resources/vela_show_webservice.jpg)
Note that there's in the section named `Specification`, it even provides you with a full sample for the usage of this workload type with a fake name `my-service-name`.
### For Traits
Similarly, we can also do `$ vela show autoscale --web`:
![](../resources/vela_show_autoscale.jpg)
With these auto-generated reference documentations, we could easily complete the application description by simple copy-paste, for example:
```yaml
name: helloworld
services:
backend: # copy-paste from the webservice ref doc above
image: oamdev/testapp:v1
cmd: ["node", "server.js"]
port: 8080
cpu: "0.1"
autoscale: # copy-paste and modify from autoscaler ref doc above
min: 1
max: 8
cron:
startAt: "19:00"
duration: "2h"
days: "Friday"
replicas: 4
timezone: "America/Los_Angeles"
```
## Using Terminal
This reference doc feature also works for terminal-only case. For example:
```shell
$ vela show webservice
# Properties
+-------+----------------------------------------------------------------------------------+---------------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
+-------+----------------------------------------------------------------------------------+---------------+----------+---------+
| cmd | Commands to run in the container | []string | false | |
| env | Define arguments by using environment variables | [[]env](#env) | false | |
| image | Which image would you like to use for your service | string | true | |
| port | Which port do you want customer traffic sent to | int | true | 80 |
| cpu | Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core) | string | false | |
+-------+----------------------------------------------------------------------------------+---------------+----------+---------+
## env
+-----------+-----------------------------------------------------------+-------------------------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
+-----------+-----------------------------------------------------------+-------------------------+----------+---------+
| name | Environment variable name | string | true | |
| value | The value of the environment variable | string | false | |
| valueFrom | Specifies a source the value of this var should come from | [valueFrom](#valueFrom) | false | |
+-----------+-----------------------------------------------------------+-------------------------+----------+---------+
### valueFrom
+--------------+--------------------------------------------------+-------------------------------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
+--------------+--------------------------------------------------+-------------------------------+----------+---------+
| secretKeyRef | Selects a key of a secret in the pod's namespace | [secretKeyRef](#secretKeyRef) | true | |
+--------------+--------------------------------------------------+-------------------------------+----------+---------+
#### secretKeyRef
+------+------------------------------------------------------------------+--------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
+------+------------------------------------------------------------------+--------+----------+---------+
| name | The name of the secret in the pod's namespace to select from | string | true | |
| key | The key of the secret to select from. Must be a valid secret key | string | true | |
+------+------------------------------------------------------------------+--------+----------+---------+
```
> Note that for all the built-in capabilities, we already published their reference docs [here](https://kubevela.io/#/en/developers/references/) based on the same doc generation mechanism.

85
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/developers/config-app.md Normal file
View File

@ -0,0 +1,85 @@
---
title: 在应用程序中配置数据或环境
---
`vela` 提供 `config` 命令用于管理配置数据。
## `vela config set`
```bash
$ vela config set test a=b c=d
reading existing config data and merging with user input
config data saved successfully ✅
```
## `vela config get`
```bash
$ vela config get test
Data:
a: b
c: d
```
## `vela config del`
```bash
$ vela config del test
config (test) deleted successfully
```
## `vela config ls`
```bash
$ vela config set test a=b
$ vela config set test2 c=d
$ vela config ls
NAME
test
test2
```
## 在应用程序中配置环境变量
可以在应用程序中将配置数据设置为环境变量。
```bash
$ vela config set demo DEMO_HELLO=helloworld
```
将以下内容保存为 `vela.yaml` 到当前目录中：
```yaml
name: testapp
services:
env-config-demo:
image: heroku/nodejs-hello-world
config: demo
```
然后运行：
```bash
$ vela up
Parsing vela.yaml ...
Loading templates ...
Rendering configs for service (env-config-demo)...
Writing deploy config to (.vela/deploy.yaml)
Applying deploy configs ...
Checking if app has been deployed...
App has not been deployed, creating a new deployment...
✅ App has been deployed 🚀🚀🚀
Port forward: vela port-forward testapp
SSH: vela exec testapp
Logging: vela logs testapp
App status: vela status testapp
Service status: vela status testapp --svc env-config-demo
```
检查环境变量：
```
$ vela exec testapp -- printenv | grep DEMO_HELLO
DEMO_HELLO=helloworld
```

89
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/developers/config-enviroments.md Normal file
View File

@ -0,0 +1,89 @@
---
title: 设置部署环境
---
通过部署环境，可以为你的应用配置全局工作空间、email 以及域名。通常情况下，部署环境分为 `test` （测试环境）、`staging` （生产镜像环境）、`prod`（生产环境）等。
## 创建环境
```bash
$ vela env init demo --email my@email.com
environment demo created, Namespace: default, Email: my@email.com
```
## 检查部署环境元数据
```bash
$ vela env ls
NAME CURRENT NAMESPACE EMAIL DOMAIN
default default
demo * default my@email.com
```
默认情况下, 将会在 K8s 默认的命名空间 `default` 下面创建环境。
## 配置变更
你可以通过再次执行如下命令变更环境配置。
```bash
$ vela env init demo --namespace demo
environment demo created, Namespace: demo, Email: my@email.com
```
```bash
$ vela env ls
NAME CURRENT NAMESPACE EMAIL DOMAIN
default default
demo * demo my@email.com
```
**注意：部署环境只针对新创建的应用生效，之前创建的应用不会受到任何影响。**
## [可选操作] 配置域名（前提：拥有 public IP）
如果你使用的是云厂商提供的 k8s 服务并已为 ingress 配置了公网 IP，那么就可以在环境中配置域名来使用，之后你就可以通过该域名来访问应用，并且自动支持 mTLS 双向认证。
例如, 你可以使用下面的命令方式获得 ingress service 的公网 IP：
```bash
$ kubectl get svc -A | grep LoadBalancer
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-ingress-lb LoadBalancer 172.21.2.174 123.57.10.233 80:32740/TCP,443:32086/TCP 41d
```
命令响应结果 `EXTERNAL-IP` 列的值：123.57.10.233 就是公网 IP。 在 DNS 中添加一条 `A` 记录吧：
```
*.your.domain => 123.57.10.233
```
如果没有自定义域名，那么你可以使用如 `123.57.10.233.xip.io` 作为域名，其中 `xip.io` 将会自动路由到前面的 IP `123.57.10.233`。
```bash
$ vela env init demo --domain 123.57.10.233.xip.io
environment demo updated, Namespace: demo, Email: my@email.com
```
### 在 Appfile 中使用域名
由于在部署环境中已经配置了全局域名, 就不需要在 route 配置中特别指定域名了。
```yaml
# in demo environment
services:
express-server:
...
route:
rules:
- path: /testapp
rewriteTarget: /
```
```
$ curl http://123.57.10.233.xip.io/testapp
Hello World
```

10
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/developers/exec-cmd.md Normal file
View File

@ -0,0 +1,10 @@
---
title: 在容器中运行命令
---
运行如下命令:
```
$ vela exec testapp -- /bin/sh
```
这将打开一个 shell 访问 testapp 容器。

238
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/developers/extensions/set-autoscale.md Normal file
View File

@ -0,0 +1,238 @@
---
title: Automatically scale workloads by resource utilization metrics and cron
---
## Prerequisite
Make sure auto-scaler trait controller is installed in your cluster
Install auto-scaler trait controller with helm
1. Add helm chart repo for autoscaler trait
```shell script
helm repo add oam.catalog http://oam.dev/catalog/
```
2. Update the chart repo
```shell script
helm repo update
```
3. Install autoscaler trait controller
```shell script
helm install --create-namespace -n vela-system autoscalertrait oam.catalog/autoscalertrait
Autoscale depends on metrics server, please [enable it in your Kubernetes cluster](../references/devex/faq#autoscale-how-to-enable-metrics-server-in-various-kubernetes-clusters) at the beginning.
> Note: autoscale is one of the extension capabilities [installed from cap center](../cap-center),
> please install it if you can't find it in `vela traits`.
## Setting cron auto-scaling policy
Introduce how to automatically scale workloads by cron.
1. Prepare Appfile
```yaml
name: testapp
services:
express-server:
# this image will be used in both build and deploy steps
image: oamdev/testapp:v1
cmd: ["node", "server.js"]
port: 8080
autoscale:
min: 1
max: 4
cron:
startAt: "14:00"
duration: "2h"
days: "Monday, Thursday"
replicas: 2
timezone: "America/Los_Angeles"
```
> The full specification of `autoscale` could show up by `$ vela show autoscale`.
2. Deploy an application
```
$ vela up
Parsing vela.yaml ...
Loading templates ...
Rendering configs for service (express-server)...
Writing deploy config to (.vela/deploy.yaml)
Applying deploy configs ...
Checking if app has been deployed...
App has not been deployed, creating a new deployment...
✅ App has been deployed 🚀🚀🚀
Port forward: vela port-forward testapp
SSH: vela exec testapp
Logging: vela logs testapp
App status: vela status testapp
Service status: vela status testapp --svc express-server
```
3. Check the replicas and wait for the scaling to take effect
Check the replicas of the application, there is one replica.
```
$ vela status testapp
About:
Name: testapp
Namespace: default
Created at: 2020-11-05 17:09:02.426632 +0800 CST
Updated at: 2020-11-05 17:09:02.426632 +0800 CST
Services:
- Name: express-server
Type: webservice
HEALTHY Ready: 1/1
Traits:
- ✅ autoscale: type: cron replicas(min/max/current): 1/4/1
Last Deployment:
Created at: 2020-11-05 17:09:03 +0800 CST
Updated at: 2020-11-05T17:09:02+08:00
```
Wait till the time clocks `startAt`, and check again. The replicas become to two, which is specified as
`replicas` in `vela.yaml`.
```
$ vela status testapp
About:
Name: testapp
Namespace: default
Created at: 2020-11-10 10:18:59.498079 +0800 CST
Updated at: 2020-11-10 10:18:59.49808 +0800 CST
Services:
- Name: express-server
Type: webservice
HEALTHY Ready: 2/2
Traits:
- ✅ autoscale: type: cron replicas(min/max/current): 1/4/2
Last Deployment:
Created at: 2020-11-10 10:18:59 +0800 CST
Updated at: 2020-11-10T10:18:59+08:00
```
Wait after the period ends, the replicas will be one eventually.
## Setting auto-scaling policy of CPU resource utilization
Introduce how to automatically scale workloads by CPU resource utilization.
1. Prepare Appfile
Modify `vela.yaml` as below. We add field `services.express-server.cpu` and change the auto-scaling policy
from cron to cpu utilization by updating filed `services.express-server.autoscale`.
```yaml
name: testapp
services:
express-server:
image: oamdev/testapp:v1
cmd: ["node", "server.js"]
port: 8080
cpu: "0.01"
autoscale:
min: 1
max: 5
cpuPercent: 10
```
2. Deploy an application
```bash
$ vela up
```
3. Expose the service entrypoint of the application
```
$ vela port-forward helloworld 80
Forwarding from 127.0.0.1:80 -> 80
Forwarding from [::1]:80 -> 80
Forward successfully! Opening browser ...
Handling connection for 80
Handling connection for 80
Handling connection for 80
Handling connection for 80
```
On your macOS, you might need to add `sudo` ahead of the command.
4. Monitor the replicas changing
Continue to monitor the replicas changing when the application becomes overloaded. You can use Apache HTTP server
benchmarking tool `ab` to mock many requests to the application.
```
$ ab -n 10000 -c 200 http://127.0.0.1/
This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 1000 requests
```
The replicas gradually increase from one to four.
```
$ vela status helloworld --svc frontend
About:
Name: helloworld
Namespace: default
Created at: 2020-11-05 20:07:21.830118 +0800 CST
Updated at: 2020-11-05 20:50:42.664725 +0800 CST
Services:
- Name: frontend
Type: webservice
HEALTHY Ready: 1/1
Traits:
- ✅ autoscale: type: cpu cpu-utilization(target/current): 5%/10% replicas(min/max/current): 1/5/2
Last Deployment:
Created at: 2020-11-05 20:07:23 +0800 CST
Updated at: 2020-11-05T20:50:42+08:00
```
```
$ vela status helloworld --svc frontend
About:
Name: helloworld
Namespace: default
Created at: 2020-11-05 20:07:21.830118 +0800 CST
Updated at: 2020-11-05 20:50:42.664725 +0800 CST
Services:
- Name: frontend
Type: webservice
HEALTHY Ready: 1/1
Traits:
- ✅ autoscale: type: cpu cpu-utilization(target/current): 5%/14% replicas(min/max/current): 1/5/4
Last Deployment:
Created at: 2020-11-05 20:07:23 +0800 CST
Updated at: 2020-11-05T20:50:42+08:00
```
Stop `ab` tool, and the replicas will decrease to one eventually.

107
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/developers/extensions/set-metrics.md Normal file
View File

@ -0,0 +1,107 @@
---
title: Monitoring Application
---
If your application has exposed metrics, you can easily tell the platform how to collect the metrics data from your app with `metrics` capability.
## Prerequisite
Make sure metrics trait controller is installed in your cluster
Install metrics trait controller with helm
1. Add helm chart repo for metrics trait
```shell script
helm repo add oam.catalog http://oam.dev/catalog/
```
2. Update the chart repo
```shell script
helm repo update
```
3. Install metrics trait controller
```shell script
helm install --create-namespace -n vela-system metricstrait oam.catalog/metricstrait
> Note: metrics is one of the extension capabilities [installed from cap center](../cap-center),
> please install it if you can't find it in `vela traits`.
## Setting metrics policy
Let's run [`christianhxc/gorandom:1.0`](https://github.com/christianhxc/prometheus-tutorial) as an example app.
The app will emit random latencies as metrics.
1. Prepare Appfile:
```bash
$ cat <<EOF > vela.yaml
name: metricapp
services:
metricapp:
type: webservice
image: christianhxc/gorandom:1.0
port: 8080
metrics:
enabled: true
format: prometheus
path: /metrics
port: 0
scheme: http
EOF
```
> The full specification of `metrics` could show up by `$ vela show metrics`.
2. Deploy the application:
```bash
$ vela up
```
3. Check status:
```bash
$ vela status metricapp
About:
Name: metricapp
Namespace: default
Created at: 2020-11-11 17:00:59.436347573 -0800 PST
Updated at: 2020-11-11 17:01:06.511064661 -0800 PST
Services:
- Name: metricapp
Type: webservice
HEALTHY Ready: 1/1
Traits:
- ✅ metrics: Monitoring port: 8080, path: /metrics, format: prometheus, schema: http.
Last Deployment:
Created at: 2020-11-11 17:00:59 -0800 PST
Updated at: 2020-11-11T17:01:06-08:00
```
The metrics trait will automatically discover port and label to monitor if no parameters specified.
If more than one ports found, it will choose the first one by default.
**(Optional) Verify that the metrics are collected on Prometheus**
<details>
Expose the port of Prometheus dashboard:
```bash
kubectl --namespace monitoring port-forward `kubectl -n monitoring get pods -l prometheus=oam -o name` 9090
```
Then access the Prometheus dashboard via http://localhost:9090/targets
![Prometheus Dashboard](../../resources/metrics.jpg)
</details>

163
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/developers/extensions/set-rollout.md Normal file
View File

@ -0,0 +1,163 @@
---
title: Setting Rollout Strategy
---
> Note: rollout is one of the extension capabilities [installed from cap center](../cap-center),
> please install it if you can't find it in `vela traits`.
The `rollout` section is used to configure Canary strategy to release your app.
Add rollout config under `express-server` along with a `route`.
```yaml
name: testapp
services:
express-server:
type: webservice
image: oamdev/testapp:rolling01
port: 80
rollout:
replicas: 5
stepWeight: 20
interval: "30s"
route:
domain: "example.com"
```
> The full specification of `rollout` could show up by `$ vela show rollout`.
Apply this `appfile.yaml`:
```bash
$ vela up
```
You could check the status by:
```bash
$ vela status testapp
About:
Name: testapp
Namespace: myenv
Created at: 2020-11-09 17:34:38.064006 +0800 CST
Updated at: 2020-11-10 17:05:53.903168 +0800 CST
Services:
- Name: testapp
Type: webservice
HEALTHY Ready: 5/5
Traits:
- ✅ rollout: interval=5s
replicas=5
stepWeight=20
- ✅ route: Visiting URL: http://example.com IP: <your-ingress-IP-address>
Last Deployment:
Created at: 2020-11-09 17:34:38 +0800 CST
Updated at: 2020-11-10T17:05:53+08:00
```
Visiting this app by:
```bash
$ curl -H "Host:example.com" http://<your-ingress-IP-address>/
Hello World -- Rolling 01
```
In day 2, assuming we have make some changes on our app and build the new image and name it by `oamdev/testapp:v2`.
Let's update the appfile by:
```yaml
name: testapp
services:
express-server:
type: webservice
- image: oamdev/testapp:rolling01
+ image: oamdev/testapp:rolling02
port: 80
rollout:
replicas: 5
stepWeight: 20
interval: "30s"
route:
domain: example.com
```
Apply this `appfile.yaml` again:
```bash
$ vela up
```
You could run `vela status` several times to see the instance rolling:
```shell script
$ vela status testapp
About:
Name: testapp
Namespace: myenv
Created at: 2020-11-12 19:02:40.353693 +0800 CST
Updated at: 2020-11-12 19:02:40.353693 +0800 CST
Services:
- Name: express-server
Type: webservice
HEALTHY express-server-v2:Ready: 1/1 express-server-v1:Ready: 4/4
Traits:
- ✅ rollout: interval=30s
replicas=5
stepWeight=20
- ✅ route: Visiting by using 'vela port-forward testapp --route'
Last Deployment:
Created at: 2020-11-12 17:20:46 +0800 CST
Updated at: 2020-11-12T19:02:40+08:00
```
You could then try to `curl` your app multiple times and and see how the app being rollout following Canary strategy:
```bash
$ curl -H "Host:example.com" http://<your-ingress-ip-address>/
Hello World -- This is rolling 02
$ curl -H "Host:example.com" http://<your-ingress-ip-address>/
Hello World -- Rolling 01
$ curl -H "Host:example.com" http://<your-ingress-ip-address>/
Hello World -- Rolling 01
$ curl -H "Host:example.com" http://<your-ingress-ip-address>/
Hello World -- This is rolling 02
$ curl -H "Host:example.com" http://<your-ingress-ip-address>/
Hello World -- Rolling 01
$ curl -H "Host:example.com" http://<your-ingress-ip-address>/
Hello World -- This is rolling 02
```
**How `Rollout` works?**
<details>
`Rollout` trait implements progressive release process to rollout your app following [Canary strategy](https://martinfowler.com/bliki/CanaryRelease.html).
In detail, `Rollout` controller will create a canary of your app , and then gradually shift traffic to the canary while measuring key performance indicators like HTTP requests success rate at the same time.
![alt](../../resources/traffic-shifting-analysis.png)
In this sample, for every `10s`, `5%` traffic will be shifted to canary from the primary, until the traffic on canary reached `50%`. At the mean time, the instance number of canary will automatically scale to `replicas: 2` per configured in Appfile.
Based on analysis result of the KPIs during this traffic shifting, a canary will be promoted or aborted if analysis is failed. If promoting, the primary will be upgraded from v1 to v2, and traffic will be fully shifted back to the primary instances. So as result, canary instances will be deleted after the promotion finished.
![alt](../../resources/promotion.png)
> Note: KubeVela's `Rollout` trait is implemented with [Weaveworks Flagger](https://flagger.app/) operator.
</details>

82
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/developers/extensions/set-route.md Normal file
View File

@ -0,0 +1,82 @@
---
title: Setting Routes
---
The `route` section is used to configure the access to your app.
## Prerequisite
Make sure route trait controller is installed in your cluster
Install route trait controller with helm
1. Add helm chart repo for route trait
```shell script
helm repo add oam.catalog http://oam.dev/catalog/
```
2. Update the chart repo
```shell script
helm repo update
```
3. Install route trait controller
```shell script
helm install --create-namespace -n vela-system routetrait oam.catalog/routetrait
> Note: route is one of the extension capabilities [installed from cap center](../cap-center),
> please install it if you can't find it in `vela traits`.
## Setting route policy
Add routing config under `express-server`:
```yaml
services:
express-server:
...
route:
domain: example.com
rules:
- path: /testapp
rewriteTarget: /
```
> The full specification of `route` could show up by `$ vela show route`.
Apply again:
```bash
$ vela up
```
Check the status until we see route is ready:
```bash
$ vela status testapp
About:
Name: testapp
Namespace: default
Created at: 2020-11-04 16:34:43.762730145 -0800 PST
Updated at: 2020-11-11 16:21:37.761158941 -0800 PST
Services:
- Name: express-server
Type: webservice
HEALTHY Ready: 1/1
Last Deployment:
Created at: 2020-11-11 16:21:37 -0800 PST
Updated at: 2020-11-11T16:21:37-08:00
Routes:
- route: Visiting URL: http://example.com IP: <ingress-IP-address>
```
**In [kind cluster setup](../../install#kind)**, you can visit the service via localhost:
> If not in kind cluster, replace 'localhost' with ingress address
```
$ curl -H "Host:example.com" http://localhost/testapp
Hello World
```

249
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/developers/learn-appfile.md Normal file
View File

@ -0,0 +1,249 @@
---
title: 学习使用 Appfile
---
`appfile` 的示例如下:
```yaml
name: testapp
services:
frontend: # 1st service
image: oamdev/testapp:v1
build:
docker:
file: Dockerfile
context: .
cmd: ["node", "server.js"]
port: 8080
route: # trait
domain: example.com
rules:
- path: /testapp
rewriteTarget: /
backend: # 2nd service
type: task # workload type
image: perl
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
```
在底层，`Appfile` 会从源码构建镜像，然后用镜像名称创建 `application` 资源
## Schema
> 在深入学习 Appfile 的详细 schema 之前，我们建议你先熟悉 KubeVela 的[核心概念](../getting-started/core-concept)。
```yaml
name: _app-name_
services:
_service-name_:
# If `build` section exists, this field will be used as the name to build image. Otherwise, KubeVela will try to pull the image with given name directly.
image: oamdev/testapp:v1
build:
docker:
file: _Dockerfile_path_ # relative path is supported, e.g. "./Dockerfile"
context: _build_context_path_ # relative path is supported, e.g. "."
push:
local: kind # optionally push to local KinD cluster instead of remote registry
type: webservice (default) | worker | task
# detailed configurations of workload
... properties of the specified workload ...
_trait_1_:
# properties of trait 1
_trait_2_:
# properties of trait 2
... more traits and their properties ...
_another_service_name_: # more services can be defined
...
```
> 想了解怎样设置特定类型的 workload 或者 trait，请阅读[参考文档手册](./check-ref-doc)
## 示例流程
在以下的流程中，我们会构建并部署一个 NodeJs 的示例 app。该 app 的源文件在[这里](https://github.com/oam-dev/kubevela/tree/master/docs/examples/testapp)。
### 环境要求
- [Docker](https://docs.docker.com/get-docker/) 需要在主机上安装 docker
- [KubeVela](../install) 需要安装 KubeVela 并配置
### 1. 下载测试的 app 的源码
git clone 然后进入 testapp 目录:
```bash
$ git clone https://github.com/oam-dev/kubevela.git
$ cd kubevela/docs/examples/testapp
```
这个示例包含 NodeJs app 的源码和用于构建 app 镜像的Dockerfile
### 2. 使用命令部署 app
我们将会使用目录中的 [vela.yaml](https://github.com/oam-dev/kubevela/tree/master/docs/examples/testapp/vela.yaml) 文件来构建和部署 app
> 注意：请修改 `oamdev` 为你自己注册的账号。或者你可以尝试 `本地测试方式`。
```yaml
image: oamdev/testapp:v1 # change this to your image
```
执行如下命令：
```bash
$ vela up
Parsing vela.yaml ...
Loading templates ...
Building service (express-server)...
Sending build context to Docker daemon 71.68kB
Step 1/10 : FROM mhart/alpine-node:12
---> 9d88359808c3
...
pushing image (oamdev/testapp:v1)...
...
Rendering configs for service (express-server)...
Writing deploy config to (.vela/deploy.yaml)
Applying deploy configs ...
Checking if app has been deployed...
App has not been deployed, creating a new deployment...
✅ App has been deployed 🚀🚀🚀
Port forward: vela port-forward testapp
SSH: vela exec testapp
Logging: vela logs testapp
App status: vela status testapp
Service status: vela status testapp --svc express-server
```
检查服务状态：
```bash
$ vela status testapp
About:
Name: testapp
Namespace: default
Created at: 2020-11-02 11:08:32.138484 +0800 CST
Updated at: 2020-11-02 11:08:32.138485 +0800 CST
Services:
- Name: express-server
Type: webservice
HEALTHY Ready: 1/1
Last Deployment:
Created at: 2020-11-02 11:08:33 +0800 CST
Updated at: 2020-11-02T11:08:32+08:00
Routes:
```
#### 本地测试方式
如果你本地有运行的 [kind](../install) 集群，你可以尝试推送到本地。这种方法无需注册远程容器仓库。
在 `build` 中添加 local 的选项值：
```yaml
build:
# push image into local kind cluster without remote transfer
push:
local: kind
docker:
file: Dockerfile
context: .
```
然后部署到 kind：
```bash
$ vela up
```
<details><summary>(进阶) 检查渲染后的 manifests 文件</summary>
默认情况下，Vela 通过 `./vela/deploy.yaml` 渲染最后的 manifests 文件：
```yaml
apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
name: testapp
namespace: default
spec:
components:
- componentName: express-server
---
apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
name: express-server
namespace: default
spec:
workload:
apiVersion: apps/v1
kind: Deployment
metadata:
name: express-server
...
---
apiVersion: core.oam.dev/v1alpha2
kind: HealthScope
metadata:
name: testapp-default-health
namespace: default
spec:
...
```
</details>
### [可选] 配置其他类型的 workload
至此，我们成功地部署一个默认类型的 workload 的 *[web 服务](../end-user/components/cue/webservice)*。我们也可以添加 *[Task](../end-user/components/cue/task)* 类型的服务到同一个 app 中。
```yaml
services:
pi:
type: task
image: perl
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
express-server:
...
```
然后再次部署 Applfile 来升级应用：
```bash
$ vela up
```
恭喜！你已经学会了使用 `Appfile` 来部署应用了。
## 下一步?
更多关于 app 的操作：
- [Check Application Logs](./check-logs)
- [Execute Commands in Application Container](./exec-cmd)
- [Access Application via Route](./port-forward)

23
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/developers/port-forward.md Normal file
View File

@ -0,0 +1,23 @@
---
title: 端口转发
---
当你的 web 服务 Application 已经被部署就可以通过 `port-forward` 来本地访问。
```bash
$ vela ls
NAME APP WORKLOAD TRAITS STATUS CREATED-TIME
express-server testapp webservice Deployed 2020-09-18 22:42:04 +0800 CST
```
它将直接为你打开浏览器。
```bash
$ vela port-forward testapp
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
Forward successfully! Opening browser ...
Handling connection for 8080
Handling connection for 8080
```

28
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/developers/references/devex/cli.md Normal file
View File

@ -0,0 +1,28 @@
---
title: KubeVela CLI
---
### Auto-completion
#### bash
```bash
To load completions in your current shell session:
$ source <(vela completion bash)
To load completions for every new session, execute once:
Linux:
$ vela completion bash > /etc/bash_completion.d/vela
MacOS:
$ vela completion bash > /usr/local/etc/bash_completion.d/vela
```
#### zsh
```bash
To load completions in your current shell session:
$ source <(vela completion zsh)
To load completions for every new session, execute once:
$ vela completion zsh > "${fpath[1]}/_vela"
```

10
i18n/zh/docusaurus-plugin-content-docs/version-v1.3/developers/references/devex/dashboard.md Normal file
View File

@ -0,0 +1,10 @@
# KubeVela Dashboard (WIP)
KubeVela has a simple client side dashboard for you to interact with. The functionality is equivalent to the vela cli.
```bash
$ vela dashboard
```
> NOTE: this feature is still under development.

Some files were not shown because too many files have changed in this diff Show More