简介： 本文整理自阿里云容器技术专家、OAM 规范主要制定者之一、KubeVela 作者和负责人孙健波（天元）在阿里云开发者社区“周二开源日”的直播分享，将剖析当前 Kubernetes 应用交付体系存在的问题详细介绍如何基于 OAM 和 KubeVela 体系赋能 PaaS，构建开放可扩展又易用的能力。
如今，围绕 Kubernetes 构建应用交付平台已经逐渐成为共识。
Kubernetes 生态本身的能力池固然是丰富的，但社区里并没有一个可扩展的、方便快捷的方式，能够帮助平台团队把这些能力快速“组装”成面向最终用户的功能（Feature）。因此，尽管大家都在基于 Kubernetes 构建上层应用平台，但这些平台本质上并不能与 Kubernetes 生态完全打通，而是变成一个个的垂直“烟囱”。
有没有方法让平台团队能够在不造*、完全打通 Kubernetes 生态的前提下构建上层平台，从而同时保证平台的易用性和可扩展性呢？本文整理自阿里云容器技术专家、OAM 规范主要制定者之一、KubeVela 作者和负责人孙健波（天元）在阿里云开发者社区“周二开源日”的直播分享，将剖析当前 Kubernetes 应用交付体系存在的问题详细介绍如何基于 OAM 和 KubeVela 体系赋能 PaaS，构建开放可扩展又易用的能力。
什么是 KubeVela
1. KubeVela 的起源
KubeVela是一个简单易用又高度可扩展的云原生应用管理引擎，是基于 Kubernetes 及阿里云与微软云共同发布的云原生应用开发模型 OAM 构建。
KubeVela 基于 OAM 模型构建了一套具体的实现，通过 Golang 编写，可以端到端地为用户构建云原生应用的平台，提供一个相对完整的解决方案。
KubeVela 项目自 2020 年 7 月份在社区里面发起，受到包括阿里、微软、Crossplane 等公司工程师在内的广大社区志愿者的欢迎，并一起投入到项目开发工作中。他们把在 OAM 实践里面的各种经验与教训，都总结沉淀到 KubeVela 项目中。
KubeVela 在 2020 年 11 月中旬正式发布，并于发布的第 4 天登顶 Github Go 趋势榜榜首。这个项目的魅力在于，一方面项目本身比较容易理解，因为大家刚看到 OAM 发布时，并不知道这个模型能够做什么，但是 KubeVela 提供许多开箱即用的功能以及可以实际操作的 Demo，使得大家更容易理解 OAM 模型以及 KubeVela 应用管理的能力。另一方面是由于许多用户在应用管理方面的诉求越来越强烈，尤其是云原生应用管理。
2. KubeVela 的用户
KubeVela 的用户主要面向的是平台团队，它为平台团队提供了一套模型，使得平台团队的业务用户可以通过简单易用的方式管理其应用。
在 KubeVela 出现之前，传统的 K8s 平台团队的主要职责可以理解为基于 Kubernetes 为用户构建应用管理平台。在实际操作中，有一些平台团队是直接向外暴露了裸 Kubernetes 的概念，但这种做法通常会带来一些问题，最突出的就是用户使用门槛高，不易理解。
针对这类问题，KubeVela 提供了一层统一的方式。主要包含两类模板，一类是基于能力的模板，包含工作负载类型，例如将一些概念封装成 Web Service，一些概念封装成 Database。还包含运维特征，是基于这些工作负载的扩展，特征包括金丝雀发布、自动扩缩容、路由访问等能力。
另外一类是部署环境模板。例如用户在发布应用前要先进行测试，测试完成后进行小流量的集群灰度发布，最后再慢慢灰度到生产集群，这些不同的集群对应的能力不一样。基于这两个方面的模板，我们将它注册到 CRD 注册中心里面，构成 KubeVela的完整能力池。
对于平台团队的业务用户，即平台团队服务的一些应用开发者，这类开发者聚焦业务实现，对 Kubernetes 的细节并不关心。在这样的前提下，开发者可以首先基于我们提供的环境模板，根据自己的实际需求选择并初始化部署环境。然后再选择能力模板，根据应用的工作负载，填写运维特征等参数。
最后由 KubeVela 进行组装渲染，变成 Kubernetes 的实际资源。
可以看到，KubeVela 为这两类用户各自提供了一些能力，平台团队可以直接使用 Kubernetes 的概念组装出来一些能力的抽象，应用开发者们可以基于这些抽象构建出应用。
KubeVela 的能力
KubeVela主要有三个能力：
- 快速构建抽象
- 快速构建用户使用界面
- 以“应用为中心”的方式统一定义和管理云资源
下面对这三个能力的实现原理进行分析。
1. 快速构建抽象
1）抽象的类型
在之前我们提到，用户在使用 K8s 时有一个很大的 Gap，这个 Gap 实际上是可以通过抽象来解决的。
抽象是构建云原生应用平台的基础，抽象本质上分为这三种类型：转换抽象（一变一）、组合抽象（一变多）和拆分抽象（多变一），以及抽象后的状态回流。
- 组合抽象
以一个网络访问的服务为例，底下由 Deployment 与 Service 组合构建而成，用户希望拿到工作负载 WebService，这样一个组合的抽象可以给用户提供服务。
- 拆分抽象
当我们在灰度发布时，K8s 生态经常会出现一些像 ArgoRollout 的发布能力，这些发布能力可能有个问题，就是把所有的概念全都糅杂在一起，有时用户在一开始使用时不关心的发布策略（如 Rollout）也在其中。“拆分抽像”的能力可以使用户在使用时把这些概念拆开来使用，在单独使用 Workload 部分时，应用也能正常运行，而不是说一定要填完 ArgoRollout。同时未来灰度发布时，用户如果希望有金丝雀的发布策略，KubeVela 也能将 Workload 与 Rollout 组装成 ArgoRollout。
- 转换抽象
在K8s原来的概念中，有的部分用户并不关心，如 Deployment 里的 labelSelectors。KubeVela 可以做一层转换，就像 Knative Revision，去掉多余的参数，封装出干净的模型。
通过以上三种方式，KubeVela 可以为用户提供一个简洁易用的应用管理界面。
讲到这里，可能会有人拿 KubeVela 与 Helm 做比较了，那么它们的区别是什么？Helm 大家比较熟悉，它可以把不同的 YAML 文件写成模板，模板里面能抠出来一些 Values，然后填写一些 Values 的信息。但是这里 Helm 有一个问题，就是组装完后 Helm 整体会成为一个黑盒，用户无法获得 Helm 里整体的状态。
举一个例子，Helm 安装完后，它把这些抽象的能力变成K8s原始的资源，但这些资源是否安装成功，Helm 很难获得感知。
同时用户如果想做统一的能力，如要把 Rollout 抽出来的概念变成公共的功能给 WebService 与 Knative Revision 使用，这种情况在 Helm 中无法实现，包括后期做统一的监控、统一的发布管理、统一的日志管理、统一的扩缩容等，Helm 均无法实现。但是在 KubeVela 中，基于 OAM 模型提供的公共标准，就可以实现一些公共的能力。
所以说，像状态回流和公共能力抽象是HELM无法做到的两点，但用KubeVela可以很容易做到。
2）KubeVela 对于抽象的实现：DCL(Data Configuration Language)
大家知道，Helm 的抽象能力是基于 Go 的 template，而 KubeVela 对于抽象的实现是则基于 DCL（DataConfiguration Language）。Kubernetes 的前身是 Borg，它在谷歌大规模使用时，有一个类似于脚本的配置语言 BorgConfig，然后它对外开源的版本可以理解成一个 CUE，即 DCL。
CUE 的功能如下图所示：
首先用户填抽象数据，接着通过 CUE 的模板注册在 KubeVela 的服务端，然后用户填的数据和模板直接合并，最后生成一个完整的 K8sYAML。这种过程看起来和 Helm 的 Go template 以及 Helm 的 Values 很像，但是 CUE 有很多强大的功能，比如：
- 专注于操纵数据，而不是写代码
- 完全兼容 JSON
- 简单直观：Schema 和 Value 语法一致
之前大家在 K8s 上做一些扩展时，通常情况下要写一个 CRD，现在有了 KubeVela 这个引擎，在多数场景下构建抽象就不需再编写代码了，只要注册 CUE 配置即可使用。
以上方为例，首先定义 Workload， WorkloadDefinition 实际上就是一个模板，这个模板讲的是工作负载里一个 Deployment 模板，Deployment 下面是我们构建出来的参数 Parameter，它包含两个参数 Image 和 CMD；之后相当于把这个参数填到了 ③ 上面的工作负载中，它的类型叫 Worker，也就是 ① 里面的 Worker。
同时还有一些抽离出来的参数，就是底下的 Deployment 里面，比如 Sidecar，把它抽出来单独使用变成一个 Trait，Trait 里面可以写一些内容如 NAME 或 Image。如果不加 Trait，单独使用 Worker 也是完全可以的。同时这个 Trait 也可以给到其他基于 Development 或带有 “spec：template:spec:containers” 这种数组模式的工作负载使用。
在 KubeVela 中，用户只要简单填写参数就会拿到这两个模板，然后在 KubeVela 中做 Merge，即 Patch 的合并，最后生成 Development。
2. 快速构建用户使用界面
1）Appfile
除了构建抽象，如何让用户使用也是一个非常关键的问题。在这里 KubeVela 给大家提供一个用户层的视角，对于不关心 K8s 细细的业务应用研发者， KubeVela 提供了 AppFile 的概念。
如上图所示，Appfile 里会包含镜像的构建、镜像如何启动、端口是怎样的、资源有多少等信息。同时包含了一些 Trait 的参数，例如用户希望能够对外的访问提供一个域名、自动扩缩容的参数等，大家可以看到它是围绕应用展开的，没有一些多余的概念。同时它是一个文件，当用户在代码仓库里做统一变更时，体验效果非常好；同时它和应用环境没有关系，可以自动适配任意 K8s 集群与部署环境，并且具有很好的扩展能力。
总结 Appfile 概念如下：
- 一个完整的应用描述文件（以应用为中心）；
- 放置于应用代码库中（Gitops 友好）；
- $ vela up（一键部署）；
- 无需学习 K8s 细节（完整的用户侧抽象）；
- 自动适配任意 K8s 集群与部署环境（环境无关）。
2）示例：上线新功能 Metrics
具体流程如下所示。
- 平台研发团队：开发了一个新 Operator 叫做 Metrics（监控）。编写一个 K8s 能力描述文件 metrics.yaml（如下方所示）。
- 平台管理员：执行 $ kubectl apply -f metrics.yaml。
- 用户：立刻就可以在 Appfile 中定义一个新的字段 Metrics（如下方所示）；无需系统更新或重启。
对于业务用户来说，不需要做任何系统的更新或重启，就可以看到这个 metrics 的能力，同时在 Appfile 里拿到扩展能力的填写规范，轻松地用起来。
3）业务用户使用 KubeVela 的工作流程
大致分为四个步骤：
- 首先执行 vela init 命令，回答问题生成基础 Appfile。
- 通过 vela traits 查看平台能力，vela show metrics 查看能力细节。
- 根据能力的参数编辑 Appfile。
- 最后，通过 vela up 命令启动应用。
4）Dashboard/Restful API 支持类似机制
如上图所示，通过注册 Definition 文件，Vela 会提供一个 jsonschema 的 API 包含的参数信息，这样就可以自动生成前端。同时 Vela 里面也会有一个前端的功能，大家可以参照这个来做一些实现。
3. 统一定义和管理云资源
1）实现原理
在管理云资源方面，尤其是对对不同云资源管理的统一，社区里比较流行的一个项目叫 Terraform。Terraform 有很多 Package，这些 Package 对应不同云厂商的云资源的驱动，即不同的云资源都可以通过 Input一个Terraform Package，然后再填一些参数，就可以完成启动。
KubeVela 和 Terraform 有非常好的联动。当用户用 workload defination 定义一个类似于 Terraform Package 之后，把相应参数填入，最后定义用户应该填的是什么。上图右方可以看到，根据 Terraform 定义出来的参数，业务研发人员其实还是填简单的 Appfile，用户体验和刚刚基于直接 Kubernetes 抽象的体验是一样的。
在用户正常使用数据库时，可以在 configRef 里填一些配置的引用，这些引用来自 sample-db，填入后 KubeVela 会把 Terraform 的资源拉起，然后同时把获得的资源输出，加入 configRef 中，最后生成一个应用，如下图所示。
2）KubeVela 架构
从整体的架构来看，最上层 KubeVela 从用户侧进来，然后是 Appfile / CLI / Dashboard 等使用界面，同时 KubeVela 给服务端的集成提供了许多能力，如用户可以将 KubeVela 当成内核使用，然后再基于 Kubernetes 来集成。有一个 CRD 叫 Application，通过这个 CRD 可以直接对接 KubeVela 的能力，同时还会有像 RestfulAPI 这种对接方式，直接有一个 HTTP 的接口来给用户对接。
然后到了 KubeVela 里面，分为两种概念，一个概念就是 Workload Types，另外一个概念是 Traits，这里面其实就是 OAM 传统应用模型的概念。
Workload 里面定义的是应用运行的一些主体，Traits 里是运维的特征及其它扩展。这些通过 CUE 配置语言，然后构建模板，对于用户来说，在上层可以拿到使用这些使用能力的方法，包括一些文档等。
下方是通过 CUE 把这些实际的资源翻译出来，翻译成 K8s 的 CRD 或原生的一些能力，然后 YourOwn 能力也是这样注册进去。注册进去以后，包括一些 CRD Controller 或 CUE 的模板，最上面提供一些发现的能力，再向下就是生成实际的资源。同时 KubeVela 还会提供一些 CRD 的注册管理、能力的管理、能力中心等功能。
Roadmap
KubeVela 1.0 即将在 2021 年 3 月中旬发布，它包含以下主体能力：
- KubeVela 的统一服务端接口Application CRD 正式发布。
- 能力注册中心与扩展能力的包管理（包格式/安装/版本更新/依赖/冲突发现）。
- 基于 OAM 模型的统一发布能力（金丝雀、灰度、分批、滚动升级、无人值守钩子）。
- 用户友好操作界面 KubeVelaDashboard，以及用于服务端对接的 Restful API。
- 集成 Helm，构建 KubeVela 应用交付链路，为 Helm 增加部署后的生命周期管理能力。
- 多集群、多环境的应用部署能力以及 K8s 环境无关的 APIServer。
- 更丰富的编排能力--数据传递与资源绑定。
作者：孙健波（天元）
本文为阿里云原创内容，未经允许不得转载