简介： 本文由“GO 开源说”第三期 KubeVela 直播内容批改整顿而成，视频内容较长，本文内容有所删减和重构。

KubeVela 的背景

KubeVela 是一个基于 Go 语言开发的云原生平台级开源我的项目，这个我的项目是去年 11 月中旬正式公布的。尽管公布到当初有余两个月工夫，然而 KubeVela 作为 ” 阿里巴巴对立云原生利用平台内核”背地的外围依赖，其实曾经在阿里多个产品背地运行了比拟长的一段时间，我自己目前也在大量参加这些产品和我的项目的内核建设工作。

这套内核零碎诞生自 2019 年年底阿里云联结微软独特推出的 Open Application Model（简称 OAM）模型基于 Kubernetes 的实现，在一直演进和迭代中交融了大量来自开源社区（尤其是微软、字节跳动、第四范式、腾讯和满帮团体的社区参与者们）的反馈与奉献，最终在 2020 年 KubeCon 北美峰会上以“KubeVela”的名字正式与开源社区见面。KubeVela 我的项目在官宣后失去了整个云原生生态的继续关注，在公布后的第四天就登上了 Go 语言的开源趋势榜榜首。

图 1  KubeVela 的 GitHub Star 快速增长

KubeVela 是什么？

一言以蔽之，KubeVela 是一个面向平台构建者的、简略易用但又高度可扩大的云原生平台构建引擎。

具体来说，KubeVela 的指标是让任何平台团队都可能以 Kubernetes 原生的形式，疾速、高效的打造出适宜不同业务场景的、可能直面用户的云原生平台进去。比方：构建利用 PaaS、数据库 PaaS、AI PaaS 或者继续交付零碎等等。

图 2  KubeVela“关注点拆散”的工作流

在设计上，KubeVela 对平台团队裸露了两大外围 API，包含：
 

1. 能力模板：“能力”在 KubeVela 中，指可能组成一个残缺利用的原子化性能，比方 StatefulSet 和 Ingress 就属于两种不同的“能力”。KubeVela 容许平台团队通过定义各种能力“模板”的形式，在 Kubernetes 中预置各种各样的能力。
2. 部署环境模板：与“能力”相似，利用的部署环境在 KubeVela 中通过“环境”模板来进行预约义和初始化，比方“测试集群”和“生产集群”，就属于两种“环境”。

而作为平台的用户，比方业务团队，他们只须要通过平台团队提供的环境模板来“一键”初始化本人预期的部署集群，而后把本人须要的能力模板“组装”成一个残缺的利用，就能够间接向任何 Kubernetes 集群进行利用交付和运维了。

因为上述这些能力和环境，都通过“模板”的形式进行了形象，所以对于业务团队来说，它们并不需要学习残缺的 Kubernetes 概念与细节，只须要理解上述模板裸露进去的参数，就能够无缝的应用 Kubernetes 来实现本人要做的事件。而具体通过模板暴露出哪些可配置项、背地的模板怎么渲染、渲染成什么样 Kubernetes 对象，则齐全全在平台团队的掌控之中，并且能够随时调节和批改。

上述“平台团队提供能力模板”联合“业务团队组装模板申明利用”的工作流，也正是阿里和微软独特公布的 OAM 我的项目提倡的“关注点拆散”思维的集中体现。在具体的模板反对上，KubeVela 第一期反对的是 Google 开源的 CUELang 模板语言，第二期则会反对 Helm Chart 包间接作为能力模板。

KubeVela 能为你做什么？

在理解了 KubeVela 是个什么我的项目当前，咱们再来答复第二个大家始终都很关怀的问题：作为一个平台构建者，KubeVela 可能帮忙你做什么?

1. 疾速构建形象

构建“形象”，是任何一个云原生平台的最根底、也必然会提供的性能。

咱们晓得，Kubernetes 裸露进去的是一套申明式 API，而所谓形象，其实就是一个平台在这些申明式 API 的根底上，为用户裸露进去的可操作项和可配置项。作为平台团队，咱们之所以要提供“形象”，其最终目标都是为了简化用户的应用心智，让业务团队只关注他们关怀的事件，防止引入大量与业务无关的平台层细节让用户“望而生畏”。能够说，提供“形象”，是任何一个平台团队落地 Kubernetes 等零碎级开源我的项目的第一步。

