美国西部工夫 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 诞生以来并不多见。
什么是 KubeVela？
一言以蔽之，KubeVela 是一个简略易用且高度可扩大的利用治理平台与外围引擎。KubeVela 是基于 Kubernetes 与 OAM 技术构建的。
具体的说，对于利用开发人员来讲，KubeVela 是一个非常低心智累赘的云原生利用治理平台，外围性能是让开发人员方便快捷地在 Kubernetes 上定义与交付古代微服务利用，无需理解任何 Kubernetes 自身相干的细节。在这一点上，KubeVela 能够被认为是 云原生社区的 Heroku。
另一方面，对于平台团队来讲，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 专家）。
这也是为什么在云原生生态中，简直每一个平台团队都会基于 Kubernetes 构建一个下层平台给用户应用。最简略的也会给 Kubernetes 做一个图形界面，略微正式一些的则往往会基于 Kubernetes 开发一个类 PaaS 平台来满足本人的需要。实践上讲，在 Kubernetes 生态中各种能力曾经十分丰盛的明天，开发一个类 PaaS 平台应该是比拟容易的。
然而事实却往往不尽如人意。在大量的社区访谈当中，咱们发现在云原生技术极大遍及的明天，基于 Kubernetes 构建一个功能完善、用户敌对的下层利用平台，仍然是中大型公司们的“专利”。这里的起因在于：
Kubernetes 生态自身的能力池诚然丰盛，然而社区里却并没有一个可扩大的、方便快捷的形式，可能帮忙平台团队把这些能力疾速“组装”成面向最终用户的性能（Feature）。
这种窘境带来的后果，就是只管大家明天都在基于 Kubernetes 在构建下层利用平台，但这些平台实质上却并不可能与 Kubernetes 生态齐全买通，而都变成一个又一个的垂直“烟囱”。
在开源社区中，这个问题会更加显著。在明天的 Kubernetes 社区中，不乏各种“面向用户”、“面向利用”的 Kubernetes 下层零碎。但正如前文所述，这些平台都无一例外的引入了本人的专属下层形象、用户界面和插件机制。这里最典型的例子包含经典 PaaS 我的项目比方 Cloud Foundry，也包含各种 Serverless 平台。作为一个公司的平台团队，咱们实际上只有两个抉择：要么把本人局限在某种垂直的场景中来适配和驳回某个开源下层平台我的项目；要么就只能自研一个合乎本人诉求的下层平台并且造无数个社区中曾经存在的“轮子”。
那么，有没有”第三种抉择”可能让平台团队在不造轮子、齐全买通 Kubernetes 生态的前提下，轻松的构建面向用户的下层平台呢？
KubeVela 如何解决上述问题？
KubeVela 我的项目的创建初衷，就是以一个对立的形式同时解决上述最终用户与平台团队所面临的窘境。这也是为何在设计中，KubeVela 对最终用户和平台团队这两种群体进行了独自的画像，以满足他们不同的诉求。
因为 KubeVela 默认的功能集与“Heroku”相似（即：次要面向利用开发人员），所以在下文中，咱们会以 利用开发人员 或者 开发者 来代替最终用户。但咱们很快也会讲到，KubeVela 里的每一个性能，都是一个插件，作为平台团队，你能够轻松地“卸载”它的所有内置能力、而后“装置”本人须要的任何社区能力，让 KubeVela 变成一个齐全不一样的零碎。
- 利用开发者眼中的 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 又是什么样子的。
- 平台工程师眼中的 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 社区能力封装形象成一个面向用户的下层平台个性的弱小工具。而作为这个平台的最终用户，利用开发者们只须要学习这些下层形象，在一个配置文件中形容利用，就能够一键交付进来。
- 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 里应用你所设计的能力。具体的形式，请参考 $ vela cap（即：插件能力治理命令）的应用文档。
原文链接
本文为阿里云原创内容，未经容许不得转载。