共计 4257 个字符，预计需要花费 11 分钟才能阅读完成。
作者 | 邓洪超 阿里云高级技术专家
起源 |阿里巴巴云原生公众号
在 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 反对更多的能力以满足不同的用户诉求呢？
比方：
- 是否帮忙我运行一个 定时工作？
- 能不能帮我运行一个 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 原生的可扩展性与灵便度。
KubeVela 我的项目是 OAM 社区的官网我的项目，由来自阿里、微软多位云原生社区资深成员独特保护，同时也是阿里云 EDAS 服务和外部多个双十一级利用治理平台背地的外围组件。KubeVela 旨在构建一个面向未来的云原生 PaaS 架构，将横向可扩展性和以利用为核心这些最佳实际带给大家，推动甚至引领云原生社区在应用层的倒退。
想要理解更多？欢送返回官方网站上学习更多示例：
- 返回学习 KubeVela Quick Start（老手教程），一步步理解 KubeVela 的应用办法。
- 返回 OAM 社区深刻交换和反馈。中文：钉钉群 23310022，英文：Gitter 和 CNCF Slack。
作者简介
邓洪超 阿里云高级技术专家，人称“Kubernetes Operator 第二人”，OAM 与 KubeVela 我的项目外围维护者。