业界最常见的形象形式，是给用户提供一个图形界面来进行操作（比方 Console 或者 Dashboard），这些图形界面的共同点，就是仅容许用户填写某些特定的字段参数，从而实现简化用户心智的目标，比方下图所示的某开源 K8s PaaS 我的项目的 Console：

图 3  某开源 K8s PaaS 我的项目的 Console

还有一些我的项目（比方 Racher Rio）抉择给用户提供一个命令行工具，其实它的作用跟图形界面齐全相似，只不过容许填写的参数变成了 CLI 的参数而已。

当然，对于一些技术水位更高的团队，他们会基于 Kubernetes 再开发下层的 CRD + Operator 来作为“形象”。比方 Knative 其实就是一种面向 Serverless 场景的形象，Pinterest 公司则有本人的 Application CRD 形象等。

那么，作为平台团队，咱们又是怎么来决定给用户裸露哪些可配置参数呢？这就波及到了“形象”的三种根底模式（更简单的状况都是对这三种模式的进一步组合）：

• 组合形象，这种模式常见于咱们把 2 个原子能力组合成为一个能力提供，比方咱们在理论开发 Console 时，常常会把 K8s Deployment 和 Service 进行“组合”，暴露出一个 Web Service 的概念来让用户能够在一个表单里同时定义容器镜像和裸露端口。
• 拆分形象，这种模式常见于咱们心愿在应用流程上把一个对象上的字段离开成几个表单来进行分步骤填写，从而解耦部署时与运维时的配置。比方一个 Pod 外面的多个容器，我心愿在第一个表单里让用户填写业务容器，在另一个表单让运维填写 Sidecar 容器。再比方 ArgoRollout 这个对象，我会心愿一个表单让用户填写容器镜像，另一个表单让运维填写灰度策略。
• 转换形象，这种模式通常用于改个名字，或者说去掉一些无关的概念，比方 Knative Revision 跟 Deployment 实质上是一一对应的，然而外面相似 LabelSelector 这种用户不须要关怀的字段在 Knative 就会间接去掉了。

图 4  常见形象模式

上述几种形象的模式，在业界的很多平台级我的项目和产品中都有体现。但另一方面，如何正确的设计形象，以及如何确保形象可能满足业务方用户的应用需要和习惯，其实是一个十分具备挑战性的问题。这里的关键点在于，无论是图形化界面，还是 CRD Operator，这些“形象”一旦上线，对它的批改就十分艰难。可是另一方面，业务方用户的需要，又简直不可能是变化无穷的（理论状况甚至是“一天一个样”）。

KubeVela 对于“形象”的设计与实现

作为阿里巴巴的平台团队，咱们在进行大规模云原生利用基础设施的实际中，同样也遇到了如何设计“形象”的难题与挑战。通过大量的尝试与总结，咱们最终和研发效力团队一起抉择了 GitOps + IaC（Infrastructure as Code）的技术组合来解决这个问题（具体大家能够看这篇文章：《云原生时代，利用架构将如何演进？》）。

其中，GitOps 更多是对交付流水线的翻新，而 IaC 的存在，就是为了解决“形象”这个问题。具体来说，IaC 的弱小之处在于，它对“形象”的定义是通过“模板”来表白的。这意味着一个“形象”背地，并不需要 CRD Operator 这样简单的服务器端编程工作，作为平台团队咱们只须要提交一个模板，用户就“主动”有了形象后的字段；而如果要批改这些形象字段，咱们只须要将对应模板更新，用户那边的形象也就“主动”扭转了。这种形象机制的调整和更新，不须要任何从新编译和上线的环节，所以咱们把它也称为“客户端形象”。

图 5  用户、形象、模板和原始 K8s API 之间的关系

