本篇内容介绍了“KubeVela与PaaS的不同点有哪些”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
首先，我们先说结论：KubeVela 能够为用户带来非常接近 PaaS 的体验，但 KubeVela 并不是 PaaS。
大多数 PaaS 都能提供完整的应用生命周期管理功能，同时也非常关注提供简单友好的用户体验，以及对研发效能的提升。在这些点上，KubeVela 跟 PaaS 的目标和提供的用户体验，是高度一致的。但如果你去研究 KubeVela 的实现细节，就不难发现 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 只有一个 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 来使用：
首先，你需要确定 CRD 所表示的能力是对应一个 Workload Type 还是 Trait？这里的区别在于 Workload Type 指的是如何运行你的代码。而 Trait 指的是如何运维、管理或者操作已经运行起来的代码实例。
而 KubeWatch 作为一种告警机制，自然作为 Trait 来使用的。这时候，我们就可以通过写一个 TraitDefinition yaml 来将它注册：
KubeVela 内置的服务器端 Runtime 会识别监听的 TraitDefinition 注册事件，然后将该能力纳入平台管理中。
这一步完成，KubeVela 就已经注册完毕在 KubeVela 平台中可用了。但接下来我们还需要将它暴露给用户使用，所以需要定义这个能力对外的使用接口。
实际上，大多数社区能力虽然很强大，但对于最终用户来都比较复杂，学习和上手非常困难。所以在 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的不同点有哪些”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
