美国西部时间 2020 年 11 月 18 日，在云原生技术“最高盛宴”的 KubeCon 北美峰会 2020 上，CNCF 应用交付领域小组（CNCF SIG App Delivery) 与 Open Application Model (OAM) 社区，以及来自阿里云、微软云的 OAM 项目维护者们在演讲中共同宣布了 KubeVela 开源项目的正式发布。算法
从 11 月 18 号到 20 号，在为期三天的 KubeCon 北美峰会上有连续 3 场技术演讲，会从不一样维度介绍关于 KubeVela 项目的具体细节，其中还包括一个长达 1 个半小时的 KubeVela 互动教学环节。多个重量级组织以如此规模和密度在 KubeCon 北美峰会演讲中介绍一个首次发布的社区开源项目，在 KubeCon 诞生以来并很少见。docker
什么是 KubeVela ？
一言以蔽之，KubeVela 是一个简单易用且高度可扩展的应用管理平台与核心引擎。KubeVela 是基于 Kubernetes 与 OAM 技术构建的。数据库
详细的说，对于应用开发人员来说，KubeVela 是一个很是低心智负担的云原生应用管理平台，核心功能是让开发人员方便快捷地在 Kubernetes 上定义与交付现代微服务应用，无需了解任何 Kubernetes 自己相关的细节。在这一点上，KubeVela 能够被认为是云原生社区的 Heroku。express
另外一方面，对于平台团队来说，KubeVela 是一个强大而且高可扩展的云原生应用平台核心引擎。基于这样一个引擎，平台团队能够快速、高效地以 Kubernetes 原生的方式在 KubeVela 中植入任何来自云原生社区的应用管理能力，从而基于 KubeVela 打造出本身须要的云原平生台，好比：云原生数据库 PaaS、云原生 AI 平台、甚至 Serverless 服务。在这一点上，KubeVela 能够被认为是一个“以应用为中心”的 Kubernetes 发行版，以 OAM 为核心，让平台团队能够基于 KubeVela 快速打造出属于本身的 PaaS、Serverless 乃至任何面向用户的云原平生台项目。网络
KubeVela 解决了什么问题？
现现在，云原生技术的迅猛发展可能让不少人都感受到眼花缭乱，但实际上，这个生态的整体发展趋势和主旋律，是经过 Kubernetes 搭建了一个统一的基础设施抽象层，为平台团队屏蔽掉了“计算”、“网络”、“存储”等过去咱们不得不关注的基础设施概念，使得咱们可以基于 Kubernetes 方便地构建出任何咱们想要的垂直业务系统而无需关心任何基础设施层的细节。这正是 Kubernetes 被称为云计算界的 Linux 以及 “Platform for Platforms” 的根本缘由。架构
可是，当咱们把视角从平台团队提高到垂直业务系统的最终用户（如：应用开发人员）的时候，咱们会发现 Kubernetes 这样的定位和设计在解决了平台团队的大问题以后，却也为应用开发者们带来了挑战和困扰。好比，太多的用户都在抱怨 Kubernetes “太复杂了”。究其缘由，其实在于 Kubernetes 中的核心概念与体系，如：Pod、sidecar、Service、资源管理、调度算法和 CRD 等等，主要是面向平台团队而非最终用户设计的。缺少面向用户的设计不只带来了陡峭的学习曲线，影响了用户的使用体验，拖慢了研发效能，甚至在不少状况下还会引起错误操做乃至生产故障（毕竟不可能每一个业务开发人员都是 Kubernetes 专家）。app
这也是为何在云原生生态中，几乎每个平台团队都会基于 Kubernetes 构建一个上层平台给用户使用。最简单的也会给 Kubernetes 作一个图形界面，稍微正式一些的则每每会基于 Kubernetes 开发一个类 PaaS 平台来知足本身的需求。理论上讲，在 Kubernetes 生态中各类能力已经很是丰富的今天，开发一个类 PaaS 平台应该是比较容易的。less
然而现实却每每不尽如人意。在大量的社区访谈当中，咱们发如今云原生技术极大普及的今天，基于 Kubernetes 构建一个功能完善、用户友好的上层应用平台，依然是中大型公司们的“专利”。这里的缘由在于：运维
Kubernetes 生态自己的能力池当然丰富，可是社区里却并无一个可扩展的、方便快捷的方式，可以帮助平台团队把这些能力快速“组装”成面向最终用户的功能（Feature）。
这种困境带来的结果，就是尽管你们今天都在基于 Kubernetes 在构建上层应用平台，但这些平台本质上却并不可以与 Kubernetes 生态彻底打通，而都变成一个又一个的垂直“烟囱”。ide
在开源社区中，这个问题会更加明显。在今天的 Kubernetes 社区中，不乏各类“面向用户”、“面向应用”的 Kubernetes 上层系统。但正如前文所述，这些平台都无一例外的引入了本身的专属上层抽象、用户界面和插件机制。这里最典型的例子包括经典 PaaS 项目好比 Cloud Foundry，也包括各类 Serverless 平台。做为一个公司的平台团队，咱们实际上只有两个选择：要么把本身局限在某种垂直的场景中来适配和采纳某个开源上层平台项目；要么就只能自研一个符合本身诉求的上层平台而且造无数个社区中已经存在的“轮子”。
那么，有没有”第三种选择”可以让平台团队在不造轮子、彻底打通 Kubernetes 生态的前提下，轻松的构建面向用户的上层平台呢？
KubeVela 如何解决上述问题？
KubeVela 项目的创立初衷，就是以一个统一的方式同时解决上述最终用户与平台团队所面临的困境。这也是为什么在设计中，KubeVela 对最终用户和平台团队这两种群体进行了单独的画像，以知足他们不一样的诉求。
因为 KubeVela 默认的功能集与“Heroku”相似（即：主要面向应用开发人员），因此在下文中，咱们会以应用开发人员或者开发者来代替最终用户。但咱们很快也会讲到，KubeVela 里的每个功能，都是一个插件，做为平台团队，你能够轻松地“卸载”它的全部内置能力、而后“安装”本身须要的任何社区能力，让 KubeVela 变成一个彻底不同的系统。
1. 应用开发者眼中的 KubeVela
前面已经提到，对于开发者来讲，KubeVela 是一个简单、易用、又高可扩展的云原生应用管理工具，它可让开发者以极低的心智负担和上手成本在 Kubernetes 上定义与部署应用。而关于整个系统的使用，开发者只须要编写一个 docker-compose 风格应用描述文件 Appfile 便可，不须要接触和学习任何 Kubernetes 层的相关细节。
1）一个 Appfile 示例
在下述例子中，咱们会将一个叫作 vela.yaml 的 Appfile 放在你的应用代码目录中（好比应用的 GitHub Repo）。这个 Appfile 定义了如何将这个应用编译成 Docker 镜像，如何将镜像部署到 Kubernetes，如何配置外界访问应用的路由和域名，又如何让 Kubernetes 自动根据 CPU 使用量来水平扩展这个应用。
只要有了这个 20 行的配置文件，你接下来惟一须要的事情就是 $ vela up，这个应用就会被部署到 Kubernetes 中而后被外界以 https://example.com/testapp 的方式访问到。
2）Appfile 是如何工做的？
在 KubeVela 的 Appfile 背后，有着很是精妙的设计。首先须要指出的就是，这个 Appfile 是没有固定的 Schema 的。
什么意思呢？这个 Appfile 里面你可以填写的每个字段，都是直接取决于当前平台中有哪些工做负载类型（Workload Types）和应用特征（Traits）是可用的。而熟悉 OAM 的同窗都知道，这两个概念，正是 OAM 规范的核心内容，其中：
- 工做负载类型（Workload Type），定义的是底层基础设施如何运行这个应用。在上面的例子中，咱们声明：名叫 testapp 的应用会启动一个类型为“在线 Web 服务（Web Service）” 的工做负载，其实例的名字是 express-server。
- 应用特征（Traits），则为工做负载实例加上了运维时配置。在上面的例子中，咱们定义了一个 Route Trait 来描述应用如何被从外界访问，以及一个 Autoscale Trait 来描述应用如何根据 CPU 使用量进行自动的水平扩容。
而正是基于这种模块化的设计，这个 Appfile 自己是高度可扩展的。当任何一个新的 Workload Type 或者 Trait 被安装到平台后，用户就能够马上在 Appfile 里声明使用这个新增的能力。举个例子，好比后面平台团队新开发了一个用来配置应用监控属性的运维侧能力，叫作 Metrics。那么只须要举手之劳，应用开发者就能够马上使用 $ vela show metrics 命令查看这个新增能力的详情，而且在 Appfile 中使用它，以下所示：
这种简单友好、又高度敏捷的使用体验，正是 KubeVela 在最终用户侧提供的主要体感。
3）Vela Up 命令
前面提到，一旦 Appfile 准备好，开发者只须要一句 vela up 命令就能够把整个应用连同它的运维特征部署到 Kubernetes 中。部署成功后，你可使用 vela status 来查看整个应用的详情，包括如何访问这个应用。
经过 KubeVela 部署的应用会被自动设置好访问 URL（以及不一样版本对应的不一样 URL），而且会由 cert-manager 生成好证书。与此同时，KubeVela 还提供了一系列辅助命令（好比：vela logs 和 vela exec）来帮助你在无需成为 Kubernetes 专家的状况下更好地管理和调试你的应用。若是你对上述由 KubeVela 带来的开发者体验感兴趣的话，欢迎前往 KubeVela 项目的用户使用文档来了解更多。
而接下来，咱们要切换一下视角，感觉一下平台团队眼中的 KubeVela 又是什么样子的。
2. 平台工程师眼中的 KubeVela
实际上，前面介绍到的全部开发者侧体验，都离不开 KubeVela 在平台侧进行的各类创新性设计与实现。也正是这些设计的存在，才使得 KubeVela 不是一个简单的 PaaS 或者 Serverless，而是一个能够由平台工程师扩展成任意垂直系统的云原平生台内核。
具体来讲，KubeVela 为平台工程师提供了三大核心能力，使得基于 Kubernetes 构建上述面向用户的云原平生台从“阳春白雪”变成了“小菜一碟”：
第一：以应用为中心。在 Appfile 背后，其实就是“应用”这个概念，它是基于 OAM 模型实现的。经过这样的方式，KubeVela 让“应用”这个概念成为了整个平台对用户暴露的核心 API。KubeVela 中的全部能力，都是围绕着“应用”展开的。这正是为什么基于 KubeVela 扩展和构建出来的平台，自然是用户友好的：对于一个开发者来讲，他只关心“应用”，而不是容器或者 Kubernetes；而 KubeVela 会确保构建整个平台的过程，也只与应用层的需求有关。
第二：Kubernetes 原生的高可扩展性。在前面咱们已经提到过，Appfile 是一个由 Workload Type 和 Trait 组成的、彻底模块化的对象。而 OAM 模型的一个特色，就是任意一个 Kubernetes API 资源，均可以直接基于 Kubernetes 的 CRD 发现机制注册为一个 Workload Type 或者 Trait。这种可扩展性，使得 KubeVela 并不须要设计任何“插件系统”：KubeVela 里的每个能力，都是插件，而整个 Kubernetes 社区，就是 KubeVela 原生的插件中心。
第三：简单友好但高度可扩展的用户侧抽象体系。在了解了 Appfile 以后，你可能已经对这个对象的实现方式产生了好奇。实际上，KubeVela 中并非简单的实现了一个 Appfile。在平台层，KubeVela 在 OAM 模型层实现中集成了 CUELang 这种简洁强大的模板语言，从而为平台工程师基于 Kubernetes API 对象定义用户侧抽象（即：“最后一千米”抽象）提供了一个标准、通用的配置工具。更重要的是，平台工程师或者系统管理员，能够随时随地的每一个能力对应的 CUE 模板进行修改，这些修改一旦提交到 Kubernetes，用户在 Appfile 里就能够马上使用到新的抽象，不须要从新部署或者安装 KubeVela。
在具体实现层，KubeVela 是基于 OAM Kubernetes Runtime 构建的，同时采用 KEDA ，Flagger，Prometheus 等生态项目做为 Trait 的背后的依赖。固然，这些依赖只是 KubeVela 的选型，你能够随时为 KubeVela 定制和安装你喜欢的任何能力做为 Workload Type 或者 Trait。综合以上讲解，KubeVela 项目的总体架构由用户界面层，模型层，和能力管理层三部分组成，以下所示：
有了 KubeVela，平台工程师终于拥有了一个能够方便快捷地将任何一个 Kubernetes 社区能力封装抽象成一个面向用户的上层平台特性的强大工具。而做为这个平台的最终用户，应用开发者们只须要学习这些上层抽象，在一个配置文件中描述应用，就能够一键交付出去。
3. KubeVela VS 经典 PaaS
不少人可能会问，KubeVela 跟经典 PaaS 的主要区别和联系是什么呢？
事实上，大多数经典 PaaS 都能提供完整的应用生命周期管理功能，同时也很是关注提供简单友好的用户体验，提高研发效能。在这些点上，KubeVela 跟经典 PaaS 的目标，是很是一致的。
但另外一方面，经典 PaaS 每每是不可扩展的（好比 Rancher 的 Rio 项目），或者会引入属于本身的插件生态（哪怕这个 PaaS 是彻底基于 Kubernetes 构建的），以此来确保平台自己的用户体验和能力的可控制性（好比 Cloud Foundry 或者 Heroku 的插件中心）。
相比之下，KubeVela 的设计是彻底不一样的。KubeVela 的目标，从一开始就是利用整个 Kubernetes 社区做为本身的“插件中心”，而且“故意”把它的每个内置能力都设计成是独立的、可插拔的插件。这种高度可扩展的模型，背后其实有着精密的设计与实现。好比，KubeVela 如何确保某个彻底独立的 Trait 必定可以绑定于某种 Workload Type？如何检查这些相互独立的 Trait 是否冲突？这些挑战，正是 Open Application Model（OAM）做为 KubeVela 模型层的起到的关键做用，一言以蔽之：OAM 是一个高度可扩展的应用定义与能力管理模型。
KubeVela 和 OAM 社区欢迎你们设计和制做任何 Workload Type 和 Trait 的定义文件。只要把它们存放在 GitHub 上，全世界任何一个 KubeVela 用户就均可以在本身的 Appfile 里使用你所设计的能力。
本文为阿里云原创内容，未经容许不得转载。