在具体的实现上，阿里巴巴是通过 CUELang 这个 Google 开发的模板语言来定义形象模板的，这也是为何 KubeVela 第一期先开源了基于 CUE 的形象机制。在具体应用上，平台团队只须要将 CUE 模板依照 OAM 标准（即：WorkloadDefinition  和 TraitDefinition 对象）注册（kubectl apply）到 Kubernetes 集群当中，业务用户就能够立即应用这个形象（具体的应用形式咱们前面会具体阐明）。

另一方面，CUE 之所以受到 Google 和阿里的青眼，还在于它比较完善的形象层实现能力。比方后面咱们总结了形象的三种模式，其中“转换形象”和“组合形象”在模板渲染的时候很容易做，无非就是模板渲染的时候换个字段名称，生成的内容变成多个对象而已。然而拆分形象其实是有很大难度的，这波及到拆分后能力的独立运行以及最终两个能力又重新组合到一起（patch-merge）的过程。

而借助 KubeVela，这个拆分就比较简单了。以后面提到解耦业务容器与 Sidecar 容器的定义流程为例，咱们心愿把“定义业务容器”和“定义 Sidecar 容器”在用户侧拆到两个不同的表单下来。在具体执行上，平台团队只须要注册一个 WorkloadDefinition 对象（名叫 worker），外面携带业务容器的 Deployment 模板，而后再注册一个 TraitDefinition 对象（名叫 sidecar），外面只携带 Sidecar 容器的模板，那么 KubeVela 就会对用户侧暴露出 worker 和 sidecar 两套齐全独立的可配置项，使得用户能够在部署时只须要填写 worker 中的业务容器参数，运维则能够在后续的运维时独立填写 sidecar 的配置参数，而齐全不须要对用户的 worker 局部进行任何批改。

图 6  KubeVela 对 Kubernetes  API 进行“拆分”的例子

当然，除了 CUE 之外，上述形象机制也能够通过 Helm 来实现，并且同 GitOps 流水线无缝集成。这个性能会作为 KubeVela 下一个重要个性公布，届时咱们会分享基于 KubeVela 构建继续交付零碎的案例与最佳实际。

2. 疾速构建用户应用界面

在有了上述“形象”之后，作为平台的最终用户，业务团队就能够通过某种形式应用这些形象来交付和治理利用了。在这一层，KubeVela 不会做任何束缚，相同，它的指标是让形象可能被间接透出在用户的应用界面上，这样，当平台团队对这些形象进行了调整之后，业务用户就能够立刻应用到最新的形象，不须要对系统做任何更新或者降级。

在具体执行上，KubeVela 会给上述形象主动生成  JSON schema，这个 JSON schema 的内容，就是该形象容许用户填写的参数列表和类型。所以无论是图形界面，还是其余用户界面，就能够间接应用这个 JSON schema 渲染出用户表单，甚至生成应用文档。

比方后面解耦 Sidecar 容器定义的例子，KubeVela 就会为用户暴露出两份 JSON schema：一个用来定义业务容器的参数列表，一个用来 Sidecar 容器的参数列表，前端就能够渲染成两个独立的表单来供用户填写。

正是上述 IaC 形象 + 主动生成 Schema 的机制，让基于 KubeVela 构建面向用户的应用界面不仅变得非常简单，而且还高度可扩大：这些形象背地的模板只有被平台管理员批改，就会立即体现在用户的图形界面表单上，基本不须要进行系统升级和从新上线。

在 KubeVela 中，它内置了一个简化版的图形界面，叫做 Appfile，它其实就是把上述形象的 schema 以 YAML 的形式展现了进去，从而容许用户进行批改和配置，在上面的例子中，咱们能够形象的看到每一个“能力形象”（route，autoscaler 等等）在 Appfile 如何体现为一个个可配置项的。

图 7  在 Appfile 应用 KubeVela 中的形象

图 8  应用 vela traits 查看曾经注册的能力

图 9  应用 vela show 查看能力的应用文档（主动生成）

目前，Appfile 是 KubeVela 内置的应用“形象”的次要用户界面。与此同时，雷同机制的 Dashboard 和 Restful API 则打算在  2021 Q2 在 KubeVela 中公布进去，从而让用户通过图形界面和 API 的形式来定义和应用这套形象机制。
 
