开发者学堂课程【第八届大学生创新创业大赛阿里命题云原生命题培训：KubeVela 项目和能力简介】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1044/detail/15201
KubeVela 项目和核心简介
内容介绍：
一、了解什么是 KubeVela
二、创建 KubeVela 项目的初衷
三、KubeVela 的能力
一、 了解什么是 KubeVela ：
1. KubeVela 的背景
KubeVela 是一个简单易用又高度可扩展的云原生应用管理引擎，是最近半年发起的新项目。
KubeVela 实际是基于 OAM 模型构建的， OAM 模型是阿里和微软一起共同发布的，从2019年至现在一年半左右的时间， OAM 模型已经较为完备， KubeVela 基于 OAM 模型构建了一套具体的实现，可以端到端的为用户构建一个云原生应用的平台，提供一个相对完整的解决方案，通过 Golang 编写。
此项目从2020年七月开始在社区发起，受到了广大社区的志愿者欢迎，大家开始进行项目开发，包括阿里、微软、 Crossplane 等公司的工程师将在 OAM 中的实践经验教训，包括原来的 OAM 的实现和有用的功能都合并到了 KubeVela 项目里。
在2020年十月中旬 KubeCon 时正式发布，发布后的第四天，这一项目就登顶 God的开元的趋势榜首，为什么这个项目有这样的魅力呢，一方面是因为这个项目比较容易理解，一开始在 OAM 发布时，不容易理解这个模型能够做什么，但是这个项目提供了很多简单应有的 demo （样本）且可操作的部分，因此很容易被理解；另外一方面，可以看到，在应用管理方面的诉求较多，尤其是云原生应用管理需求较强。
2. 细看 KubeVela
首先 KubeVela 的用户分为两方面，一方面是平台团队，平台团队使用工具基于 Kubernetes 构建能够应用的应用管理平台，需要为用户构建应用管理平台，一些团队就将 Kubernetes 裸的概念暴露出去了，并不是暴露裸的 Kubernetes 概念就是好的， KubeVela 模板分为两类，一个是基于能力的模板，比如把一些概念被分装为 Web Service和一些概念分装为 Database ,同时能力模板里还有一些类型是基于工作负载的一些扩展，可以理解为运维的特征，这些特征包括金丝雀发布、自动扩缩容、路由访问等能力，统称为能力的模板，能力的模板分为两类，一类是工作负载，另一类是运维特征。
另外一类是部署环境模板，例如在发布应用时要先进行测试，测试完成后进行一个小流量的集群，最后再慢慢灰度到生产集群，这些不同的集群可能对应的能力是不一样的，所以在部署环境上也会有一套模板，这个模板上的能力也会不一样。基于这两个方面的模板，我们将它注册到 CRD里，加上 KubeVela的完整的能力，平台团队再将其能力注册到 KubeVela 里。
平台团队的业务用户，即平台团队服务的一些应用开发者，这类开发者，对 K8s 的具体的细节并不关心，如果平台还需要业务用户给出压模，开发者是不愿意用这样的平台的。开发者可以首先基于我们提供的环境模板，选择开发者需要部署的环境，再基于填写的能力模板，根据应用的工作负载，填写运维特征等参数，最后 KubeVela 进行组装渲染和拆分，变成 Kubernetes 的实际资源。可以看到，从比较简单的概念来看 KubeVela 为这两类用户各自提供了一些能力，让平台团队可以直接使用 Kubernetes 的概念组装出来一些能力的抽象，另外一方面平台团队的应用开发者们可以基于这些抽象构建出应用。
了解到 KubeVela 的大的概念后，需要了解KubeVela 创建的初衷。
二、 创建 KubeVela 项目的初衷：
1.业务实际使用场景与 K8s 概念之间存在 Gap
在 K8s 的社区中，都在基于 K8s 做一些扩展，做一些上层能力，这个能力是非常多的，但是当业务用户实际上应用 K8s 时，往往会认为 K8s 不太好用，甚至会有疑问： K8s 给业务产生了什么价值？
究其原因，用户希望的概念与 K8s 实际上提供的概念存在明显的 Gap ,从 API 来看，业务用户希望的是从代码开始最后构建 CI/CD pipeline ,但 K8s 提供的是 Deployment , Pod , Controller 这样的概念，从抽象的层次来看， K8s 提供了许多概念可以很方便的给用户提供一个组装的能力，不同的组件可以很容易地集成，但对于用户可能并不希望到手的是乐高，而希望得到的是一个拼好的玩具，而不是一块块散的组件，拿到的是一个完整的灰度发布的能力，可以直接使用，而不是需要了解去改一个 ingress ，一个istio 等等，这是一点 Gap 。
另外一方面， K8s 提供了很多压模可以供用户写，但是用户更希望有一个 GUI 的界面，一个 CLI 的工具方便使用。
2.针对不同场景构建的应用平台形成大量“谷仓”
除此之外，大家基于 Kubernetes 各自在构建这样的平台，出现大量 PaaS/Serverless 等的平台，基于 Kubernetes 构建平台较为容易，针对不同的场景，例如有状态应用平台、无状态应用平台、 Serverless 应用平台，这样就会产生大量的重复造轮子，而这些轮子没有横向的复用能力，会产生很多黑格，业务用户可能就会比较迷惑，不知道对接哪一个平台，每一个平台中抽象出来的新的概念可能会成为用户的学习负担，用户一点是不愿意发生这些状况的，此时形成的“谷仓”，造成的一些人力资源的浪费，是很多公司会存在的一些问题。
3.直接基于 K8s 构建 PaaS 不是银“银弹”
直接基于 K8s 构建一套应用管理平台也可能有问题，基于 K8s 在上面封装一层 API ，而这层 API 会成为瓶颈，例如把 Deployment 加 Service 封装成一个服务的概念，就很容易成为一个瓶颈，可能会成为一个“代码写死”的组合，如果新加入一个工具，社区里的生态不断发展，今天可能出现一个弹性扩缩容的软件叫 keda 可能又要去封装一下 keda ，需要写一个固定的 API ，明天又出现一个 istio 的扩展能力，可能又需要写一个固定的 API ,用户会发现社区能力的增长速度远远大于平台 API 扩展速度，所以 API 需要一个非常好的扩展性才能满足用户利益发展的需求，基于这样的背景，我们需要一个既能够给用户带来“用户友好易用”性，又有“高可扩展”的引擎—— KubeVela。
三、 KubeVela 的三个能力
KubeVela 有三个能力，第一个是快速构建抽象；第二个是快速构建用户界面；第三个是以应用中心的方式统一定义和管理云资源，这就和社区的一些云资源的组建做一些集成，还可能会有一些其他的集成首先来看看是如何实现三大能力的。
1. 快速构建抽象
在之前我们提到，用户在使用 K8s 时有一个很大的 Gap，这一层 Gap 实际上可以通过抽象来解决。
抽象是构建云原生平台应用平台的基础，抽象本质上分为这三种类型：转换抽象（一变一）、组合抽象（一变多）、拆分抽象（多变一）以及抽象后的状态回流。
（1）组合抽象：就像常见的模式，比如一个服务，要进行网络的访问，一个网络访问的服务，在底下是通过 Deployment 加 Service 构建的，这就是第一种组合方式，用户可能希望拿到的 WebService 的工作负载，在底下进行了一个组合，所以就通过这样个组合的抽象来给用户提供服务。
（2）拆分抽象：当我们在灰度发布时， K8s 生态经常会出现一些像 ArgoRollout 的发布能力，但这些发布能力可能有一些问题，就是把所有的概念全都糅杂全都在一起，有一些发布策略也在里面，有的用户可能在一开始使用时不关心发布策略。拆分抽像的能力可以使用户在使用时把这些概念拆开来使用，在单独使用 Workload 时，也能将应用运行起来，而不是说一定要填完 ArgoRollout。同时用户希望未来灰度发布时，用户希望有金丝雀的发布策略，也能将 Workload 与 Rollout 组装成 ArgoRollout。
（3）转换抽象：在K8s原来的概念中，有一些比较多余，如 Deployment 里的 labelSelectors 的概念，用户可能也不关心这一点。KubeVela 可以做一层转换，去就像 Knative Revision，去掉多余的参数，封装出干净的模型。
总结以上大的本质上的三种抽象的模式，可以为用户提供一个简洁易用的应用界面， KubeVela 为用户提供了统一的组合三种抽象模式的一些统一的方法。
除了这三种以外，可能会想到 KubeVela 提供的能力 Helm 也提供了，因为Helm 大家可能比较熟悉，认为 Helm也可以实现同样的效果，它可以把不同的 YAML 文件写成模板，模板里面能抠出来一些 Values，然后填写一些 Values 的信息。但是这里 Helm 有一个问题，就是组装完后 Helm 整体会成为一个黑盒，用户无法获得 Helm 里整体的状态。
举一个例子，Helm 安装完后，它把这些抽象的能力变成 K8s 原始的资源，但这些资源是否安装成功，Helm 是不关心的，或者说是很难获得这个信息。同时用户如果想做统一的能力，如要把 Rollout 抽出来的概念变成公共的功能，这种情况在 Helm 中无法实现，包括后期做统一的监控、统一的发布管理、统一的日志管理、统一的扩缩容等，Helm 均无法实现。但是在 KubeVela 中，基于 OAM 模型提供的公共的标准，就可以实现一些公共的能力。像状态回流和公共能力是 Helm 无法做到的两点，但用 KubeVela 可以很容易做到。
(4) KubeVela 对于抽象的实现：DCL(Data Configuration Language)：Helm 的抽象能力是基于 Go 的 template ,而 KubeVela 对于抽象的实现是则基于 DCL（ DataConfiguration Language ）。 Kubernetes 的前身是 Borg ，它在谷歌大规模使用时，有一个类似于脚本的配置语—— BorgConfig ，然后它对外开源的版本可以理解成一个 CUE ，即 DCL 。
CUE 的功能从图上来看，首先用户填一个简单的参数，也就是抽象数据，接着通过 CUE 的模板注册在 KubeVela 的服务端，然后用户填的数据和模板直接合并，最后生成一个完整的 K8s 的资源。这种过程看起来和 Helm 的 Go template 以及 Helm 的 Values 很像，但是 CUE 有比较强大的功能：
（1）很简洁：可以看到 Helm 的 templat 里和花括号可能很容易让人眼花缭乱，格式配错，例如多出一个空格，就无法运行，但是 CUE 是一个比较完整的语言，所有会有校验和格式化等等的工具可以便于用户使用，所以在排查问题方面非常方便，并且 CUE 看上去像是一个特定的格式，但是它基于 JSON ，又去掉了 JSON 中多余的部分，例如下图：正常的 JSON 是一个双引号里的字段，又有一些逗号，把原来可以去掉的，比如去掉了开头的双引号、句末的逗号，做了简化，这样将 JSON 的格式完整的搬过来，也可以工作，同时 JSON 多余的信息在 CUE 里就可以简化， CUE 会变得较为简洁。
同时 CUE 的 Schema 校验的数据值的语法和 Values 几乎是一样的，如下图，在里面既可以写 Values 也可以写一个井号，写一个校验的类型，所以使用起来会比较简单。
举一个例子，有一些场景通过 CUE 构建了抽象，甚至不需要写代码，Schema 和 Value 语法一致之前，在 K8s 上做一些扩展时，通常情况下要写一个 CRD，现在有了 KubeVela 这个引擎，只要注册 CUE 配置即可使用，在多数场景下构建抽象就不需再编写代码了。
如上图所例，首先从 ① 开始，定义工作负载的 Workload ， Workload Definition 实际上是一个模板，这个模板讲的是工作负载里一个 Deployment 的模板，Deployment 下面是我们构建出来的参数—— Parameter ，它提供了两个参数 Image 和 CMD 。之后相当于把这个参数填到了 ③ 上面的工作负载中，它的类型叫 Worker，也就是 ① 里面的 Worker。
同时还有一些抽离出来的参数，底下的 Deployment 里面，比如 Sidecar ，把它抽出来单独使用变成一个 Trait ，Trait 里面可以写一些内容如 NAME 或 Image 。如果不加 Trait，单独使用 Worker 也是完全可以的。同时这个 Trait 也可以给到其他基于 Development 或 spec 是带有 “ spec：
template:spec:containers ” 这种数组的工作模式负载使用， Trait 就可以直接附庸到其他工作负载。
在 KubeVela 中，用户只要简单填写参数就会拿到这两个模板，然后在 KubeVela 中做 Merge ，即 Patch 的合并，最后生成 Development ，整个过程和 Helm 里的 install 比较像，所以比较容易理解。
2. 快速构建用户使用界面
（1）Appfile：除了构建抽象，如何让用户使用，也是一个非常关键的问题。在这里 KubeVela 提供一个用户层的视角，对于不关心 K8s 的应用业务研发者， KubeVela 提供了 AppFile 的概念。
如上图所示，Appfile 里会包含镜像的构建、镜像如何启动、端口是怎样的、资源有多少等。同时包含了一些 Trait 的参数，例如用户希望能够对外的访问，提供一个域名、一个请求的 ari 地址、自动扩缩容的参数等，可以看到它是完全围绕应用展开的，没有多余的概念。同时它是一个文件，所以在做 gitops放到代码仓库里做统一变更时，体验效果非常好，同时它和应用环境没有关系，可以和环境的概念合并变成一个实际的不同环境的一个应用概念，补充一点，这实际上是一个 Schema free ，所以这个内容是可以扩展的，例如明天想要增加一个新的概念，日志收集的概念或者 matrics 的暴露，那么完全可以通过这一平台的快速扩展能力，增加这一个参数的。
Appfile 概念总结如下：
一个完整的应用描述文件（以应用为中心）
放置于应用代码库中（Gitops 友好）
$ vela up（一键部署）
无需学习 K8s 细节（完整的用户侧抽象）
自动适配任意 K8s 集群与部署环境（环境无关）。
（2）示例：上线新功能 Metrics ：平台研发团队：开发了一个新的功能叫做 Metrics是一个监控的功能，平台团队写好了一个 definition 文件，就是一个模板。
平台管理员：执行 $ kubectl apply -f metrics.yaml ，平台团队管理员直接执行到 K8s 里去， KubeVela 拿到了这样一个平台层的模板，
用户：立刻就可以在 Appfile 中定义一个新的字段 Metrics用户不需要去做任何系统的更新和重启，这时用户就可以看到这样一个能力，同时在 Appfile 里拿到扩展文件写上去，这个过程基本上不需要写代码，能力描述文件 metrics.yaml 。
（3）业务用户使用 KubeVela 的工作流程大致分为四个步骤：首先执行 vela init 命令，回答问题过程中会有一些选择，选择不同问题也不相同，回答问题也不同，生成基础 Appfile。
通过 vela traits 查看系统里有的扩展能力，同时要看你的系统里的扩展能力有哪些参数，然后将参数填上去就会看到一个配置文件，就可以填上去。根据能力的参数编辑 Appfile。最后，通过 vela up 命令启动应用。
（4）Dashboard/Restful API 支持类似机制
如上图所示，通过注册 Definition 文件，Vela 会提供一个 json schema 的 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 中，最后生成一个应用。
