在 KubeVela 项目发布之后，不少国内外的社区同窗们都会问到一个相似的问题：KubeVela 的体验真的很是棒，能够说是 Kubernetes 上的 Heroku 了。这么看来， KubeVela 跟 Heroku 这样的 PaaS 产品究竟是不是一类项目呢？数据库
今天，咱们就专门来聊一个这个话题：KubeVela 与 PaaS 有何不一样？后端
备注：本文所提到的 PaaS，既包括 Heroku 这样的经典 PaaS 产品，也包括各类各样的基于 Kubernetes 的“云原生” PaaS。它们虽然底层实现不一样，可是对用户提供的使用接口和体验是类似的。但 OpenShift 是一个例外，做为一个比 Kubernetes 自己还复杂的项目，OpenShift 不属于本文所讨论的简单易用、面向用户的 PaaS 之列，而是一个地道的 Kubernetes 发行版。
首先，咱们先说结论：KubeVela 可以为用户带来很是接近 PaaS 的体验，但 KubeVela 并非 PaaS。服务器
为何说 KubeVela 不是 PaaS？
大多数 PaaS 都能提供完整的应用生命周期管理功能，同时也很是关注提供简单友好的用户体验，以及对研发效能的提高。在这些点上，KubeVela 跟 PaaS 的目标和提供的用户体验，是高度一致的。但若是你去研究 KubeVela 的实现细节，就不难发现 KubeVela 的总体设计与实现其实与各种 PaaS 项目的差异是很是大的。若是从用户视角来看，这些区别则会直接反应在整个项目的“可扩展性”上。架构
进一步来讲，PaaS 的用户体验虽好，但却每每是不可扩展的。咱们能够直接拿比较新的 Kubernetes PaaS，好比 Rancher Rio 项目来看。这个项目提供了很好的应用部署体验，好比 Rio run 来让你快速部署一个容器化应用、自动分配域名和访问规则等等。可是，若是咱们想让 Rio 支持更多的能力以知足不一样的用户诉求呢？app
好比：框架
- 可否帮助我运行一个 定时任务？
- 能不能帮我运行一个 OpenKruise 的 CloneSet 工做负载？
- 能不能帮我运行一个 MySQL Operator？
- 能不能根据个人自定义 metrics 来作水平扩容？
- 能不能基于 Flagger 和 Istio来帮我作渐进式灰度发布？
- 能不能 ……
而这里的关键点在于，上述这些能力在 Kubernetes 生态中都是很是常见的的能力，有的甚至是 Kubernetes 内置就能够支持。但是到了 PaaS 这里，要支持上述任何一个能力，都必须对 PaaS 进行一轮开发，并且因为先前的一些假设和设计，甚至极可能须要大规模的重构。运维
举个例子，我有一个 PaaS 系统，它全部的应用都是经过 Deployment 来执行的，那么这个 PaaS 的发布、扩容等功能，也都会直接按照 Deployment 来进行实现。而如今，用户提出了原地升级的诉求，须要让这个 PaaS 再支持 CloneSet，那整套系统极可能就得掀翻重来。再到运维能力这一侧，这个问题会更加严重，好比如今这个 PaaS 支持的是蓝绿发布策略，那么它跟流量管理、监控系统等依赖之间，都是须要大量交互和集成的。而如今咱们要让 PaaS 支持一个新的策略叫作“金丝雀”发布，那么全部的这些交互和执行逻辑基本全得重重构一遍，工做量是巨大的。模块化
固然，并非全部的 PaaS 都彻底没有可扩展性。工程能力比较强的 PaaS，好比 Cloud Foundry 和 Heroku，它们都提供了本身的插件能力和插件中心，在确保平台自己的用户体验和能力的可控制性的前提下开放必定的插件能力，好比容许用户接入本身的数据库，或者开发一些简单的 Feature 进去。但这种插件机制不管怎么作，说白了只能是这个 PaaS 专属的封闭小生态能力。而在云原生时代，咱们开源社区已经有了 Kubernetes 生态这样一个近乎“无限”的能力池，在这个能力池面前，任何 PaaS 专属的小生态都显得太苍白无力了。学习
上述问题，咱们能够统称为 PaaS 的“能力困境”。ui
相比之下，KubeVela 的目标从一开始就是利用整个 Kubernetes 生态做为本身的“插件中心”，而且“有意”把它的每个内置能力都设计成独立的、可插拔的插件。这种高度可扩展的模型，背后其实有着精密的设计与实现。好比，KubeVela 如何确保某个彻底独立的 Trait 必定可以绑定于某种 Workload Type？如何检查这些相互独立的 Trait 间是否存在冲突？这些挑战正是 Open Application Model（OAM）做为 KubeVela 模型层的起到的关键做用，一言以蔽之：OAM 是一个高度可扩展的应用定义与能力装配模型。
并且，你们设计和制做任何 Workload Type 和 Trait 的定义文件，只要存放在 GitHub 上，全世界任何一个 KubeVela 用户就均可以在本身的 Appfile 里使用这些能力。具体的方式，请参考 $ vela cap （即：插件能力管理命令）的使用文档。
因此说，KubeVela 提倡的是一种面向将来的云原平生台架构，这种架构认为：
- 应用平台自己架构完全模块化，其全部的能力都是可插拔的，而平台核心框架经过模型层提供标准化的能力封装与装配流程。
- 该流程可以无缝接入云原生生态中的任何应用管理能力，使得平台工程师彻底专一于能力自己的研发和基于该模型的能力封装过程，使平台团队在为用户带来简单易用的平台层抽象的同时，快速、敏捷地响应用户变幻无穷的应用管理诉求。
KubeVela 总体架构与能力可插拔机制
KubeVela 总体架构以下图所示：
在架构上，KubeVela 只有一个 controller 而且以插件的方式运行在 Kubernetes 之上，为 Kubernetes 带来了面向应用层的抽象，以及以此为基础的面向用户的使用界面，即Appfile。Appfile 乃至 KubeVela 运行机制背后的核心，则是其能力管理模型 Open Application Model (OAM) 。基于这个模型，KubeVela 为系统管理员提供了一套基于注册与自发现的能力装配流程，来接入 Kubernetes 生态中的任意能力到 KubeVela 中，从而以“一套核心框架搭配不一样能力”的方式，适配各类使用场景（好比 AI PaaS，数据库 PaaS 等等）。
具体操做上，做为系统管理员或者平台开发者，上述能力装配流程容许他们把任意的 Kubernetes API 资源（含 CRD）以及对应的 Controller 做为“能力”一键注册到 KubeVela 中，而后经过 CUE 模板语言将这些能力封装成用户可用的抽象（即成为 Appfile 中的一部分）。
接下来，咱们就来 Demo 一下如何将 kubewatch 这个社区中的告警机制直接插入到 KubeVela 中做为一个告警 Trait 来使用：
Step 1：将平台能力注册为 OAM 对象
首先，你须要肯定 CRD 所表示的能力是对应一个 Workload Type 仍是 Trait？这里的区别在于 Workload Type 指的是如何运行你的代码。而 Trait 指的是如何运维、管理或者操做已经运行起来的代码实例。
而 KubeWatch 做为一种告警机制，天然做为 Trait 来使用的。这时候，咱们就能够经过写一个 TraitDefinition yaml 来将它注册：
KubeVela 内置的服务器端 Runtime 会识别监听的 TraitDefinition 注册事件，而后将该能力归入平台管理中。
这一步完成，KubeVela 就已经注册完毕在 KubeVela 平台中可用了。但接下来咱们还须要将它暴露给用户使用，因此须要定义这个能力对外的使用接口。
Step 2：编写 CUE template 来封装对外暴露接口
实际上，大多数社区能力虽然很强大，但对于最终用户来都比较复杂，学习和上手很是困难。因此在 KubeVela 中，它容许平台管理员对能力作进一步封装以便对用户暴露简单易用的使用接口，在绝大多数场景下，这些使用接口每每只有几个参数就足够了。在能力封装这一步，KubeVela 选择了 CUE 模板语言，来链接用户界面和后端能力对象，而且自然就支持彻底动态的模板绑定（即变动模板不须要重启或者从新部署系统）。下面就是 KubeWatch Trait 的模板例子：
将这个模板放到 Definition 文件中并 $ kubectl apply -f 到 Kubernetes 中，KubeVela 就会自动识别和处理相关输入。这时候，用户就能够直接在 Appfile 中声明使用刚加进来的能力了，好比发送告警信息到指定的 Slack channel：
能够看到，这个 kubewatch 的配置是咱们经过三方扩展进来的一个新的能力，经过 KubeVela 平台管理 Kubernetes 扩展能力就是这么简单快速。有了 KubeVela，平台开发人员就能够简单快速地在 Kubernetes 上搭建起一个 PaaS，且可以将任何一个 Kubernetes 能力快速封装成面向最终用户的上层抽象。
以上示例，仅仅是 KubeVela 可扩展性的“冰山一角”。在后续的文章中，咱们会继续详细介绍 KubeVela 能力装配流程中更多的细节问题，好比：
- 如何定义能力之间的冲突关系与协做关系？
- 如何快速的定义 CUE 模板文件？
- 如何基于 CUE 语言定义出功能强大的“能力模块”，而后把这些模块安装到 KubeVela 中？
- 等等 ……
总结
原生的可扩展性与能力装配机制，是 KubeVela 与大多数 PaaS 项目的根本性不一样，这也致使 KubeVela 背后的实现和模型跟它们相比也有着本质性的差别。因此说，KubeVela 的核心目标，乃是在为用户带来简单易用的应用管理体验的同时，为平台管理员提供彻底 Kubernetes 原生的可扩展性与灵活度。
做者：邓洪超 阿里云高级技术专家， 人称 “Kubernetes Operator 第二人”，OAM 与 KubeVela 项目核心维护者。
本文为阿里云原创内容，未经容许不得转载。