乐趣区

关于chrome:基于-KubeVela-与-Kubernetes-打造无限能力的开放-PaaS

jiezi

简介：本文整顿自阿里云容器技术专家、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。

  1. 疾速构建用户应用界面

==============

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 外面也会有一个前端的性能，大家能够参照这个来做一些实现。

  1. 对立定义和治理云资源

==============

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 月中旬公布，它蕴含以下主体能力：

  1. KubeVela 的对立服务端接口 Application CRD 正式公布。
  2. 能力注册核心与扩大能力的包治理（包格局 / 装置 / 版本更新 / 依赖 / 抵触发现）。
  3. 基于 OAM 模型的对立公布能力（金丝雀、灰度、分批、滚动降级、无人值守钩子）。
  4. 用户敌对操作界面 KubeVelaDashboard，以及用于服务端对接的 Restful API。
  5. 集成 Helm，构建 KubeVela 利用交付链路，为 Helm 减少部署后的生命周期治理能力。
  6. 多集群、多环境的利用部署能力以及 K8s 环境无关的 APIServer。
  7. 更丰盛的编排能力 – 数据传递与资源绑定。

作者：孙健波（天元）

本文为阿里云原创内容，未经容许不得转载

退出移动版