OAM概念及KubeVela基础知识学习

OAM概念及KubeVela基础知识学习

结合B站KuBeVela开源项目介绍视频以及PPT等学习资料整理，阅读KuBeVela官方文档。仅供个人学习和回顾使用。

参考资料：

Introduction | KubeVela

Go开源说第三期KubeVela_哔哩哔哩_bilibili

开放应用模型（OAM）：全球首个云原生应用标准定义与架构模型-阿里云开发者社区 (aliyun.com)

DevOps和GitOps有什么区别？ - 知乎 (zhihu.com)

OAM概念

开放应用模型 （Open Application Model）OAM 是一个专注于描述应用的标准规范。

通过将应用定义与集群的运维能力分离，可以让应用开发者更专注于应用本身的价值点，而不是”应用部署在哪“这样的运维细节。关注点的分离让平台构建者可以轻松地把平台的运维能力封装成可被复用的组件，从而让业务应用开发者能够专注于将这些运维组件与代码进行集成，从而快速、轻松地构建可信赖的应用。

简单理解：OAM就是平台构建者（平台管理员）通过编写CRD打包成Component和Trait。

把自己的CRD或者社区的CRD稍微做一个分类和封装暴露给用户，用户只需要理解两个概念：Component和Trait。其中具体内容由CRD决定。

存在的问题

碎片化： 出现大量Paas/Serverless平台

烟囱化：没有横向交互能力，没有复用，不可移植

封闭：重复造轮子

形成了“谷仓”：

解决的方法

围绕用户易用性的抽象可以有效降低学习和使用的门槛。

如果对功能点进行一定程度的抽象，那么可以有效降低学习的成本。例如纯粹使用K8s，需要进行Pod、Deployment等概念的学习。

但是抽象程度越高，越易用，扩展性却显著降低。

K8s中，CRD+Controllers可以无限扩展，但是在Knative中，只能进行有限的扩展。

关注点分离

实际上存在的是面对两种用户的不同需求：“可扩展性”针对平台构建者（Platform Builder），“易用性”针对业务应用开发者（End User）

一般在PB和EU中间有多种抽象方式：组合抽象、转换抽象、拆分抽象等。

组合抽象：

例如在平台构建者（Platform Builder）方面，将一个Deployment（image+replicas）与Service（port）组合起来，在业务应用开发者（End User）方面看成一个WebService（image+replicas+port），这样业务应用开发者可以在研发的时候同时填上镜像、副本数以及端口，使之映射成K8s中的两个对象。

拆分抽象：

有的时候K8s中的内容大而全，但是对于业务应用开发者来说只需要关注部分比较重要的信息（镜像、副本数等），但是其他的内容（例如发布策略等）在研发时可能并不关心，则可以将其拆分出来。

转换抽象：

在K8s中，可能某个对象的某些字段完全没有人关心，那么可以在抽象的时候把它完全去除掉，使之成为一个比较简单、易于使用的接口，比如Deployment中的LabelSelectors，用户可能并不关心Label字段，则在抽象的时候将其转换成更少字段的一个对象，并自动填上需要填写的内容。

KubeVela

介绍

KubeVela是一个现代应用程序平台，它使跨混合、多云环境交付和管理应用程序变得更容易、更快。同时，它具有高度的可扩展性和可编程性，可以随着需求的增长而适应不同的需求。

KubeVela，一个既“用户友好易用” ，又 “高可扩展”的应用管理平台构建框架，一个标准化的云原生应用平台构建引擎。

（图片来源：GoCN社区https://gocn.vip/）

围绕一个应用的镜像、代码如何构建、启动参数、访问域名、路由策略、扩缩容等。在业务开发者方面，以应用为中心进行内容的填充。

文件内容可能会很长，但是格式、结构等清晰且简单。

适合gitopos，方便管理和回滚。

当前，KubeVela是基于K8s构建的，但是如果KubeVela架构流行起来的话，那么应用描述标准可以在不同的环境、平台上配置，做到K8s无关。

核心概念及系统架构

