深入解读：KubeVela与PaaS有何不同？

在 KubeVela 项目发布以后，很多国内外的社区同学们都会问到一个类似的问题：KubeVela 的体验真的非常棒，可以说是 Kubernetes 上的 Heroku 了。这么看来， KubeVela 跟 Heroku 这样的 PaaS 产品到底是不是一类项目呢？

今天，我们就专门来聊一个这个话题：KubeVela 与 PaaS 有何不同？

首先，我们先说结论：KubeVela 能够为用户带来非常接近 PaaS 的体验，但 KubeVela 并不是 PaaS。

为什么说 KubeVela 不是 PaaS？

绝大多数PaaS都具备完整的应用生命周期管理能力，同时高度重视用户体验的简洁友好以及研发效能的提升。在这些方面，KubeVela与PaaS的目标以及提供的用户体验是高度契合的。然而，倘若深入研究KubeVela的实现细节，便不难发现其整体设计与实现和各类PaaS项目存在着极大的差异。若从用户视角来看，这些差异会直接体现在整个项目的“可扩展性”上。

进一步来说，PaaS 的用户体验虽好，但却往往是不可扩展的。我们可以直接拿比较新的 Kubernetes PaaS，比如 Rancher Rio 项目来看。这个项目提供了很好的应用部署体验，比如 Rio run 来让你快速部署一个容器化应用、自动分配域名和访问规则等等。但是，如果我们想让 Rio 支持更多的能力以满足不同的用户诉求呢？

比如：

• 能否帮助我运行一个 定时任务？
• 能不能帮我运行一个 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 的“能力困境”。

相比之下，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 原生的可扩展性与灵活度。

原文链接

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