自 KubeVela 项目发布以来，海内外社区中很多开发者都会反复提到一个相似的问题：KubeVela 的使用体验确实非常出色，甚至可以被看作是 Kubernetes 上的 Heroku。那么，KubeVela 和 Heroku 这类 PaaS 平台，到底是不是同一类产品或项目？

今天，我们就专门围绕这个话题展开：KubeVela 与 PaaS 到底有什么区别？

首先，先给出结论：KubeVela 可以为用户提供非常接近 PaaS 的体验，但 KubeVela 本身并不是 PaaS。

为什么说 KubeVela 不是 PaaS？

绝大多数 PaaS 平台都具备完整的应用生命周期管理能力，同时非常强调简洁友好的用户体验和研发效率提升。在这些方面，KubeVela 与 PaaS 的目标高度一致，面向用户呈现出的体验也非常接近。然而，如果进一步深入到 KubeVela 的设计与实现层面，就会发现它与传统 PaaS、以及各类 Kubernetes PaaS 在架构思路上存在非常明显的差异。从用户视角出发，这种差异最终会集中体现在项目的“可扩展性”上。

进一步说，PaaS 的体验通常很好，但它的能力往往并不容易扩展。我们可以直接以较新的 Kubernetes PaaS 项目 Rancher Rio 为例。这个项目提供了优秀的应用部署体验，例如通过 Rio run 快速部署容器化应用、自动分配域名和访问规则等。但如果我们希望 Rio 支持更多能力，以满足不同团队、不同业务场景的需求，又会怎样呢？

比如：

• 能否帮我运行一个定时任务？
• 能否帮我运行一个 OpenKruise 的 CloneSet 工作负载？
• 能否帮我运行一个 MySQL Operator？
• 能否根据自定义 metrics 实现水平自动扩缩容？
• 能否基于 Flagger 和 Istio 实现渐进式灰度发布？
• 能不能 ……

关键在于，上述这些能力在 Kubernetes 生态中其实都非常常见，有些甚至是 Kubernetes 原生就支持的功能。但一旦放到 PaaS 场景中，想支持其中任何一种能力，往往都需要对 PaaS 本身进行新一轮开发；而受限于既有假设和设计，很多时候甚至需要进行大规模重构。

举个例子，假设我有一个 PaaS 系统，所有应用默认都是通过 Deployment 运行的，那么这个 PaaS 的发布、扩容等核心功能，也一定是围绕 Deployment 来实现的。此时，如果用户提出原地升级的需求，希望平台支持 CloneSet，那么这套系统很可能就需要推翻原有实现重新设计。再看运维能力，这个问题会更加突出。比如当前 PaaS 支持的是蓝绿发布策略，那么它与流量管理、监控系统等依赖之间，通常都已经建立了大量交互和集成逻辑。如果现在要再支持一种新的“金丝雀发布”策略，那么相关交互、执行链路和配套逻辑几乎都要重新改造，整体工作量会非常大。

当然，并不是所有 PaaS 都完全没有扩展能力。工程能力更强的 PaaS，例如 Cloud Foundry 和 Heroku，通常会提供自身的插件机制和插件市场，在保证平台整体体验和能力可控性的前提下，开放一定范围的扩展能力，比如允许用户接入自定义数据库，或者开发一些相对简单的功能模块。但无论这种插件机制如何设计，本质上它仍然只是这个 PaaS 专属的封闭小生态。而在云原生时代，开源社区已经拥有 Kubernetes 生态这样几乎“无限”的能力池。面对这样庞大的云原生能力生态，任何 PaaS 私有的小型插件生态都显得相对有限。

上述问题，可以统一概括为 PaaS 面临的“能力困境”。

与之相比，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 平台里，可以被系统识别和管理。不过，要让终端用户真正使用它，我们还需要继续定义该能力对外暴露的使用接口。

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 背后的实现方式和模型设计，与传统 PaaS 相比存在本质不同。因此，KubeVela 的核心目标，就是在为用户提供简单易用的应用管理体验的同时，为平台管理员带来完全 Kubernetes 原生的扩展能力与灵活性。

原文链接

本文为阿里云原创内容，未经允许不得转载。