Feat: add separation of concern
Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>
This commit is contained in:
Jianbo Sun
parent
2e750f6a9f
commit
cfb1731ec3
|
|
@ -5,7 +5,7 @@ slug: /
|
|||
|
||||
## What is KubeVela?
|
||||
|
||||
KubeVela is a modern software delivery control plane. The goal is to make deploying and operating applications across today's hybrid, multi-cloud environments easier, faster and more reliable. Welcome onboard and sail Vela!
|
||||
KubeVela is a modern software delivery and management control plane. The goal is to make deploying and operating applications across today's hybrid, multi-cloud environments easier, faster and more reliable. Welcome onboard and sail Vela!
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,33 @@
|
|||
---
|
||||
title: Separation of Concerns
|
||||
---
|
||||
|
||||
KubeVela designs for separation of concerns, as a result, there're two roles of users:
|
||||
|
||||
- **Platform Team**
|
||||
- The platform engineers initialize the deployment environments, provide stable infrastructure capabilities (e.g. mysql-operator) and register them as reusable templates using [KubeVela Definitions](./definition) into the control plane. They should be experienced and skillful with the infrastructure.
|
||||
- **End Users**
|
||||
- The end users are usually app developers. They choose target environment, and choose capability templates, fill in values and finally assemble them as a [KubeVela Application](./core-concept). They don't need to understand the infrastructure details.
|
||||
|
||||
The KubeVela community has also maintained a bundle of infrastructure capabilities, they are called [addons](../reference/addons/overview).
|
||||
|
||||
The work flow is shown as below:
|
||||
|
||||
|
||||
|
||||
## What's benefit?
|
||||
|
||||
The separation of concern benefit the end users most. They can enjoy the "Application-Centric" experience without learning any infrastructure details. To make it more concrete, they can be free from the following scenarios:
|
||||
|
||||
- No need to learn Kubernetes API deprecations from versions upgrade.
|
||||
- No need to care about the difference between several ingress implementations.
|
||||
- No need to understand the CPU limit or even deeper infrastructure knowledge such as pod disruption budget.
|
||||
- Declare high availability or other operation requirements as application traits.
|
||||
- Use the capability with more confidence as they're enforced with best practices provided by platform teams.
|
||||
|
||||
|
||||
As to platform teams, the benefits are also obvious:
|
||||
|
||||
- They can provide reusable capabilities, enforce best practices and make application delivery safer.
|
||||
- They can provide flexible template parameters to serve different application teams with the same platform per their needs.
|
||||
- They can share and integrate capabilities with the whole open source community easily in a standard way.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 1.3 MiB |
|
|
@ -310,8 +310,8 @@
|
|||
"sidebar.docs.category.Kubernetes Manifest CD": {
|
||||
"message": "Kubernetes 资源交付"
|
||||
},
|
||||
"sidebar.docs.category.CD Policies": {
|
||||
"message": "资源交付策略"
|
||||
"sidebar.docs.category.Application Policies": {
|
||||
"message": "应用管理策略"
|
||||
},
|
||||
"sidebar.docs.category.UX Customization": {
|
||||
"message": "定制 UI"
|
||||
|
|
|
|||
|
|
@ -1,105 +0,0 @@
|
|||
---
|
||||
title: 核心概念
|
||||
---
|
||||
|
||||
*"KubeVela 是一个面向混合环境的、简单易用、同时高可扩展的应用交付与管理引擎。"*
|
||||
|
||||
在本部分中，我们会对 KubeVela 的核心思想进行详细解释，并进一步阐清一些在本项目中被广泛使用的技术术语。
|
||||
|
||||
## 综述
|
||||
|
||||
首先，KubeVela 引入了下面所述的带有关注点分离思想的工作流：
|
||||
- **平台团队**
|
||||
- 通过给部署环境和可重复使用的能力模块编写模板来构建应用，并将他们注册到集群中。
|
||||
- **业务用户**
|
||||
- 选择部署环境、模型和可用模块来组装应用，并把应用部署到目标环境中。
|
||||
|
||||
工作流如下图所示:
|
||||
|
||||
|
||||
|
||||
这种基于模板的工作流使得平台团队能够在一系列的 Kubernetes CRD 之上，引导用户遵守他们构建的最佳实践和 部署经验，并且可以很自然地为业务用户提供 PaaS 级别的体验（比如：“以应用为中心”，“高层次的抽象”，“自助式运维操作”等等）。
|
||||
|
||||
|
||||
|
||||
下面开始介绍 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的主要概念由下图所示：
|
||||
|
||||
|
||||
|
||||
## 架构
|
||||
|
||||
KubeVela的整体架构由下图所示：
|
||||
|
||||
|
||||
|
||||
特别的，application controller 负责应用的抽象和封装（比如负责 `Application` 和 `Definition` 的 controller ）。Rollout contoller 负责以整个应用为单位处理渐进式 rollout 策略。多集群部署引擎，在流量切分和 rollout 特性的支持下，负责跨多集群和环境部署应用。
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
---
|
||||
title: 关注点分离
|
||||
---
|
||||
|
||||
KubeVela 是面向关注点分离设计的系统，所以 KubeVela 的用户天然分为两种角色，由公司的两个团队（或个人）承担。
|
||||
|
||||
- **平台团队**
|
||||
- 由平台工程师完成，他们需要准备应用部署环境，维护稳定可靠的基础设施功能（如 mysql operator），并将基础设施能力作为 [KubeVela 模块定义](./definition) 注册到集群中。他们需要具备丰富的基础设施经验。
|
||||
- **最终用户**
|
||||
- 最终用户即业务应用的开发者，使用平台的过程中首先选择部署环境，然后挑选能力模块，填写业务参数并组装成 [KubeVela 应用](./core-concept)。他们无需关心基础设施细节。
|
||||
|
||||
整个工作流程如下图所示:
|
||||
|
||||
|
||||
|
||||
## 关注点分离的价值和优势
|
||||
|
||||
关注点对最终用户的价值是最大的，他们可以获得以应用为中心的平台使用体验，不再需要了解基础设施细节。具体而言，他们在如下场景直接受益：
|
||||
|
||||
- 不再需要关系 Kubernetes 版本变化带来的 API 变化。
|
||||
- 不再需要关心像 Ingress 这样的对象不同底层实现之间的区别。
|
||||
- 不再需要了解诸如 CPU Limit 或者 Pod 驱逐策略这类完全是平台底层特性的概念。
|
||||
- 可以用声明式的方式描述注入高可用、灰度发布这样的运维需求。
|
||||
- 应用交付更安全、可靠，因为使用的是平台工程师基于最佳实践封装的能力，不会因为权限过大或者直接操作基础设施 API 带来稳定性风险。
|
||||
|
||||
对于平台团队而言，好处也非常明显：
|
||||
|
||||
- 他们可以专注于面向场景的维护能力，更聚焦的保证应用交付的易用性和安全性，为业务工程师提供最佳实践。
|
||||
- 他们不会丧失基础设施的灵活性，可以根据不同业务团队的需要按需提供不同的能力模块，服务的效率更高，服务的团队规模也可以变大。
|
||||
- 他们可以与开源社区共建基础设施功能，复用云原生生态项目，为开源做贡献，并且这一切都是通过标准化的方式完成，减少了与社区分叉的风险。
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 1.3 MiB |
|
|
@ -310,8 +310,8 @@
|
|||
"sidebar.docs.category.Kubernetes Manifest CD": {
|
||||
"message": "Kubernetes 资源交付"
|
||||
},
|
||||
"sidebar.docs.category.CD Policies": {
|
||||
"message": "资源交付策略"
|
||||
"sidebar.docs.category.Application Policies": {
|
||||
"message": "应用管理策略"
|
||||
},
|
||||
"sidebar.docs.category.UX Customization": {
|
||||
"message": "定制 UI"
|
||||
|
|
|
|||
|
|
@ -1,105 +0,0 @@
|
|||
---
|
||||
title: 核心概念
|
||||
---
|
||||
|
||||
*"KubeVela 是一个面向混合环境的、简单易用、同时高可扩展的应用交付与管理引擎。"*
|
||||
|
||||
在本部分中，我们会对 KubeVela 的核心思想进行详细解释，并进一步阐清一些在本项目中被广泛使用的技术术语。
|
||||
|
||||
## 综述
|
||||
|
||||
首先，KubeVela 引入了下面所述的带有关注点分离思想的工作流：
|
||||
- **平台团队**
|
||||
- 通过给部署环境和可重复使用的能力模块编写模板来构建应用，并将他们注册到集群中。
|
||||
- **业务用户**
|
||||
- 选择部署环境、模型和可用模块来组装应用，并把应用部署到目标环境中。
|
||||
|
||||
工作流如下图所示:
|
||||
|
||||
|
||||
|
||||
这种基于模板的工作流使得平台团队能够在一系列的 Kubernetes CRD 之上，引导用户遵守他们构建的最佳实践和 部署经验，并且可以很自然地为业务用户提供 PaaS 级别的体验（比如：“以应用为中心”，“高层次的抽象”，“自助式运维操作”等等）。
|
||||
|
||||
|
||||
|
||||
下面开始介绍 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的主要概念由下图所示：
|
||||
|
||||
|
||||
|
||||
## 架构
|
||||
|
||||
KubeVela的整体架构由下图所示：
|
||||
|
||||
|
||||
|
||||
特别的，application controller 负责应用的抽象和封装（比如负责 `Application` 和 `Definition` 的 controller ）。Rollout contoller 负责以整个应用为单位处理渐进式 rollout 策略。多集群部署引擎，在流量切分和 rollout 特性的支持下，负责跨多集群和环境部署应用。
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
---
|
||||
title: 关注点分离
|
||||
---
|
||||
|
||||
KubeVela 是面向关注点分离设计的系统，所以 KubeVela 的用户天然分为两种角色，由公司的两个团队（或个人）承担。
|
||||
|
||||
- **平台团队**
|
||||
- 由平台工程师完成，他们需要准备应用部署环境，维护稳定可靠的基础设施功能（如 mysql operator），并将基础设施能力作为 [KubeVela 模块定义](./definition) 注册到集群中。他们需要具备丰富的基础设施经验。
|
||||
- **最终用户**
|
||||
- 最终用户即业务应用的开发者，使用平台的过程中首先选择部署环境，然后挑选能力模块，填写业务参数并组装成 [KubeVela 应用](./core-concept)。他们无需关心基础设施细节。
|
||||
|
||||
整个工作流程如下图所示:
|
||||
|
||||
|
||||
|
||||
## 关注点分离的价值和优势
|
||||
|
||||
关注点对最终用户的价值是最大的，他们可以获得以应用为中心的平台使用体验，不再需要了解基础设施细节。具体而言，他们在如下场景直接受益：
|
||||
|
||||
- 不再需要关系 Kubernetes 版本变化带来的 API 变化。
|
||||
- 不再需要关心像 Ingress 这样的对象不同底层实现之间的区别。
|
||||
- 不再需要了解诸如 CPU Limit 或者 Pod 驱逐策略这类完全是平台底层特性的概念。
|
||||
- 可以用声明式的方式描述注入高可用、灰度发布这样的运维需求。
|
||||
- 应用交付更安全、可靠，因为使用的是平台工程师基于最佳实践封装的能力，不会因为权限过大或者直接操作基础设施 API 带来稳定性风险。
|
||||
|
||||
对于平台团队而言，好处也非常明显：
|
||||
|
||||
- 他们可以专注于面向场景的维护能力，更聚焦的保证应用交付的易用性和安全性，为业务工程师提供最佳实践。
|
||||
- 他们不会丧失基础设施的灵活性，可以根据不同业务团队的需要按需提供不同的能力模块，服务的效率更高，服务的团队规模也可以变大。
|
||||
- 他们可以与开源社区共建基础设施功能，复用云原生生态项目，为开源做贡献，并且这一切都是通过标准化的方式完成，减少了与社区分叉的风险。
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 1.3 MiB |
|
|
@ -43,6 +43,7 @@ module.exports = {
|
|||
label: 'Core Concepts',
|
||||
collapsed: false,
|
||||
items: [
|
||||
'getting-started/separate-of-concern',
|
||||
'getting-started/core-concept',
|
||||
'getting-started/definition',
|
||||
'getting-started/architecture',
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ slug: /
|
|||
|
||||
## What is KubeVela?
|
||||
|
||||
KubeVela is a modern software delivery control plane. The goal is to make deploying and operating applications across today's hybrid, multi-cloud environments easier, faster and more reliable. Welcome onboard and sail Vela!
|
||||
KubeVela is a modern software delivery and management control plane. The goal is to make deploying and operating applications across today's hybrid, multi-cloud environments easier, faster and more reliable. Welcome onboard and sail Vela!
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,33 @@
|
|||
---
|
||||
title: Separation of Concerns
|
||||
---
|
||||
|
||||
KubeVela designs for separation of concerns, as a result, there're two roles of users:
|
||||
|
||||
- **Platform Team**
|
||||
- The platform engineers initialize the deployment environments, provide stable infrastructure capabilities (e.g. mysql-operator) and register them as reusable templates using [KubeVela Definitions](./definition) into the control plane. They should be experienced and skillful with the infrastructure.
|
||||
- **End Users**
|
||||
- The end users are usually app developers. They choose target environment, and choose capability templates, fill in values and finally assemble them as a [KubeVela Application](./core-concept). They don't need to understand the infrastructure details.
|
||||
|
||||
The KubeVela community has also maintained a bundle of infrastructure capabilities, they are called [addons](../reference/addons/overview).
|
||||
|
||||
The work flow is shown as below:
|
||||
|
||||
|
||||
|
||||
## What's benefit?
|
||||
|
||||
The separation of concern benefit the end users most. They can enjoy the "Application-Centric" experience without learning any infrastructure details. To make it more concrete, they can be free from the following scenarios:
|
||||
|
||||
- No need to learn Kubernetes API deprecations from versions upgrade.
|
||||
- No need to care about the difference between several ingress implementations.
|
||||
- No need to understand the CPU limit or even deeper infrastructure knowledge such as pod disruption budget.
|
||||
- Declare high availability or other operation requirements as application traits.
|
||||
- Use the capability with more confidence as they're enforced with best practices provided by platform teams.
|
||||
|
||||
|
||||
As to platform teams, the benefits are also obvious:
|
||||
|
||||
- They can provide reusable capabilities, enforce best practices and make application delivery safer.
|
||||
- They can provide flexible template parameters to serve different application teams with the same platform per their needs.
|
||||
- They can share and integrate capabilities with the whole open source community easily in a standard way.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 1.3 MiB |
|
|
@ -41,6 +41,7 @@
|
|||
"label": "Core Concepts",
|
||||
"collapsed": false,
|
||||
"items": [
|
||||
"getting-started/separate-of-concern",
|
||||
"getting-started/core-concept",
|
||||
"getting-started/definition",
|
||||
"getting-started/architecture"
|
||||
|
|
|
|||
Loading…
Reference in New Issue