头图.png

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

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

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

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

点击回看完整视频: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 的用户

2.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 社区交流钉钉群,与更多开发和运维人员深入了解项目及其实际使用场景。