update intro and arch EN (#243)
This commit is contained in:
Hongchao Deng
GitHub
parent
7ec98063dc
commit
b2df3453cb
|
|
@ -4,12 +4,54 @@ title: Architecture
|
|||
|
||||
The overall architecture of KubeVela is shown as below:
|
||||
|
||||
|
||||
|
||||
|
||||
### Control Plane
|
||||
|
||||
Control plane is where KubeVela itself lives in. As the project's name implies, KubeVela by design leverages Kubernetes as control plane. This is the key of how KubeVela guarantees full *automation* and strong *determinism* to application delivery at scale. Users will interact with KubeVela via the application centric API to model the application deployment, and KubeVela will deliver the application to target *runtime infrastructure* per policies and workflow declared by users and ensure the success.
|
||||
## API
|
||||
|
||||
### Runtime Infrastructures
|
||||
The API layer provides KubeVela APIs exposed to users for building application delivery platform and solutions.
|
||||
KubeVela APIs are declarative and application centric.
|
||||
It is based on Kubernetes CRDs to natively fit into the Kubernetes ecosystem.
|
||||
|
||||
Runtime infrastructures are where the applications are actually running on. KubeVela allows you to deploy and manage applications on both Kubernetes based infrastructures (local, managed offerings, or IoT/Edge/On-Premise ones) and non-Kubernetes environments such as public/private clouds in a consistent workflow. KubeVela itself does not run on the runtime infrastructures, they two are fully decoupled.
|
||||
The APIs can be categorized for two purposes:
|
||||
|
||||
- For **platform users** to compose final application manifest to deploy.
|
||||
- Usually this contains only user-concerned config and hides infrastructure details.
|
||||
- Users will normally write the manifest in yaml format.
|
||||
- This currently includes Application only. But we may add more user-facing APIs, e.g. ApplicationSet to define multiple Applications.
|
||||
- For **platform admins** to define capability definitions to handle actual operations.
|
||||
- Each definition glues operational tasks using CUE and exposes user-concerned config only.
|
||||
- Admins will normally write the manifest in yaml + CUE format.
|
||||
- This currently includes Component, Trait, Policy, and Workflow definition types.
|
||||
|
||||
The APIs are served by the control plane.
|
||||
Because it is so important that we put a separate section to talk about it.
|
||||
|
||||
## Control Plane
|
||||
|
||||
The control plane layers is where KubeVela puts the components central to the entire system.
|
||||
It is the first entry to handle user API requests, the central place to register plugins,
|
||||
and central processor to manage global states and dispatches tasks/resources.
|
||||
|
||||
The control plane contains three major parts:
|
||||
|
||||
- **Plugin registry** stores and manages X-Definitions.
|
||||
X-Definitions are CRDs that users can apply and get via kubectl.
|
||||
There are additional backend functions to store and manage multiple versions of X-Definitions.
|
||||
- **Core Control** provides the core control logic to the entire system.
|
||||
It consists of the core components that are hanlding Application, X-Definition API requests,
|
||||
orchestrating Workflows, storing revisions of Applications and Components,
|
||||
parsing and executing CUE fields, garbage collecting unused resources.
|
||||
- **Builtin Controllers** registers builtin plugins and provides the backing controllers for the resources
|
||||
created by X-Definitions. These are core to the KubeVela ecosystem that we believe everyone will use.
|
||||
|
||||
The control plane (including API layer) is KubeVela per se.
|
||||
Technically speaking, KubeVela is a control plane to manage applications over multiple clusters, hybrid environments.
|
||||
|
||||
## Execution
|
||||
|
||||
The execution layer is where the applications are actually running on.
|
||||
KubeVela allows you to deploy and manage application resources in a consistent workflow onto both
|
||||
Kubernetes cluster (e.g. local, managed offerings, IoT/edge, on-prem)
|
||||
and non-Kubernetes environments on clouds.
|
||||
KubeVela itself does not run on the execution infrastructures, but manage them instead.
|
||||
|
|
|
|||
|
|
@ -6,36 +6,23 @@ slug: /
|
|||
|
||||
## Motivation
|
||||
|
||||
The trend of cloud-native technology is moving towards pursuing consistent application delivery across clouds and on-premises infrastructures using Kubernetes as the common layer. Kubernetes, although excellent in abstracting low-level infrastructure details, does not introduce abstractions to model software deployment on top of today's hybrid and distributed environments. We’ve seen the lack of application level context have impacted user experiences, slowed down productivity, led to unexpected errors or misconfigurations in production.
|
||||
The trend of cloud-native technology is moving towards pursuing consistent experience of application delivery across clouds and on-prem clusters. Kubernetes is becoming the standard layer which is excellent in abstracting away low-level infrastructure details. But it does not provide abstractions to model application deployment on top of hybrid and distributed environments. The lack of application level context have impacted user experience, slowed down productivity, led to unexpected errors due to misconfigurations in production.
|
||||
|
||||
Meanwhile, modeling the deployment of a microservice application is a highly fragmented and challenging process. Thus, many solutions tried to solve above problem so far are either too simplified to fix the real issue, or too complicated to use at all. On the other hand, though many solutions provided friendly UI layer, the platform themselves can barely extend. This means as the needs of your application grow, they are almost certain to outgrow the capabilities of such systems.
|
||||
Meanwhile, modeling the deployment of a microservice application is a highly fragmented and challenging process. Thus, many solutions that tried to solve the problem so far are either over simplified and could not fix the real issue, or too complicated to use at all. On the other hand, though many solutions provided friendly UI layer, the platform themselves are not customizable. This means as the needs of your platform grow, it is inevitable for the feature requirements to outgrow the capabilities of such systems.
|
||||
|
||||
Today the application teams are eager to find a platform that can simplify the application delivery experience across hybrid environments (e.g. multi-cluster/multi-cloud/hybrid-cloud/distributed-cloud), while also be flexible enough to satisfy the fast growth of businesses requirements. The platform-engineers have similar empathy but the effort of building such system is out of their scope.
|
||||
|
||||
Today, the application teams are eager to find a platform that can simplify the application delivery across hybrid environments (e.g. multi-cluster/multi-cloud/hybrid-cloud/distributed-cloud), while it should also be flexible enough to meet the requirement of fast growing businesses. The platform-engineers do want to help but the engineering effort of building such system seems to be daunting.
|
||||
|
||||
## What is KubeVela?
|
||||
|
||||
KubeVela is a modern application platform that makes deploying and managing applications across today's hybrid, multi-cloud environments easier and faster, while at meantime, naturally adapts to your needs as they grow. This is achieved by doing the following:
|
||||
KubeVela is a modern application platform that makes it easier and faster to deliver and manage applications across hybrid, multi-cloud environments. At the mean time, it is highly extensible and programmable, which can adapt to your needs as they grow. This is achieved by doing the following:
|
||||
|
||||
**Application Centric** - KubeVela introduces [Open Application Model (OAM)](https://oam.dev/) as the consistent yet higher level API to capture a full deployment of microservices on top of hybrid environments. Placement strategy, traffic shifting and rolling update are declared at application level. No infrastructure level concern, simply deploy.
|
||||
**Application Centric** - KubeVela introduces [Open Application Model (OAM)](https://oam.dev/) as the consistent and application-focused API to capture a full deployment of microservices on top of hybrid environments. Placement strategy, traffic shifting and rolling update are declared at the perspective of application developers. No infrastructure level concern, only application level concepts.
|
||||
|
||||
**Programmable Workflow** - KubeVela leverages [CUE](https://cuelang.org/) to implement its model layer. This allows you to declare application deployment workflow as a DAG, with all steps and application's needs glued together in programmable approach. No restrictions, natively extensible.
|
||||
**Programmable Workflow** - KubeVela leverages [CUE](https://cuelang.org/) as the implementation engine behind the model layer. This allows you to compose deployment workflow in a modular and declarative API, and automates any operational tasks in a programmable manner. No restrictions, natively extensible.
|
||||
|
||||
**Runtime Agnostic** - KubeVela works as an application delivery control plane that is fully runtime agnostic. It can deploy and manage any application components including containers, cloud functions, databases, or even EC2 instances across hybrid environments, following the workflow you defined.
|
||||
|
||||
## Architecture
|
||||
|
||||
The overall architecture of KubeVela is shown as below:
|
||||
|
||||
|
||||
|
||||
### Control Plane
|
||||
|
||||
Control plane is where KubeVela itself lives in. As the project's name implies, KubeVela by design leverages Kubernetes as control plane. This is the key of how KubeVela guarantees full *automation* and strong *determinism* to application delivery at scale. Users will interact with KubeVela via the application centric API to model the application deployment, and KubeVela will deliver the application to target *runtime infrastructure* per policies and workflow declared by users and ensure the success.
|
||||
|
||||
### Runtime Infrastructures
|
||||
|
||||
Runtime infrastructures are where the applications are actually running on. KubeVela allows you to deploy and manage applications on both Kubernetes based infrastructures (local, managed offerings, or IoT/Edge/On-Premise ones) and non-Kubernetes environments such as public/private clouds in a consistent workflow. KubeVela itself does not run on the runtime infrastructures, they two are fully decoupled.
|
||||
|
||||
## Comparisons
|
||||
|
||||
### KubeVela vs. Platform-as-a-Service (PaaS)
|
||||
|
|
@ -71,3 +58,11 @@ Of course, KubeVela also supports other encapsulation formats including Kustomiz
|
|||
KubeVela is a modern application deployment system built with cloud native stack. It leverages [Open Application Model](https://github.com/oam-dev/spec) and Kubernetes as control plane to resolve a hard problem - making shipping applications enjoyable.
|
||||
|
||||
Welcome onboard and sail Vela!
|
||||
|
||||
|
||||
## What's Next
|
||||
|
||||
Here are some recommended next steps:
|
||||
|
||||
- Learn KubeVela's [Core Concepts](core-concepts/application).
|
||||
- Learn KubeVela's [Architecture](core-concepts/architecture).
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 536 KiB |
|
|
@ -17,7 +17,7 @@ slug: /
|
|||
|
||||
KubeVela 是一个开箱即用的、现代化的应用交付与管理平台。KubeVela 通过以下设计，使得面向混合/多云环境的应用交付变得非常简单高效：
|
||||
|
||||
- **完全以应用为中心** - KubeVela 创新性的提出了开放应用模型（OAM）来作为应用交付的顶层抽象，并通过声明式的交付工作流来捕获面向混合环境的微服务应用交付的整个过程，甚至连多集群分发策略、流量调配和滚动更新等运维特征，也都声明在应用级别。用户无需关心任何基础设施细节，只需要专注于定义和部署应用即可。
|
||||
- **完全以应用为中心** - KubeVela 创新性的提出了[开放应用模型（OAM）](https://oam.dev/)来作为应用交付的顶层抽象，并通过声明式的交付工作流来捕获面向混合环境的微服务应用交付的整个过程，甚至连多集群分发策略、流量调配和滚动更新等运维特征，也都声明在应用级别。用户无需关心任何基础设施细节，只需要专注于定义和部署应用即可。
|
||||
- **可编程式交付工作流** - KubeVela 的交付模型是利用 [CUE](https://cuelang.org/) 来实现的。CUE 是一种诞生自 Google Borg 系统的数据配置语言，它可以将应用交付的所有步骤、所需资源、关联的运维动作以可编程的方式粘合成一个 DAG（有向无环图）来作为最终的声明式交付计划。相比于其他系统的复杂性和不可扩展性，KubeVela 基于 CUE 的实现不仅使用简单、扩展性极强，也更符合现代 GitOps 应用交付的趋势与要求。
|
||||
- **运行时无关** - KubeVela 是一个完全与运行时基础设施无关的应用交付与管理控制平面。所以它可以按照你定义的工作流与策略，面向任何环境交付和管理任何应用组件，比如：容器、云函数、数据库，甚至 AWS EC2 实例等等。
|
||||
|
||||
|
|
@ -28,20 +28,6 @@ KubeVela 是一个开箱即用的、现代化的应用交付与管理平台。Ku
|
|||
- 第三方软件供应商（ISV）、垂直领域应用开发者：KubeVela 可以帮助你构建标准化的软件交付物，交付到任意云厂商和 Kubernetes 数据中心。
|
||||
|
||||
|
||||
## 架构图
|
||||
|
||||
KubeVela 的整体架构如下图所示：
|
||||
|
||||
|
||||
|
||||
### 控制平面
|
||||
|
||||
正如项目名字所暗示的那样，KubeVela 依靠 Kubernetes 作为应用交付与管理控制平面的核心实现。这个机制是 KubeVela 在大规模应用交付场景中保证自动化和确定性的关键所在。用户只需要通过以应用程序为中心的 API 与平台进行交互，然后 KubeVela 就会根据用户声明的策略、规则和工作流，将应用分发到目标基础设施运行起来，并始终确保这个状态的成功。
|
||||
|
||||
### 运行时基础设施
|
||||
|
||||
运行时基础设施是应用程序实际运行的地方。 KubeVela 允许你将应用程序交付到任何平台比如公有云、私有云、本地环境或者 Kubernetes 集群（本地、托管产品或 IoT/边缘）上。KubeVela 本身不运行在这些基础设施当中，并且与它们完全解耦。
|
||||
|
||||
## 产品形态对比
|
||||
|
||||
### KubeVela vs. 平台即服务 (PaaS)
|
||||
|
|
@ -78,4 +64,6 @@ KubeVela 是一个基于云原生技术栈构建的现代应用交付系统。
|
|||
|
||||
## 下一步
|
||||
|
||||
现在，让我们开始[安装使用 KubeVela](./getting-started/quick-install)！
|
||||
接下来，我们推荐你：
|
||||
- 开始[安装使用 KubeVela](./getting-started/quick-install)
|
||||
- 了解[系统架构](core-concepts/architecture)和[核心概念](core-concepts/application)
|
||||
Loading…
Reference in New Issue