值得一提的是，作为 Kubernetes 原生的平台构建引擎，KubeVela 的上述形象机制和 Appfile 自身，全副都以申明式 API 的形式实现在 Kubernetes 当中，其中 Appfile 对应的 CRD 就叫做 Application 对象。

所以作为平台团队，他们通过 Definition CRD 来注册形象模板，作为平台的用户，他们实际上则是通过这个 Application CRD 来应用形象模板，整套机制齐全以 Kubernetes 插件的形式运行，提供了最原生的被集成和可扩大能力。

3. 借助 Terraform  对立定义和治理云资源

而有了 Definition + Application 这套体系（这也正是 OAM 标准的核心内容）之后，KubeVela 就能够在一套对立的应用体验和 API 下，集成更多的能力提供方，比方：Terraform。

Terraform 是业内出名的创立云资源的工具，它丰盛的生态简直蕴含了所有支流云厂商的大部分云资源，是对 Kubernetes 云资源管理能力有余最好的补充。在 KubeVela 中应用 Terraform 定义和拉起云资源非常简单，如下图所示：

图 10  KubeVela 应用 Terraform 拉起云资源

1）平台团队：注册云资源模板和形象

平台团队的工作是定义一个名为 ”aliyun-rds” 的 WorkloadDefinition 对象，并且在外面定义好 Terraform 阿里云 RDS 云资源的模板。在上述例子中咱们同样是通过 CUE 来编写的 Terraform 配置，这是因为 Terraform 云资源自身反对应用 JSON 格局形容，而 CUE 又是 JSON 的超集，所以能够天然的应用 Terraform 所有的能力。

当然，另一方面咱们也在打算反对 Terraform 的 HCL 语法来作为 KubeVela 的另一种模板语言。在 CUE 模板中咱们援用了阿里云的 RDS 定义，并形象成 user、password 等大量用户字段（parameter）。

2）用户：定义和应用云资源

这样，用户只须要在 Appfile 中，填写一个新的 Service，命名为  sample-db 而其类型就是咱们下面定义的  aliyun-rds，就能够在这个局部定义模板中提供的 user，password 等参数。

除此之外，用户还能够在下面的  express-server 这个业务利用中定义数据绑定，填写名为 sample-db 的配置及其映射的环境变量名称。

最初，用户只须要一句  vela up 命令，KubeVela 就会拉起业务容器，而后主动把 Terraform 创立的阿里云 RDS 返回的链接信息传递到业务的容器中，咱们能够在最初一部分看到这个利用曾经胜利启动，并取得了数据库的连贯信息。当然，这个流程中的数据传递和编排性能，也是 KubeVela 内置的外围能力。

总结

作为 Kubernetes 上第一个云原生平台构建引擎以及 OAM 模型的残缺实现，KubeVela 为平台构建者提供的能力远不止这些，比方后续行将开源的对立利用灰度框架、多集群多环境的交付组件、CRD Controller 的生命周期治理等等，都是 KubeVela 重点打造的的外围能力。限于篇幅就不再一一开展，十分欢送大家到社区中应用和反馈，理解更多的细节。

欢送退出 KubeVela 社区

正如最开始所言，KubeVela 是一个由社区发动社区构建的我的项目，所以在我的项目的晚期，咱们就曾经播种了 38 名贡献者，来自数十家不同的公司，这是一个十分凋谢的社区，也有大量的新性能在布局和实现中，欢送大家的奉献、应用和反馈。

如果你想要更好的理解 KubeVela 我的项目，欢送返回其官方网站上学习具体的示例和手册。更高阶的，能够尝试为 KubeVela 增加来自开源社区的插件能力。此外，如果你有任何对于扩大 KubeVela 的微妙想法，比方，基于 KubeVela 开发一个本人的云原生数据库场景 PaaS 或者 AI 场景 PaaS，欢送返回 OAM 社区通过 Issue 来进行探讨。

作者：孙健波（天元）
原文链接
本文为阿里云原创内容，未经容许不得转载