KubeVela 围绕着云原生应用交付和管理场景展开，背后的应用交付模型是 Open Application Model，简称 OAM ，其核心是将应用部署所需的所有组件和各项运维动作，描述为一个统一的、与基础设施无关的**“部署计划”**，进而实现在混合环境中标准化和高效率的应用交付。

**组件（Component）**定义一个制品或云服务的交付和管理形式，一个应用中可以包括多个组件，最佳的实践方案是一个应用中包括一个主组件（核心业务）和附属组件（强依赖或独享的中间件，运维组件等）。

**运维特征（Trait）**是可以随时绑定给待部署组件的、模块化、可拔插的运维能力，比如：副本数调整（手动、自动）、数据持久化、 设置网关策略、自动设置 DNS 解析等。用户可以从社区获取成熟的能力，也可以自行定义。

**工作流（Workflow）**由多个步骤组成，允许用户自定义应用在某个环境的交付过程。典型的工作流步骤包括人工审核、数据传递、多集群发布、通知等。

**应用策略（Policy）**负责定义指定应用交付过程中的策略，比如质量保证策略、安全组策略、防火墙规则、SLO 目标、放置策略等。

**版本记录 （Revision）**应用每进行一次部署，生成一个版本记录，版本中快照了应用的完整配置。用户可以在任意时候将应用在某个环境的部署实例回滚到任意部署完成的历史版本。

平台构建者在workflow之上，包含了很多组件，每个组件绑定了各自的trait，业务开发者就可以使用oam提供出来的抽象和应用进行交互。

业务开发者使用KubeVela的工作流程

①vela init

使用vela init回答问题生成基础Appfile

业务应用的域名？test

邮箱是什么（用于生成https的证书等）？

业务应用的名称？

应用工作负载的类型？

服务的名称（一个应用可能有多个服务）？

服务的镜像？

端口？

填写完成以后，会自动生成一个yaml格式的文件。（上图的Appfile文件）

②vela traits

如果还想要增加功能，可以通过vela traits来查看平台能力，并使用vela show traits查看能力细节。

③编辑appfile

根据能力的参数编辑appfile

④vela up

使用vela up启动应用

应用启动以后，可以使用命令做更多的操作。例如vela port-forward可以对应用进行端口的转发，这样本地也可以访问到这个应用，快速查看这个应用有没有run起来。同时也可以使用vela exec像docker exec一样进入这个容器。vela status查看应用的状态。

使用vela的CLI有围绕应用生命周期管理的一些工具。使用vela的CLI可以完成应用的发布和一些运维的操作。

平台构建者使用KuBeVela

为平台构建者提供强大的扩展能力，K8s CRD Controller注册即可使用，无需改造。

为平台侧提供标准化的抽象能力，以应用为中心，这样可以使得业务开发者方面可以很容易地使用Appfile。

围绕能力的体系架构，任何KuBeVela的功能都是插件式的独立模块，所以安装一种能力和删除一种能力都非常简单。

所以KuBeVela的定位就是一个构建平台的脚手架，将K8s中各种各样强大的能力组装起来，形成自己的业务管理平台。

注册Definition

这是针对平台构建者需要学习的知识，真正的业务研发人员不需要掌握注册Definition的知识，平台构建者是基于K8s这一层工作的。注册CRD的工作是需要平台构建者来完成，其实也是K8s中比较简单的概念，只需要在里面填写一些基本内容，再将文件注册即可。

有了这些文件以后，在底层的能力层其实是统一的。在前面提到，很多业务平台都去构建K8s上的PaaS，所以构建了很多谷仓。但实际上有了底下一层注册以后，就可以构建一个统一的能力池，只需要一个大的K8s，然后里面装上各种各样的能力即可。此时，不同的业务平台只需要注册不同的Definition或者workloadDefinition文件即可。

例如，有的平台可以注册一个手动扩缩容，有的平台可以注册一个自动扩缩容。手动扩缩容可以是调用一个Controller去修改replicas等字段，自动扩缩容可能使用hpa能力，它们互相不会冲突，而是独立地为不同的平台进行服务。

GitOps应用

DevOps维基百科定义 DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

