基于Kubernetes打造“无限能力”的开放PaaS

简介： 本文整理自阿里云容器技术专家、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。更丰富的编排能力--数据传递与资源绑定。作者：孙健波（天元）