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

你的名字 2022-11-05 00:48 114阅读 0赞

![头图.png][.png]

作者 | 孙健波（天元）  
来源 | 阿里巴巴云原生公众号

如今，围绕 Kubernetes 构建应用交付平台已经逐渐成为共识。

Kubernetes 生态本身的能力池固然是丰富的，但社区里并没有一个可扩展的、方便快捷的方式，能够帮助平台团队把这些能力快速“组装”成面向最终用户的功能（Feature）。因此，尽管大家都在基于 Kubernetes 构建上层应用平台，但这些平台本质上并不能与 Kubernetes 生态完全打通，而是变成一个个的垂直“烟囱”。

有没有方法让平台团队能够在不造轮子、完全打通 Kubernetes 生态的前提下构建上层平台，从而同时保证平台的易用性和可扩展性呢？本文整理自阿里云容器技术专家、OAM 规范主要制定者之一、KubeVela 作者和负责人孙健波（天元）在阿里云开发者社区“周二开源日”的直播分享，将剖析当前 Kubernetes  应用交付体系存在的问题详细介绍如何基于 OAM 和 KubeVela 体系赋能 PaaS，构建开放可扩展又易用的能力。

**点击回看完整视频：**[https://developer.aliyun.com/live/246067][https_developer.aliyun.com_live_246067]

# 什么是 KubeVela #

## 1. KubeVela 的起源 ##

KubeVela是一个简单易用又高度可扩展的云原生应用管理引擎，是基于 Kubernetes 及阿里云与微软云共同发布的云原生应用开发模型 OAM 构建。

KubeVela 基于 OAM 模型构建了一套具体的实现，通过 Golang 编写，可以端到端地为用户构建云原生应用的平台，提供一个相对完整的解决方案。

KubeVela 项目自 2020 年 7 月份在社区里面发起，受到包括阿里、微软、Crossplane 等公司工程师在内的广大社区志愿者的欢迎，并一起投入到项目开发工作中。他们把在 OAM 实践里面的各种经验与教训，都总结沉淀到 KubeVela 项目中。

![1.jpg][]

KubeVela 在 2020 年 11 月中旬正式发布，并于发布的第 4 天登顶 Github Go 趋势榜榜首。这个项目的魅力在于，一方面项目本身比较容易理解，因为大家刚看到 OAM 发布时，并不知道这个模型能够做什么，但是 KubeVela 提供许多开箱即用的功能以及可以实际操作的 Demo，使得大家更容易理解 OAM 模型以及 KubeVela 应用管理的能力。另一方面是由于许多用户在应用管理方面的诉求越来越强烈，尤其是云原生应用管理。

## 2. KubeVela 的用户 ##

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xS6tY94L-1614756252857)(https://ucc.alicdn.com/pic/developer-ecology/449523b6405c4751ad2608c8dc403384.jpg)\]

KubeVela 的用户主要面向的是平台团队，它为平台团队提供了一套模型，使得平台团队的业务用户可以通过简单易用的方式管理其应用。

在 KubeVela 出现之前，传统的 K8s 平台团队的主要职责可以理解为基于 Kubernetes 为用户构建应用管理平台。在实际操作中，有一些平台团队是直接向外暴露了裸 Kubernetes 的概念，但这种做法通常会带来一些问题，最突出的就是用户使用门槛高，不易理解。

针对这类问题，KubeVela 提供了一层统一的方式。主要包含两类模板，一类是基于能力的模板，包含工作负载类型，例如将一些概念封装成 Web Service，一些概念封装成 Database。还包含运维特征，是基于这些工作负载的扩展，特征包括金丝雀发布、自动扩缩容、路由访问等能力。

另外一类是部署环境模板。例如用户在发布应用前要先进行测试，测试完成后进行小流量的集群灰度发布，最后再慢慢灰度到生产集群，这些不同的集群对应的能力不一样。基于这两个方面的模板，我们将它注册到 CRD 注册中心里面，构成 KubeVela的完整能力池。

对于平台团队的业务用户，即平台团队服务的一些应用开发者，这类开发者聚焦业务实现，对 Kubernetes 的细节并不关心。在这样的前提下，开发者可以首先基于我们提供的环境模板，根据自己的实际需求选择并初始化部署环境。然后再选择能力模板，根据应用的工作负载，填写运维特征等参数。

最后由 KubeVela 进行组装渲染，变成 Kubernetes 的实际资源。

可以看到，KubeVela 为这两类用户各自提供了一些能力，平台团队可以直接使用 Kubernetes 的概念组装出来一些能力的抽象，应用开发者们可以基于这些抽象构建出应用。

# KubeVela 的能力 #

KubeVela主要有三个能力：

*  快速构建抽象
 *  快速构建用户使用界面
 *  以“应用为中心”的方式统一定义和管理云资源

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

## 1. 快速构建抽象 ##

### 1）抽象的类型 ###

在之前我们提到，用户在使用 K8s 时有一个很大的 Gap，这个 Gap 实际上是可以通过抽象来解决的。

抽象是构建云原生应用平台的基础，抽象本质上分为这三种类型：转换抽象（一变一）、组合抽象（一变多）和拆分抽象（多变一），以及抽象后的状态回流。

![3.jpg][]

*  组合抽象

以一个网络访问的服务为例，底下由 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 的功能如下图所示：

![4.jpg][]

首先用户填抽象数据，接着通过 CUE 的模板注册在 KubeVela 的服务端，然后用户填的数据和模板直接合并，最后生成一个完整的 K8sYAML。这种过程看起来和 Helm 的 Go template 以及 Helm 的 Values 很像，但是 CUE 有很多强大的功能，比如：

*  专注于操纵数据，而不是写代码
 *  完全兼容 JSON
 *  简单直观：Schema 和 Value 语法一致

之前大家在 K8s 上做一些扩展时，通常情况下要写一个 CRD，现在有了 KubeVela 这个引擎，在多数场景下构建抽象就不需再编写代码了，只要注册 CUE 配置即可使用。

![5.jpg][]

以上方为例，首先定义 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 的概念。

![6.jpg][]

如上图所示，Appfile 里会包含镜像的构建、镜像如何启动、端口是怎样的、资源有多少等信息。同时包含了一些 Trait 的参数，例如用户希望能够对外的访问提供一个域名、自动扩缩容的参数等，大家可以看到它是围绕应用展开的，没有一些多余的概念。同时它是一个文件，当用户在代码仓库里做统一变更时，体验效果非常好；同时它和应用环境没有关系，可以自动适配任意 K8s 集群与部署环境，并且具有很好的扩展能力。

总结 Appfile 概念如下：

*  一个完整的应用描述文件（以应用为中心）；
 *  放置于应用代码库中（Gitops 友好）；
 *  $ vela up（一键部署）；
 *  无需学习 K8s 细节（完整的用户侧抽象）；
 *  自动适配任意 K8s 集群与部署环境（环境无关）。

### 2）示例：上线新功能 Metrics ###

具体流程如下所示。

*  平台研发团队：
    
     *  开发了一个新 Operator 叫做 Metrics（监控）。
     *  编写一个 K8s 能力描述文件 metrics.yaml（如下方所示）。

![7.jpg][]

*  平台管理员：执行 $ kubectl apply -f metrics.yaml。
 *  用户：立刻就可以在 Appfile 中定义一个新的字段 Metrics（如下方所示）；无需系统更新或重启。

![8.jpg][]

对于业务用户来说，不需要做任何系统的更新或重启，就可以看到这个 metrics 的能力，同时在 Appfile 里拿到扩展能力的填写规范，轻松地用起来。

### 3）业务用户使用 KubeVela 的工作流程 ###

大致分为四个步骤：

*  首先执行 vela init 命令，回答问题生成基础 Appfile。

![9.jpg][]

*  通过 vela traits 查看平台能力，vela show metrics 查看能力细节。

![10.jpg][]

*  根据能力的参数编辑 Appfile。

![11.jpg][]

*  最后，通过 vela up 命令启动应用。

![12.jpg][]

### 4）Dashboard/Restful API 支持类似机制 ###

![13.jpg][]

如上图所示，通过注册 Definition 文件，Vela 会提供一个 jsonschema 的 API 包含的参数信息，这样就可以自动生成前端。同时 Vela 里面也会有一个前端的功能，大家可以参照这个来做一些实现。

## 3. 统一定义和管理云资源 ##

### 1）实现原理 ###

![14.jpg][]

在管理云资源方面，尤其是对对不同云资源管理的统一，社区里比较流行的一个项目叫 Terraform。Terraform 有很多 Package，这些 Package 对应不同云厂商的云资源的驱动，即不同的云资源都可以通过 Input一个Terraform  Package，然后再填一些参数，就可以完成启动。

KubeVela 和 Terraform 有非常好的联动。当用户用 workload defination 定义一个类似于 Terraform  Package 之后，把相应参数填入，最后定义用户应该填的是什么。上图右方可以看到，根据 Terraform 定义出来的参数，业务研发人员其实还是填简单的 Appfile，用户体验和刚刚基于直接 Kubernetes 抽象的体验是一样的。

在用户正常使用数据库时，可以在 configRef 里填一些配置的引用，这些引用来自 sample-db，填入后 KubeVela 会把 Terraform 的资源拉起，然后同时把获得的资源输出，加入 configRef 中，最后生成一个应用，如下图所示。

![15.jpg][]

### 2）KubeVela 架构 ###

![16.jpg][]

从整体的架构来看，最上层 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 月中旬发布，它包含以下主体能力：

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][https_oam.dev]
 *  KubeVela GitHub 项目地址：  
    [https://github.com/oam-dev/kubevela][https_github.com_oam-dev_kubevela]
 *  社区交流钉群：钉钉搜索群号 23310022 即可加入交流群

# “Kubernetes 与云原生应用开源实践大讲堂” #

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

![1613961888243-1a0d0fe2-6013-4511-a65b-5243d69eb71a.png][]

[.png]: /images/20221023/f8d6bfe1b2864598b259b956d16cc15b.png
[https_developer.aliyun.com_live_246067]: https://developer.aliyun.com/live/246067
[1.jpg]: /images/20221023/338809ad323f4b3790b7248c9ce7abd5.png
[3.jpg]: /images/20221023/87ae0445ca6e4022ba498c235f75c2c0.png
[4.jpg]: /images/20221023/fd8f4a0e959649a69cc82ebf762f2401.png
[5.jpg]: /images/20221023/91254c6c239f40649df371e05c9d0cd4.png
[6.jpg]: /images/20221023/039dfcb9f32f4d19906309ab483ef551.png
[7.jpg]: /images/20221023/2f3649ba54ef4ab488b82fd5e61a6b37.png
[8.jpg]: /images/20221023/4f45db4b85f2470b80f018bd60aab4fb.png
[9.jpg]: /images/20221023/7d78ff4ea211489fa97c86695322fbb0.png
[10.jpg]: /images/20221023/f8448187d9e144609ba5978e0aecbd45.png
[11.jpg]: /images/20221023/7d26d1a2b8bd4c52a848729460eafbf7.png
[12.jpg]: /images/20221023/fc62546bbcf84572affef830b942a98a.png
[13.jpg]: /images/20221023/fd983b19d42a4721a69da7efbee2868e.png
[14.jpg]: /images/20221023/d4e30f46274644628ca85cabe85d3fa5.png
[15.jpg]: /images/20221023/ed76d55da5914dc586efed2acd38d9c0.png
[16.jpg]: /images/20221023/202d806d72e94d53ae6da0046d18b799.png
[https_oam.dev]: https://oam.dev
[https_github.com_oam-dev_kubevela]: https://github.com/oam-dev/kubevela
[Kubernetes]: https://developer.aliyun.com/topic/k8s/practices
[1613961888243-1a0d0fe2-6013-4511-a65b-5243d69eb71a.png]: /images/20221023/2af43a58e7044644b950d1c9a0c3842d.png