GitOps 是一种操作设置，GitOps 使用 Git 来自动化管理基础设施和配置、部署等。GitOps是一种集成在DevOps周期中的技术，是一种用于存储，管理和检索K8s，Swarm等容器协调器的部署描述符的方法。Git 存储库包含系统的整个状态，这意味着开发人员可以查看和审核系统状态的任何更改轨迹。

在Git项目代码仓库中放入yaml文件，有了yaml文件以后，可以提交更新，无论是更新业务的代码文件还是运维的yaml文件都可以将这些功能进行合并。使用vela up将更改部署起来，KuBeVela在其中提供一个服务端的能力。

如果出现了问题，可以再提交一个commit或者进行回滚，再通过KuBeVela部署更新。

Appfile如何与K8s资源衔接

客户端抽象：DCL (Data Configuration Language)

对 K8s 资源进行抽象实际上就是在操纵 YAML 数据，通过 DCL 来完成相比于 CRD + controller 更简单，

无需编写代码，注册 CUE 配置即可使用。

用户在平台UI界面填写对应的数据，再通过CUE的模板形成完整的yaml文件。

CUE模板文件在appfile和UI界面中起了一个桥梁的作用，一方面形成jsonschema提供UI的展示字段，一方面在Appfile中注册对应的内容。

CUE语言

CUE 是 KubeVela 的核心依赖，也是用户实现自定义扩展的主要方式。

确保环境中已经安装如下命令行：

• cue v0.2.2 目前 KubeVela 暂时只支持 CUE v0.2.2 版本，将在后续迭代中升级支持新的 CUE 版本。
• vela >= v1.1.0

已经安装好了vela，查看一下版本：

$ vela version
Version: v1.2.2
GitRevision: git-29ecc5c
GolangVersion: go1.16.13

从git上下载：

https://github.com/cue-lang/cue/releases/download/v0.2.2/cue_0.2.2_Linux_x86_64.tar.gz

在WSL2上使用，先创建一个cue文件夹，将cue解压进去，再把里面的cue*文件放到执行目录中：

mkdir cue
tar -xvf cue_0.2.2_Linux_x86_64.tar.gz -C cue
cd cue
sudo mv cue /usr/local/bin/

成功安装，查看一下版本：

$ cue version
cue version 0.2.2 linux/amd64

上线服务流程示例

①平台研发团队开发了一个新的Operator用于进行监控，功能的名称叫做metrics，同时需要编写一个K8s能力描述文件metrics.yaml。

②平台管理员需要执行$ kubectl apply -f metrics.yaml对能力进行注册

③用户可以立即在Appfile中定义一个新的字段 metrics来使用这个能力且无需进行系统更新或者重启。

使用VelaUx

VelaUX 是一个可视化操作界面，包括 UI+API 服务，它适用于大多数厂商开箱即用的获取应用交付和管理能力。

国内环境可使用以下安装方式：

vela addon enable velaux serviceType=NodePort repo=acr.kubevela.net

serviceType 配置 velaux 服务的访问方式，如果你使用云服务集群，请配置为 serviceType=LoadBalancer：

vela addon enable velaux serviceType=LoadBalancer repo=acr.kubevela.net

启用完成后通过以下方式获取访问地址：

kubectl get service velaux -n vela-system -o jsonpath="{.spec.ports[0].nodePort}"

或者：

kubectl get service velaux -n vela-system -o jsonpath="{.status.loadBalancer.ingress[0].ip}"

如果你的集群中已经安装了 Nginx Ingress Controller，而且你具有可用的域名，你可以这样部署 VelaUX(请使用真实域名替换 example.doamin.com)：

vela addon enable velaux repo=acr.kubevela.net domain=example.doamin.com

ubectl get service velaux -n vela-system -o jsonpath="{.status.loadBalancer.ingress[0].ip}"

如果你的集群中已经安装了 Nginx Ingress Controller，而且你具有可用的域名，你可以这样部署 VelaUX(请使用真实域名替换 example.doamin.com)：

```shell
vela addon enable velaux repo=acr.kubevela.net domain=example.doamin.com