KubeVela 高可扩展的云原生应用平台与核心引擎

https://www.oschina.net/news/121015/kubevela-open-source

美国西部时间 2020 年 11 月 18 日，在云原生技术 KubeCon 北美峰会 2020 上，CNCF 应用交付领域小组（CNCF SIG App Delivery) 与 Open Application Model (OAM) 社区，以及来自阿里云、微软云的 OAM 项目维护者们在演讲中共同宣布了 KubeVela 开源项目的正式发布。

什么是 KubeVela ？

基于 Kubernetes 与 OAM 技术构建的，简单易用且高度可扩展的应用管理平台与核心引擎。核心思想是：
让开发人员方便快捷地在 Kubernetes 上定义与交付现代微服务应用，无需了解任何 Kubernetes 本身相关的细节。在这一点上，KubeVela 可以被认为是云原生社区的 Heroku。

Heroku是支持多种编程语言的云平台，在2010年被Salesforce.com收购帮助开发人员构建和发布Web应用程序，而无需担心管理服务器、扩展操作或处理部署过程，支持Ruby、Java、Node.js、Python、PHP、GO等8种编程语言。

KubeVela 解决了什么问题？

让平台团队在不造轮子、完全打通 Kubernetes 生态的前提下，轻松的构建面向用户的上层平台。

核心问题是：Kubernetes 生态本身的能力池固然丰富，但是社区里却并没有一个可扩展的、方便快捷的方式，能够帮助平台团队把这些能力快速“组装”成面向最终用户的功能（Feature）。

这也是为什么在云原生生态中，几乎每一个平台团队都会基于 Kubernetes 构建一个上层平台给用户使用。最简单的也会给 Kubernetes 做一个图形界面，稍微正式一些的则往往会基于 Kubernetes 开发一个类 PaaS 平台来满足自己的需求。

KubeVela 对最终用户和平台团队这两种群体进行了单独的画像，以满足他们不同的诉求。KubeVela 里的每一个功能，都是一个插件，平台团队可以轻松地“卸载”它的所有内置能力、然后“安装”自己需要的任何社区能力，让 KubeVela 变成一个完全不一样的系统。

1. 应用开发者眼中的 KubeVela

让开发者以极低的心智负担和上手成本在 Kubernetes 上定义与部署应用。而关于整个系统的使用，开发者只需要编写一个 docker-compose 风格应用描述文件 Appfile 即可，不需要接触和学习任何 Kubernetes 层的相关细节。

一个 Appfile 示例

vela.yaml 的 Appfile 放在你的应用代码目录中（比如应用的 GitHub Repo）。这个 Appfile 定义了：

如何将这个应用编译成 Docker 镜像
如何将镜像部署到 Kubernetes
如何配置外界访问应用的路由和域名
如何让 Kubernetes 自动根据 CPU 使用量来水平扩展这个应用

只要有了这个 20 行的配置文件，接下来唯一需要的事情就是:
$ vela up
这个应用就会被部署到 Kubernetes 中然后被外界以 https://example.com/testapp 的方式访问到。

这个 Appfile 是没有固定的 Schema 的，意思是基于这种模块化的设计，Appfile 本身是高度可扩展的。里面能够填写的每一个字段，直接取决于当前平台中有哪些工作负载类型（Workload Types）和可用的应用特征（Traits）。这是核心概念，其中：

工作负载类型（Workload Type），定义的是底层基础设施如何运行这个应用。
应用特征（Traits），则为工作负载实例加上了运维时配置。

在上面的例子中：

名叫 testapp 的应用会启动一个类型为“在线 Web 服务（Web Service）” 的工作负载，其实例的名字是 express-server。
定义了一个 Route Trait 来描述应用如何被从外界访问，以及一个 Autoscale Trait 来描述应用如何根据 CPU 使用量进行自动的水平扩容。

当任何新的 Workload Type 或者 Trait 被安装到平台后，用户可以立刻在 Appfile 里声明使用这个新增的能力。

举个例子，比如后面平台团队新开发了一个用来配置应用监控属性的运维侧能力，叫做 Metrics。那么应用开发者就可以立刻使用：
$ vela show metrics
命令查看这个新增能力的详情，并且在 Appfile 中使用它，如下所示：

这种简单友好、又高度敏捷的使用体验，正是 KubeVela 在最终用户侧提供的主要体感。
通过 KubeVela 部署的应用会被自动设置好访问 URL（以及不同版本对应的不同 URL），并且会由 cert-manager 生成好证书。与此同时，KubeVela 还提供了一系列辅助命令（比如：vela logs 和 vela exec）来帮助你在无需成为 Kubernetes 专家的情况下更好地管理和调试你的应用。

2. 平台工程师眼中的 KubeVela

KubeVela 不是一个简单的 PaaS 或者 Serverless，而是一个可以由平台工程师扩展成任意垂直系统的云原生平台内核，提供了三大核心能力：

第一：以应用为中心，让“应用”这个概念成为了整个平台对用户暴露的核心 API。因此，基于 KubeVela 扩展和构建出来的平台，天然是用户友好的：对于一个开发者来说，他只关心“应用”，而不是容器或者 Kubernetes；而 KubeVela 会确保构建整个平台的过程，也只与应用层的需求有关。

第二：Kubernetes 原生的高可扩展性。Appfile 是一个由 Workload Type 和 Trait 组成的、完全模块化的对象。任意一个 Kubernetes API 资源，都可以直接基于 Kubernetes 的 CRD 发现机制注册为一个 Workload Type 或者 Trait。这种可扩展性，使得 KubeVela 并不需要设计任何“插件系统”：KubeVela 里的每一个能力，都是插件，而整个 Kubernetes 社区，就是 KubeVela 原生的插件中心。

第三：简单友好但高度可扩展的用户侧抽象体系。KubeVela 中并不是仅仅简单的实现了一个 Appfile。KubeVela 在 OAM 模型层实现中集成了 CUELang 模板语言，从而为平台工程师基于 Kubernetes API 对象定义用户侧抽象（即：“最后一公里”抽象）提供了一个标准、通用的配置工具。更重要的是，平台工程师或者系统管理员，可以随时随地的每个能力对应的 CUE 模板进行修改，这些修改一旦提交到 Kubernetes，用户在 Appfile 里就可以立刻使用到新的抽象，不需要重新部署或者安装 KubeVela。

有了 KubeVela，平台工程师终于拥有了一个可以方便快捷地将任何一个 Kubernetes 社区能力封装抽象成一个面向用户的上层平台特性的强大工具。而作为这个平台的最终用户，应用开发者们只需要学习这些上层抽象，在一个配置文件中描述应用，就可以一键交付出去。

3. KubeVela vs 经典 PaaS

KubeVela 跟经典 PaaS 的设计目标是非常一致的，其优势体现在扩展性上。经典 PaaS 往往是不可扩展的，或者会引入属于自己的插件生态（哪怕这个 PaaS 是完全基于 Kubernetes 构建的），以此来确保平台本身的用户体验和能力的可控制性（比如 Cloud Foundry 或者 Heroku 的插件中心）。

这种高度可扩展的模型背后有着精密的设计与实现。比如：