如今，基于 Kubernetes 构建应用交付平台，已经逐步成为云原生领域的普遍共识。

Kubernetes 生态本身具备非常丰富的能力，但社区中一直缺少一种可扩展、便捷高效的方式，帮助平台团队将这些能力快速“组装”成面向最终用户的功能（Feature）。因此，虽然很多企业都在基于 Kubernetes 打造上层应用平台，但这些平台本质上往往无法与 Kubernetes 生态实现完全打通，最终容易演变为一个个垂直“烟囱式”平台。

那么，是否有一种方法，可以让平台团队在不重复造轮子、充分打通 Kubernetes 生态的前提下，构建上层应用平台，并同时兼顾平台的易用性与可扩展性？本文整理自阿里云容器技术专家、OAM 规范主要制定者之一、KubeVela 作者及负责人孙健波（天元）在阿里云开发者社区“周二开源日”中的直播分享，将深入剖析当前 Kubernetes 应用交付体系存在的问题，并详细介绍如何基于 OAM 和 KubeVela 体系赋能 PaaS 平台建设，打造开放、可扩展且易于使用的云原生能力平台。

点击回看完整视频：https://developer.aliyun.com/live/246067

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 主要具备三个核心能力：

• 快速构建抽象

• 快速构建用户使用界面

• 以“应用为中心”的方式统一定义和管理云资源

下面将对这三个能力的实现原理进行进一步分析。

1. 快速构建抽象

1）抽象的类型

前面提到，用户在使用 K8s 时往往存在较大的认知 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（Data Configuration Language）。Kubernetes 的前身是 Borg，在谷歌大规模使用时，它有一种类似脚本的配置语言 BorgConfig；其对外开源后的思路，可以理解为 CUE，也就是这里所说的 DCL。

CUE 的功能如下图所示：

首先，用户填写抽象数据，然后通过 CUE 模板在 KubeVela 服务端进行注册。接着，用户填写的数据会与模板直接合并，最终生成完整的 K8s YAML。这个过程看起来与 Helm 的 Go template 和 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 参数，例如用户希望对外访问时提供一个域名，或配置自动扩缩容参数等。可以看到，Appfile 是围绕应用本身展开的，不包含过多冗余概念。同时，它是一个文件，当用户在代码仓库中统一管理和变更时，整体体验会非常好；并且它与具体应用环境无关，能够自动适配任意 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 分别对应不同云厂商的云资源驱动。也就是说，各类云资源都可以通过引入一个 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 的能力；此外还支持 Restful API 这样的接入方式，通过 HTTP 接口直接与用户系统对接。

进入 KubeVela 内部后，主要分为两类核心概念：一类是 Workload Types，另一类是 Traits，这实际上就是 OAM 传统应用模型中的核心概念。

Workload 定义的是应用运行主体，Traits 则描述运维特征及其他扩展能力。通过 CUE 配置语言，可以构建模板。对于用户而言，在上层能够直接获取这些能力的使用方式，包括相应文档等内容。

下层则通过 CUE 将这些实际资源翻译出来，转换成 K8s 的 CRD 或原生能力，而 YourOwn 能力同样可以通过这种方式注册进去。注册完成后，无论是 CRD Controller 还是 CUE 模板，最上层都可以对外提供能力发现；再向下则生成实际资源。同时，KubeVela 还会提供 CRD 注册管理、能力管理、能力中心等功能。

KubeVela 1.0 即将在 2021 年 3 月中旬发布，主要包含以下核心能力：

1. KubeVela 的统一服务端接口 Application CRD 正式发布。
2. 能力注册中心与扩展能力的包管理（包格式/安装/版本更新/依赖/冲突发现）。
3. 基于 OAM 模型的统一发布能力（金丝雀、灰度、分批、滚动升级、无人值守钩子）。
4. 用户友好型操作界面 KubeVelaDashboard，以及用于服务端对接的 Restful API。
5. 集成 Helm，构建 KubeVela 应用交付链路，为 Helm 增加部署后的生命周期管理能力。
6. 支持多集群、多环境的应用部署能力，以及与 K8s 环境无关的 APIServer。
7. 更丰富的编排能力——数据传递与资源绑定。

以上就是本次分享的全部内容。想了解更多 OAM 和 KubeVela 相关信息，可以访问 KubeVela 官网或 Github 项目地址。也欢迎大家加入 OAM 社区交流钉钉群，与更多开发者和运维人员深入交流项目能力及实际落地场景。

• OAM 官网：https://oam.dev

• KubeVela GitHub 项目地址：https://github.com/oam-dev/kubevela

• 社区交流钉群：钉钉搜索群号 23310022 即可加入交流群

4 场云原生与 Kubernetes 技术前沿话题直播、70 节经典课程、3 本云原生电子书，来“Kubernetes 与云原生应用开源实践大讲堂”，与阿里云容器技术专家一起，将热门容器开源项目与前沿云原生应用落地实践一网打尽！点击直达“Kubernetes 与云原生应用开源实践大讲堂”！