Fix current folder zh out-of-sync (#314)
* Fix next doc zh * Fix current folder
This commit is contained in:
Lei Zhang (Harry)
GitHub
parent
21ab5091e7
commit
95ae82036f
|
|
@ -1,12 +1,12 @@
|
|||
---
|
||||
title: 应用部署计划
|
||||
title: 应用交付模型
|
||||
---
|
||||
|
||||
KubeVela 背后的应用交付模型是 [Open Application Model](../platform-engineers/oam/oam-model)，简称 OAM ，其核心是将应用部署所需的所有组件和各项运维动作，描述为一个统一的、与基础设施无关的“部署计划”，进而实现在混合环境中进行标准化和高效率的应用交付。这个应用部署计划就是这一节所要介绍的 **Application** 对象，也是 OAM 模型的使用者唯一需要了解的 API。
|
||||
KubeVela 背后的应用交付模型是 [Open Application Model](../platform-engineers/oam/oam-model)，简称 OAM ，其核心是将应用部署所需的所有组件和各项运维动作，描述为一个统一的、与基础设施无关的“部署计划”，进而实现在混合环境中进行标准化和高效率的应用交付。
|
||||
|
||||
## 应用程序部署计划（Application）
|
||||
## 应用部署计划（Application）
|
||||
|
||||
KubeVela 通过 YAML 文件的方式描述应用部署计划。一个典型的 YAML 样例如下：
|
||||
KubeVela 通过声明式 YAML 文件的方式来描述应用部署计划。一个典型的样例如下：
|
||||
|
||||
```yaml
|
||||
# sample.yaml
|
||||
|
|
@ -71,27 +71,11 @@ spec:
|
|||
env: prod
|
||||
```
|
||||
|
||||
这里的字段对应着：
|
||||
|
||||
- `apiVersion`：所使用的 OAM API 版本。
|
||||
- `kind`：种类。我们最经常用到的就是 Pod 了。
|
||||
- `metadata`：业务相关信息。比如这次要创建的是一个网站。
|
||||
- `Spec`：描述我们需要应用去交付什么，告诉 Kubernetes 做成什么样。这里我们放入 KubeVela 的 `components`、`policies` 以及 `workflow`。
|
||||
- `components`：一次应用交付部署计划所涵盖的全部组件。
|
||||
- `traits`：应用交付部署计划中每个组件独立的运维特征。
|
||||
- `policies`：作用于整个应用全局的部署策略。
|
||||
- `workflow`：自定义应用交付“执行过程”的工作流。
|
||||
|
||||
下面这张示意图诠释了它们之间的关系：
|
||||
|
||||
|
||||
先有一个总体的应用部署计划 Application。在此基础之上我们申明应用主体为可配置、可部署的组件（Components），并同时对应地去申明，期望每个组件要拥有的相关运维特征 （Traits），如果有需要，还可以申明自定义的执行流程 （Workflow）。
|
||||
|
||||
你使用 KubeVela 的时候，就像在玩“乐高“积木：先拿起一块大的“应用程序”，然后往上固定一块或几块“组件”，组件上又可以贴上任何颜色大小的“运维特征”。同时根据需求的变化，你随时可以重新组装，形成新的应用部署计划。
|
||||
在使用时，一个应用部署计划由组件、运维特征、策略、工作流等多个模块组装而成。
|
||||
|
||||
## 组件（Components）
|
||||
|
||||
KubeVela 内置了常用的组件类型，使用 [KubeVela CLI](../install#3-安装-kubevela-cli) 命令查看：
|
||||
一个应用部署计划可以包含很多待部署组件。KubeVela 内置了常用的组件类型，使用 [KubeVela CLI](../install#3-安装-kubevela-cli) 命令查看：
|
||||
```
|
||||
vela components
|
||||
```
|
||||
|
|
@ -109,13 +93,9 @@ worker vela-system deployments.apps Describes long-run
|
|||
|
||||
```
|
||||
|
||||
你可以继续使用 [Helm 组件](../end-user/components/helm)和[Kustomize 组件](../end-user/components/kustomize)等开箱即用的 KubeVela 内置组件来构建你的应用部署计划。
|
||||
|
||||
如果你是熟悉 Kubernetes 的平台管理员，你可以通过[自定义组件入门](../platform-engineers/components/custom-component)文档了解 KubeVela 是如何扩展任意类型的自定义组件的。特别的，[Terraform 组件](../platform-engineers/components/component-terraform) 就是 KubeVela 自定义组件能力的一个最佳实践，可以满足任意云资源的供应，只需少量云厂商特定配置（如鉴权、云资源模块等），即可成为一个开箱即用的云资源组件。
|
||||
|
||||
## 运维特征（Traits）
|
||||
|
||||
KubeVela 也内置了常用的运维特征类型，使用 [KubeVela CLI](../install#3-安装-kubevela-cli) 命令查看：
|
||||
运维特征是可以随时绑定给待部署组件的、模块化的运维能力。KubeVela 也内置了常用的运维特征类型，使用 [KubeVela CLI](../install#3-安装-kubevela-cli) 命令查看：
|
||||
```
|
||||
vela traits
|
||||
```
|
||||
|
|
@ -130,35 +110,15 @@ scaler vela-system webservice,worker false Manually
|
|||
sidecar vela-system deployments.apps true Inject a sidecar container to the component.
|
||||
```
|
||||
|
||||
你可以继续阅读用户手册里的 [绑定运维特征](../end-user/traits/ingress) ，具体查看如何完成各种运维特征的开发。
|
||||
|
||||
如果你是熟悉 Kubernetes 的平台管理员，也可以了解 KubeVela 中[自定义运维特征](../platform-engineers/traits/customize-trait) 的能力，为你的用户扩展任意运维功能。
|
||||
|
||||
## 应用策略（Policy)
|
||||
|
||||
应用策略（Policy）负责定义应用级别的部署特征，比如健康检查规则、安全组、防火墙、SLO、检验等模块。
|
||||
应用策略的扩展性和功能与运维特征类似，可以灵活的扩展和对接所有云原生应用生命周期管理的能力。相对于运维特征而言，应用策略作用于一个应用的整体，而运维特征作用于应用中的某个组件。
|
||||
|
||||
在本例中，我们设置了一个将应用部署到不同环境的策略。
|
||||
应用策略（Policy）负责定义指定应用交付过程中的策略，比如质量保证策略、安全组策略、防火墙规则、SLO 目标、放置策略等等。
|
||||
|
||||
## 工作流（Workflow）
|
||||
|
||||
KubeVela 的工作流机制允许用户自定义应用部署计划中的步骤，粘合额外的交付流程，指定任意的交付环境。简而言之，工作流提供了定制化的控制逻辑，在原有 Kubernetes 模式交付资源（Apply）的基础上，提供了面向过程的灵活性。比如说，使用工作流实现暂停、人工验证、状态等待、数据流传递、多环境灰度、A/B 测试等复杂操作。
|
||||
工作流允许用户将组件、运维特征、具体的交付动作等一系列元素组装成为一个完整的、面向过程的有向无环图（DAG）。典型的工作流步骤包括暂停、人工审核、等待、数据传递、多环境/多集群发布、A/B 测试等等。
|
||||
|
||||
工作流是 KubeVela 实践过程中基于 OAM 模型的进一步探索和最佳实践，充分遵守 OAM 的模块化理念和可复用特性。每一个工作流模块都是一个“超级粘合剂”，可以将你任意的工具和流程都组合起来。使得你在现代复杂云原生应用交付环境中，可以通过一份申明式的配置，完整的描述所有的交付流程，保证交付过程的稳定性和便利性。
|
||||
|
||||
> 需要说明的是，工作流机制是基于“应用和环境”粒度工作的，它提供了“自定义交付过程”的强大能力。一旦定义工作流，就代表用户自己指定交付的执行过程，原有的组件部署过程会被取代。工作流并非必填能力，用户在不编写 Workflow 过程的情况下，依旧可以完成组件和运维策略的自动化部署。
|
||||
|
||||
在上面的例子中，我们已经可以看到一些工作流的步骤：
|
||||
|
||||
- 这里使用了 `deploy2env` 和 `suspend` 类型的工作流步骤：
|
||||
- `deploy2env` 类型可以根据用户定义的策略将应用部署到指定的环境。
|
||||
- 在第一步完成后，开始执行 `suspend` 类型的工作流步骤。该步骤会暂停工作流，我们可以查看集群中第一个组件的状态，当其成功运行后，再使用 `vela workflow resume website` 命令来继续该工作流。
|
||||
- 当工作流继续运行后，第三个步骤开始部署组件及运维特征。此时我们查看集群，可以看到所以资源都已经被成功部署。
|
||||
|
||||
关于工作流，你可以从[指定环境部署](../end-user/workflow/multi-env)这个工作流节点类型开始逐次了解更多 KubeVela 当前的内置工作流节点类型。
|
||||
|
||||
如果你是熟悉 Kubernetes 的平台管理员，你可以[学习创建自定义工作流节点类型](../platform-engineers/workflow/workflow)，或者通过[设计文档](https://github.com/oam-dev/kubevela/blob/master/design/vela-core/workflow_policy.md)了解工作流系统背后的设计和架构.
|
||||
每一个工作流步骤在 KubeVela 中都是一个完全可插拔的独立功能模块，KubeVela 允许你通过 CUE 语言自由的定义和创建属于自己的工作流步骤来组成自己的交付计划。
|
||||
|
||||
## 下一步
|
||||
|
||||
|
|
@ -166,4 +126,4 @@ KubeVela 的工作流机制允许用户自定义应用部署计划中的步骤
|
|||
|
||||
- 加入 KubeVela 中文社区钉钉群，群号：23310022。
|
||||
- 阅读[**用户手册**](../end-user/components/helm)，从 Helm 组件开始了解如何构建你的应用部署计划。
|
||||
- 阅读[**管理员手册**](../platform-engineers/oam/oam-model)了解 KubeVela 的扩展方式和背后的 OAM 模型原理。
|
||||
- 阅读[**管理员手册**](../platform-engineers/oam/oam-model)了解开放应用模型的细节。
|
||||
|
|
@ -2,37 +2,35 @@
|
|||
title: 系统架构
|
||||
---
|
||||
|
||||
KubeVela 在默认安装模式下，是一个只包含“控制平面”的架构，通过插件机制与各种运行时系统进行紧密配合。其中 KubeVela 核心控制器工作在一个单独的控制面 Kubernetes 集群。
|
||||
如下图所示，自上而下看，用户只与 KubeVela 所在的控制面 Kubernetes 集群发生交互。
|
||||
KubeVela 的整体架构如下所示：
|
||||
|
||||
|
||||
|
||||
## API 层
|
||||
## KubeVela 是一个控制平面系统
|
||||
|
||||
KubeVela API 是声明式的，并以应用程序为中心，用于构建应用交付平台和解决方案。同时，由于它基于原生的 Kubernetes CRD 构建，所以使用起来非常方便。
|
||||
KubeVela 本身是一个的应用交付与管理控制平面，它架在 Kubernetes 集群、云平台等基础设施之上，通过开放应用模型来对组件、云服务、运维能力、交付工作流进行统一的编排和交付。KubeVela 这种与基础设施本身完全解耦的设计，很容易就能帮助你面向混合云/多云/多集群基础设施进行应用交付与管理。
|
||||
|
||||
- 对于大多数不用关心底层细节的用户来说，你只需要：
|
||||
- 查看 KubeVela 所提供的开箱即用的组件、运维特征、应用策略和工作流
|
||||
- 通过 YAML 文件来描述一个应用部署计划
|
||||
- 对于少数管理员来说：
|
||||
- 内置新的组件、运维特征、应用策略和自定义工作流，提供给你的用户
|
||||
- 通常需要使用 YAML 文件和 CUE 语言来完成上述操作
|
||||
而为了能够同任何 CI 流水线或者 GitOps 工具无缝集成，KubeVela 的 API（即开放应用模型）被设计为是声明式、完全以应用为中心的，它包括：
|
||||
- 帮助用户定义应用交付计划的 `Application` 对象
|
||||
- 帮助平台管理员通过 CUE 语言定义平台能力和抽象的 `X-Definition `对象
|
||||
- 比如 `ComponentDefinition`、`TraitDefinition` 等
|
||||
|
||||
## 控制平面层
|
||||
在具体实现上，KubeVela 依赖一个独立的 Kubernetes 集群来运行。这其实是一个“有意为之”的设计：云原生社区中大量的实践已经证明“构建一个科学的、健壮的控制平面系统”，正是 Kubernetes 项目最擅长的工作。所以，依赖 Kubernetes 作为控制平面集群这个选择，虽然会增加一定的部署难度，却能够让我们以最原生的方式为大规模应用交付带来至关重要的“确定性”、“收敛性”和“自动化能力”。
|
||||
|
||||
控制平面层是 KubeVela 的系统核心。它既能帮你按需组装内置能力，或者通过注册各种能力插件满足交付应用的需要，同时在交付后全自动处理 API 请求并管理全局状态。
|
||||
|
||||
主要包含如下三个部分:
|
||||
具体来说，KubeVela 本身主要由如下几个部分组成:
|
||||
|
||||
- **核心控制器** 为整个系统提供核心控制逻辑，完成诸如编排应用和工作流、修订版本快照、垃圾回收等等基础逻辑
|
||||
- **新增内置能力** 由 X-Definitions 创建，注册应用交付所需要的内置能力。基于这个灵活性，我们可以自由地去集成开源生态的能力，按需自定义
|
||||
- **插件能力中心** Addon 让你可以调用生态下常见的能力，甚至直接省去了开发的时间和成本
|
||||
- **模块化能力控制器** 负责对 X-Definitions 对象进行注册和管理。
|
||||
- **插件控制器** 负责注册和管理 KubeVela 运行所需要的第三方插件，比如 Flux、Terraform 组件等等。
|
||||
|
||||
## 执行层
|
||||
### 运行时基础设施
|
||||
|
||||
最后，执行层是应用程序实际会运行的地方。KubeVela 允许你在统一的工作流中，部署和管理应用程序到 Kubernetes 集群，例如本地、托管云服务、IoT/边缘设备端等等。
|
||||
运行时基础设施是应用实际运行的地方。KubeVela 本身是完全与这些基础设施无关的，因此它允许你面向任何环境（包括 Kubernetes 环境，也包括非 Kubernetes 环境比如云平台和边缘设备等）去交付和管理任何类型的应用。
|
||||
|
||||
## 下一步
|
||||
## KubeVela 是可编程的
|
||||
|
||||
- 学习如何用 KubeVela 来进行应用交付, 请查看[应用部署计划](./application)。
|
||||
- 阅读管理员手册学习 [开放应用模型](../platform-engineers/oam/oam-model)。
|
||||
现实世界中的应用交付，往往是一个比较复杂的过程。哪怕是一个比较通用的交付流程，也会因为场景、环境、用户甚至团队的不同而千差万别。所以 KubeVela 从第一天起就采用了一种“可编程”式的方法来实现它的交付模型，这使得 KubeVela 可以以前所未有的灵活度适配到你的应用交付场景中。
|
||||
|
||||
|
||||
|
||||
如果要详细学习 KubeVela 的可编程文档，欢迎查看文档网站中《管理员手册》部分。
|
||||
|
|
|
|||
|
|
@ -0,0 +1,270 @@
|
|||
---
|
||||
title: 工作流步骤
|
||||
---
|
||||
|
||||
本文档将详细介绍 KubeVela 内置的各个工作流步骤。您可以通过自由的组合它们来设计完整的交付工作流。
|
||||
|
||||
## apply-application
|
||||
|
||||
### 简介
|
||||
|
||||
部署当前 Application 中的所有组件和运维特征。
|
||||
|
||||
### 参数
|
||||
|
||||
无需指定参数，主要用于应用部署前后增加自定义步骤。
|
||||
|
||||
### 示例
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: express-server
|
||||
type: apply-application
|
||||
```
|
||||
|
||||
## depends-on-app
|
||||
|
||||
### 简介
|
||||
|
||||
等待指定的 Application 完成。
|
||||
|
||||
### 参数
|
||||
|
||||
| 参数名 | 类型 | 说明 |
|
||||
| :-------: | :----: | :-----------------------------------: |
|
||||
| name | string | 需要等待的 Application 名称 |
|
||||
| namespace | string | 需要等待的 Application 所在的命名空间 |
|
||||
|
||||
### 示例
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: express-server
|
||||
type: depends-on-app
|
||||
properties:
|
||||
name: another-app
|
||||
namespace: default
|
||||
```
|
||||
|
||||
## deploy2env
|
||||
|
||||
### 简介
|
||||
|
||||
将 Application 在不同的环境和策略中部署。
|
||||
|
||||
### 参数
|
||||
|
||||
| 参数名 | 类型 | 说明 |
|
||||
| :----: | :----: | :--------------: |
|
||||
| policy | string | 需要关联的策略名 |
|
||||
| env | string | 需要关联的环境名 |
|
||||
|
||||
### 示例
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: multi-env-demo
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.21
|
||||
port: 80
|
||||
|
||||
policies:
|
||||
- name: env
|
||||
type: env-binding
|
||||
properties:
|
||||
created: false
|
||||
envs:
|
||||
- name: test
|
||||
patch:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.20
|
||||
port: 80
|
||||
placement:
|
||||
namespaceSelector:
|
||||
name: test
|
||||
- name: prod
|
||||
patch:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.20
|
||||
port: 80
|
||||
placement:
|
||||
namespaceSelector:
|
||||
name: prod
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
type: deploy2env
|
||||
properties:
|
||||
policy: env
|
||||
env: test
|
||||
- name: deploy-prod-server
|
||||
type: deploy2env
|
||||
properties:
|
||||
policy: env
|
||||
env: prod
|
||||
```
|
||||
|
||||
## webhook-notification
|
||||
|
||||
### 简介
|
||||
|
||||
向指定的 Webhook 发送信息。
|
||||
|
||||
### 参数
|
||||
|
||||
| 参数名 | 类型 | 说明 |
|
||||
| :--------------: | :----: | :--------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| slack | Object | 可选值，如果需要发送 Slack 信息，则需填写其 url 及 message |
|
||||
| slack.url | String | 必填值，Slack 的 Webhook 地址 |
|
||||
| slack.message | Object | 必填值，需要发送的 Slack 信息，请符合 [Slack 信息规范](https://api.slack.com/reference/messaging/payload) |
|
||||
| dingding | Object | 可选值，如果需要发送钉钉信息，则需填写其 url 及 message |
|
||||
| dingding.url | String | 必填值，钉钉的 Webhook 地址 |
|
||||
| dingding.message | Object | 必填值，需要发送的钉钉信息，请符合 [钉钉信息规范](https://developers.dingtalk.com/document/robots/custom-robot-access/title-72m-8ag-pqw) |
|
||||
|
||||
### 示例
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: dingtalk-message
|
||||
type: webhook-notification
|
||||
properties:
|
||||
dingding:
|
||||
# 钉钉 Webhook 地址，请查看：https://developers.dingtalk.com/document/robots/custom-robot-access
|
||||
url: xxx
|
||||
message:
|
||||
msgtype: text
|
||||
text:
|
||||
context: 开始运行工作流
|
||||
- name: application
|
||||
type: apply-application
|
||||
- name: slack-message
|
||||
type: webhook-notification
|
||||
properties:
|
||||
slack:
|
||||
# Slack Webhook 地址，请查看：https://api.slack.com/messaging/webhooks
|
||||
url: xxx
|
||||
message:
|
||||
text: 工作流运行完成
|
||||
```
|
||||
|
||||
## suspend
|
||||
|
||||
### 简介
|
||||
|
||||
暂停当前工作流，可以通过 `vela workflow resume appname` 继续已暂停的工作流。
|
||||
|
||||
> 有关于 `vela workflow` 命令的介绍，可以详见 [vela cli](../../cli/vela_workflow)。
|
||||
|
||||
### 参数
|
||||
|
||||
| 参数名 | 类型 | 说明 |
|
||||
| :----: | :---: | :---: |
|
||||
| - | - | - |
|
||||
|
||||
### 示例
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: slack-message
|
||||
type: webhook-notification
|
||||
properties:
|
||||
slack:
|
||||
# Slack Webhook 地址，请查看：https://api.slack.com/messaging/webhooks
|
||||
url: xxx
|
||||
message:
|
||||
text: 准备开始部署应用，请管理员审批并继续工作流
|
||||
- name: manual-approval
|
||||
type: suspend
|
||||
- name: express-server
|
||||
type: apply-application
|
||||
```
|
||||
|
|
@ -15,7 +15,11 @@ slug: /
|
|||
|
||||
## 什么是 KubeVela？
|
||||
|
||||
KubeVela 是一个开箱即用的、现代化的应用交付与管理平台。KubeVela 通过以下设计，使得面向混合/多云环境的应用交付变得非常简单高效：
|
||||
KubeVela 是一个开箱即用的、现代化的应用交付与管理平台。
|
||||
|
||||
|
||||
|
||||
KubeVela 通过以下设计，使得面向混合/多云环境的应用交付变得非常简单高效：
|
||||
|
||||
- **完全以应用为中心** - KubeVela 创新性的提出了[开放应用模型（OAM）](https://oam.dev/)来作为应用交付的顶层抽象，并通过声明式的交付工作流来捕获面向混合环境的微服务应用交付的整个过程，甚至连多集群分发策略、流量调配和滚动更新等运维特征，也都声明在应用级别。用户无需关心任何基础设施细节，只需要专注于定义和部署应用即可。
|
||||
- **可编程式交付工作流** - KubeVela 的交付模型是利用 [CUE](https://cuelang.org/) 来实现的。CUE 是一种诞生自 Google Borg 系统的数据配置语言，它可以将应用交付的所有步骤、所需资源、关联的运维动作以可编程的方式粘合成一个 DAG（有向无环图）来作为最终的声明式交付计划。相比于其他系统的复杂性和不可扩展性，KubeVela 基于 CUE 的实现不仅使用简单、扩展性极强，也更符合现代 GitOps 应用交付的趋势与要求。
|
||||
|
|
|
|||
|
|
@ -2,75 +2,43 @@
|
|||
title: 交付第一个应用
|
||||
---
|
||||
|
||||
欢迎来到 KubeVela! 在本小节中，我们会向你介绍如何完成第一个 Demo。
|
||||
欢迎来到 KubeVela! 在本小节中，我们会向你介绍一些例子来帮助你理解如何使用 KubeVela 解决应用交付中的实际问题。
|
||||
|
||||
先来实际感受 KubeVela 到底是如何工作的。
|
||||
在实践之前，请确保您已经按照《快速安装》文档，在您的控制平面集群中安装了 KubeVela。
|
||||
|
||||
## 部署你的第一个应用
|
||||
## 一个最简单的示例
|
||||
|
||||
首先，在你的集群上，我们使用一个提前准备好的 YMAL 文件。
|
||||
KubeVela 中一个简单的应用部署定义，大致如下所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-app
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress-1-20
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
"/": 8000
|
||||
```
|
||||
|
||||
我们可以直接使用 `kubectl` 把它提交给 KubeVela：
|
||||
|
||||
```bash
|
||||
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela-app.yaml
|
||||
```
|
||||
|
||||
检查状态：直到看到 `status` 是 `running`，并且 `services` 是 `healthy`。
|
||||
上述命令一旦执行，KubeVela 就会帮助你在目标集群中交付一个 `Web 服务`类型的组件，且该组件的容器镜像是`crccheck/hello-world`。在本示例中，我们并没有特别指明目标集群是哪个，所以 KubeVela 会默认把应用部署在它所在的集群也就是控制平面集群当中。
|
||||
|
||||
```bash
|
||||
$ kubectl get application first-vela-app -o yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
generation: 1
|
||||
name: first-vela-app
|
||||
...
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
status:
|
||||
...
|
||||
services:
|
||||
- healthy: true
|
||||
name: express-server
|
||||
traits:
|
||||
- healthy: true
|
||||
message: 'Visiting URL: testsvc.example.com, IP: your ip address'
|
||||
type: ingress
|
||||
status: running
|
||||
```
|
||||
可以看到，这个 YAML 的类型是一个 `Application`，由 `core.oam.dev/v1beta1` 来定义，即 KubeVela 的 API Specification。
|
||||
|
||||
在 `Sepc` 字段里，我们也看到比如 `components` 和 `traits` 这样陌生的字段。
|
||||
|
||||
在下一章节中，我们将带你进一步深入它们背后 KubeVela 的核心概念：应用程序、组件系统和运维特征系统。
|
||||
|
||||
同时，在底层的 K8s 资源也被创建了出来:
|
||||
|
||||
```bash
|
||||
$ kubectl get deployment
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server-v1 1/1 1 1 8m
|
||||
$ kubectl get svc
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
express-server ClusterIP 172.21.11.152 <none> 8000/TCP 7m43s
|
||||
kubernetes ClusterIP 172.21.0.1 <none> 443/TCP 116d
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
express-server <none> testsvc.example.com <your ip address> 80 7m47s
|
||||
```
|
||||
|
||||
如果你的集群有一个工作中的 ingress，你可以查看这个 service。
|
||||
而由于我们已经在上述 YAML 文件中为这个组件绑定了一个 `ingress` 类型的运维特征，KubeVela 就会指导 Kubernetes 自动为这个组件背后的工作负载配置 Service、端口映射和 HTTP 路由规则。所以只要目标集群具备 Ingress 能力，上述 YAML 一部署成功，你就可以立刻通过外域名来问这个应用了。
|
||||
|
||||
```
|
||||
$ curl -H "Host:testsvc.example.com" http://<your ip address>/
|
||||
|
|
@ -88,14 +56,195 @@ Hello World
|
|||
`'--.._\..--''
|
||||
</xmp>
|
||||
```
|
||||
**太棒了!** 你已经全都部署成功了。
|
||||
|
||||
也就是说 KubeVlea 的应用交付，围绕应用程序、组件系统和运维特征系统这一整套应用部署计划的核心概念展开，同时通过 Workflow 工作流、CUE 粘合开源生态等进行场景和能力的按需扩展，达成跨云、标准和统一的交付目标。
|
||||
## 交付更多的组件
|
||||
|
||||
KubeVela 允许你部署的组件类型是非常丰富的。在上面的例子中，`Web Service`组件实际上就是一个预先编写好的[CUE](https://cuelang.org/) 文件。
|
||||
|
||||
你还可以选择其它很多类型，比如：
|
||||
|
||||
### Helm 组件
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-delivering-chart
|
||||
spec:
|
||||
components:
|
||||
- name: redis-comp
|
||||
type: helm
|
||||
properties:
|
||||
chart: redis-cluster
|
||||
version: 6.2.7
|
||||
url: https://charts.bitnami.com/bitnami
|
||||
repoType: helm
|
||||
```
|
||||
|
||||
### Terraform 云资源组件
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: rds-cloud-source
|
||||
spec:
|
||||
components:
|
||||
- name: sample-db
|
||||
type: alibaba-rds
|
||||
properties:
|
||||
instance_name: sample-db
|
||||
account_name: oamtest
|
||||
password: U34rfwefwefffaked
|
||||
writeConnectionSecretToRef:
|
||||
name: db-conn
|
||||
```
|
||||
|
||||
### 来自 Git 仓库的组件（基于 Kustomize）
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: git-app
|
||||
spec:
|
||||
components:
|
||||
- name: git-comp
|
||||
type: kustomize
|
||||
properties:
|
||||
repoType: git
|
||||
url: https://github.com/<path>/<to>/<repo>
|
||||
git:
|
||||
branch: master
|
||||
path: ./app/dev/
|
||||
```
|
||||
|
||||
当然，还有更多。欢迎查看边栏中的《选择待交付组件》章节来阅读关于部署各种类型的详细文档。如果你需要的话，你还可以在 KubeVela 中添加自己的组件类型。
|
||||
|
||||
## 绑定运维特征
|
||||
|
||||
KubeVela 能做的远不止部署，还包括运维。它允许你为待交付组件绑定预先定义好的各种运维行为（叫做运维特征），并且这个绑定会立刻生效。接下来，我们就为 Web 服务组件绑定一个“分批发布”运维特征：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: rollout-trait-test
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
externalRevision: express-server-v1
|
||||
properties:
|
||||
image: stefanprodan/podinfo:4.0.3
|
||||
traits:
|
||||
- type: rollout
|
||||
properties:
|
||||
targetSize: 5
|
||||
rolloutBatches:
|
||||
- replicas: 2
|
||||
- replicas: 3
|
||||
```
|
||||
|
||||
好了，接下来，只要上述 YAML 中的镜像版本发生变化，KubeVela 就会按照你所定义的分批策略来更新对应的应用实例了。
|
||||
|
||||
如果你想了解 KubeVela 所支持的所有运维特征，欢迎查看边栏中的《绑定运维特征》章节，同样的，KubeVela 允许你非常容易的在平台中添加自己的运维特征。
|
||||
|
||||
## 定义交付策略与交付工作流
|
||||
|
||||
组件与运维特征只是 KubeVela 非常基本的功能。KubeVela 本身实际上是一个全功能的持续交付（CD）系统，并且原生支持面向混合环境（比如混合云/多云/多集群）应用交付。
|
||||
|
||||
举个例子：
|
||||
|
||||
> 我要交付一个包括了两个组件的微服务应用，要求先需要在预发集群当中部署 1 个副本，然后暂停交付过程，请主管进行人工审核。当审核通过后，再继续部署到生产集群中，并且需要部署为3个副本。
|
||||
|
||||
想象一下，你需要在 CI/CD 流水线里编写多少“脏乱差”的一次性脚本或者胶水代码才能让上述流程自动化的、保证一定正确性的执行起来？
|
||||
|
||||
而在 KubeVela 中，上述流程可以非常容易的通过如下所示的声明式工作流建模出来：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: example-app
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: hello-world-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 1
|
||||
- name: data-worker
|
||||
type: worker
|
||||
properties:
|
||||
image: busybox
|
||||
cmd:
|
||||
- sleep
|
||||
- '1000000'
|
||||
policies:
|
||||
- name: example-multi-env-policy
|
||||
type: env-binding
|
||||
properties:
|
||||
envs:
|
||||
- name: staging
|
||||
placement: # selecting the cluster to deploy to
|
||||
clusterSelector:
|
||||
name: cluster-staging
|
||||
selector: # selecting which component to use
|
||||
components:
|
||||
- hello-world-server
|
||||
|
||||
- name: prod
|
||||
placement:
|
||||
clusterSelector:
|
||||
name: cluster-prod
|
||||
patch: # overlay patch on above components
|
||||
components:
|
||||
- name: hello-world-server
|
||||
type: webservice
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 3
|
||||
|
||||
- name: health-policy-demo
|
||||
type: health
|
||||
properties:
|
||||
probeInterval: 5
|
||||
probeTimeout: 10
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
# deploy to staging env
|
||||
- name: deploy-staging
|
||||
type: deploy2env
|
||||
properties:
|
||||
policy: example-multi-env-policy
|
||||
env: staging
|
||||
|
||||
# manual check
|
||||
- name: manual-approval
|
||||
type: suspend
|
||||
|
||||
# deploy to prod env
|
||||
- name: deploy-prod
|
||||
type: deploy2env
|
||||
properties:
|
||||
policy: example-multi-env-policy
|
||||
env: prod
|
||||
```
|
||||
|
||||
不需要任何“脏乱差”脚本，KubeVela 就能够以完全自动化、高确定性的声明式工作流完成所有的应用交付动作。更为重要的是，KubeVela 希望你继续使用你现有的任何 CI 方案，而 KubeVela 则负责帮助你更好的完成 CD 流程。
|
||||
|
||||
## 下一步
|
||||
|
||||
后续步骤:
|
||||
上述所有功能，只是 KubeVela 这个现代化的云原生应用交付与管理平台的冰山一角。您可以从下面步骤来开始更好的了解 KubeVela:
|
||||
|
||||
- 查看 KubeVela 的[`应用部署计划及其概念`](./core-concepts/application)，进一步理解其是如何工作的。
|
||||
- 查看 KubeVela 的[`系统架构`](./core-concepts/architecture)，了解 KubeVela 的系统构成和运转模式。
|
||||
- 查看 KubeVela 的[`应用交付模型`](./core-concepts/application)，进一步理解其是如何工作的。
|
||||
- 学习 KubeVela 的[`系统架构`](./core-concepts/architecture)，深入了解 KubeVela 本身的设计与架构原理。
|
||||
- 加入 KubeVela 中文社区钉钉群，群号：23310022。
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 497 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 454 KiB After Width: | Height: | Size: 198 KiB |
|
|
@ -6,7 +6,7 @@ KubeVela 背后的应用交付模型是 [Open Application Model](../platform-eng
|
|||
|
||||
## 应用部署计划（Application）
|
||||
|
||||
KubeVela 通过 YAML 文件的方式描述应用部署计划。一个典型的 YAML 样例如下：
|
||||
KubeVela 通过声明式 YAML 文件的方式来描述应用部署计划。一个典型的样例如下：
|
||||
|
||||
```yaml
|
||||
# sample.yaml
|
||||
|
|
|
|||
|
|
@ -8,26 +8,28 @@ KubeVela 的整体架构如下所示：
|
|||
|
||||
## KubeVela 是一个控制平面系统
|
||||
|
||||
KubeVela 本身是一个的应用交付与管理控制平面，它架在 Kubernetes 集群、云平台等基础设施之上，通过开放应用模型来对组件、云服务、运维能力、交付工作流进行统一的编排和交付，因而与基础设施本身完全解耦并且很容易面向任何混合/多云/多集群基础设施进行应用交付与管理。
|
||||
KubeVela 本身是一个的应用交付与管理控制平面，它架在 Kubernetes 集群、云平台等基础设施之上，通过开放应用模型来对组件、云服务、运维能力、交付工作流进行统一的编排和交付。KubeVela 这种与基础设施本身完全解耦的设计，很容易就能帮助你面向混合云/多云/多集群基础设施进行应用交付与管理。
|
||||
|
||||
而为了能够同任何 CI 流水线或者 GitOps 工具无缝对接，KubeVela 的 API（即开放应用模型）被设计为是声明式、完全以应用为中心的，它包括：
|
||||
而为了能够同任何 CI 流水线或者 GitOps 工具无缝集成，KubeVela 的 API（即开放应用模型）被设计为是声明式、完全以应用为中心的，它包括：
|
||||
- 帮助用户定义应用交付计划的 `Application` 对象
|
||||
- 帮助平台管理员通过 CUE 语言定义平台能力和抽象的 `X-Definition `对象
|
||||
- 比如 `ComponentDefinition`、`TraitDefinition` 等
|
||||
|
||||
在实现上，KubeVela 需要依赖一个独立的 Kubernetes 集群来运行。这是一个有意为之的设计：因为帮助你快速实现一个科学的、健壮的控制平面系统，正是 Kubernetes 项目最擅长的一件事情。这个实践已经久经社区考验，能够让我们以最低的代价为大规模应用交付工作流带来宝贵的确定性、收敛性和自动化能力。具体来说，KubeVela 本身主要由如下几个部分注册:
|
||||
在具体实现上，KubeVela 依赖一个独立的 Kubernetes 集群来运行。这其实是一个“有意为之”的设计：云原生社区中大量的实践已经证明“构建一个科学的、健壮的控制平面系统”，正是 Kubernetes 项目最擅长的工作。所以，依赖 Kubernetes 作为控制平面集群这个选择，虽然会增加一定的部署难度，却能够让我们以最原生的方式为大规模应用交付带来至关重要的“确定性”、“收敛性”和“自动化能力”。
|
||||
|
||||
具体来说，KubeVela 本身主要由如下几个部分组成:
|
||||
|
||||
- **核心控制器** 为整个系统提供核心控制逻辑，完成诸如编排应用和工作流、修订版本快照、垃圾回收等等基础逻辑
|
||||
- **模块能力控制器** 负责对 X-Definitions 对象进行注册和管理。
|
||||
- **插件控制器** 负责注册和管理 KubeVela 运行所需要的第三方插件，比如 Flux，Terraform 组件等等。
|
||||
- **模块化能力控制器** 负责对 X-Definitions 对象进行注册和管理。
|
||||
- **插件控制器** 负责注册和管理 KubeVela 运行所需要的第三方插件，比如 Flux、Terraform 组件等等。
|
||||
|
||||
### 运行时基础设施
|
||||
|
||||
运行时基础设施是应用实际运行的地方。KubeVela 本身是完全与这些基础设施无关的，因此它允许你面向任何环境，包括 Kubernetes 环境，也包括非 Kubernetes 环境比如云平台和边缘设备等，交付任何类型的应用。
|
||||
运行时基础设施是应用实际运行的地方。KubeVela 本身是完全与这些基础设施无关的，因此它允许你面向任何环境（包括 Kubernetes 环境，也包括非 Kubernetes 环境比如云平台和边缘设备等）去交付和管理任何类型的应用。
|
||||
|
||||
## KubeVela 是可编程的
|
||||
|
||||
在现实世界中，应用交付往往比较复杂，哪怕是一个非常通用的交付过程，也会因为用户、团队、环境、场景的变化而千差万别。所以 KubeVela 从第一天起就采用了一种“可编程”式的方法来实现它的交付模型，这使得 KubeVela 可以非常容易和灵活的适配到你的应用交付场景中。
|
||||
现实世界中的应用交付，往往是一个比较复杂的过程。哪怕是一个比较通用的交付流程，也会因为场景、环境、用户甚至团队的不同而千差万别。所以 KubeVela 从第一天起就采用了一种“可编程”式的方法来实现它的交付模型，这使得 KubeVela 可以以前所未有的灵活度适配到你的应用交付场景中。
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ title: 交付第一个应用
|
|||
|
||||
## 一个最简单的示例
|
||||
|
||||
KubeVela 中一个比较简单的应用部署定义，大致如下所示：
|
||||
KubeVela 中一个简单的应用部署定义，大致如下所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -61,7 +61,7 @@ Hello World
|
|||
|
||||
KubeVela 允许你部署的组件类型是非常丰富的。在上面的例子中，`Web Service`组件实际上就是一个预先编写好的[CUE](https://cuelang.org/) 文件。
|
||||
|
||||
你还可以其它很多类型，比如：
|
||||
你还可以选择其它很多类型，比如：
|
||||
|
||||
### Helm 组件
|
||||
|
||||
|
|
@ -239,12 +239,12 @@ spec:
|
|||
env: prod
|
||||
```
|
||||
|
||||
不需要任何“脏乱差”脚本，KubeVela 就能够以完全自动化、高确定性的声明式工作流完成所有的应用交付动作。更为重要的是，KubeVela 希望你继续使用你现有的 CI 方案，而 KubeVela 则负责帮助你更好的完成 CD 流程。
|
||||
不需要任何“脏乱差”脚本，KubeVela 就能够以完全自动化、高确定性的声明式工作流完成所有的应用交付动作。更为重要的是，KubeVela 希望你继续使用你现有的任何 CI 方案，而 KubeVela 则负责帮助你更好的完成 CD 流程。
|
||||
|
||||
## 下一步
|
||||
|
||||
上述所有功能，只是 KubeVela 这个现代化的云原生应用交付与管理平台的冰山一角。您可以从下面步骤来开始更好的了解 KubeVela:
|
||||
|
||||
- 查看 KubeVela 的[`应用部署模型`](./core-concepts/application)，进一步理解其是如何工作的。
|
||||
- 查看 KubeVela 的[`系统架构`](./core-concepts/architecture)，了解 KubeVela 本身的设计与架构原理。
|
||||
- 查看 KubeVela 的[`应用交付模型`](./core-concepts/application)，进一步理解其是如何工作的。
|
||||
- 学习 KubeVela 的[`系统架构`](./core-concepts/architecture)，深入了解 KubeVela 本身的设计与架构原理。
|
||||
- 加入 KubeVela 中文社区钉钉群，群号：23310022。
|
||||
Loading…
Reference in New Issue