KubeVela 基础入门，有你想知道的全部

发布时间：2023-10-16 12:59:36 所属栏目：云计算来源：

导读：KubeVela是一个便捷的应用程序分发和管理工具，使用简单且易于升级，它使得应用在面向混合云环境中的交付更简单、快捷，是开放应用模型（OAM）的一个实现，所以我们需要先了解下 OAM。

后AM 简介
OAM（Open Appl

KubeVela是一个便捷的应用程序分发和管理工具，使用简单且易于升级，它使得应用在面向混合云环境中的交付更简单、快捷，是开放应用模型（OAM）的一个实现，所以我们需要先了解下 OAM。

后AM 简介
OAM（Open Application Model）是阿里巴巴和微软共同开源的云原生应用规范模型，OAM 的本质是根据软件设计的兴趣点分离原则对负责的 DevOps 流程的高度抽象和封装，一个以应用为中心的 K8s API 分层，这种模型旨在定义云原生应用的标准。
从 OAM 名称中可以看出，它是一个开放的应用模型：
开放（Open）：支持异构的平台、容器运行时、调度系统、云供应商、硬件配置等，总之与底层无关
应用（Application）：云原生应用
模型（Model）：定义标准，以使其与底层平台无关
为什么我们需要 OAM 模型呢？
现阶段应用管理的主要面临两个挑战：
对应用研发而言，Kubernetes 的 API 针对简单应用过于复杂，针对复杂应用却又难以上手；
对应用运维而言，Kubernetes 的扩展能力难以管理；Kubernetes 原生的 API 没有对云资源全部涵盖。
总体而言，面临的主要挑战就是：如何基于 Kubernetes 提供真正意义上的应用管理平台，让研发和运维只需关注到应用本身。
比如下面是一个典型的 K8s 资源清单文件，该 yaml 文件已经是被简化过的，但实际上还是比较长。
该方式针对简单无状态应用非常有效，精简 API 可以大大降低 K8s 的门槛。但是当出现大规模业务后，就会遇到很多复杂的应用，这个时候就会发现该 PaaS 应用平台能力不够了。比如ZK 多实例选主、主从切换这些逻辑，在这五个字段里就很难描述了。因为屏蔽大量字段的方式会限制基础设施本身的能力，而 K8s 的能力是非常强大而灵活的，所以我们不可能为了简化而放弃掉 K8s 本身强大的能力。

使用中间件的一些工程师跟我们开玩笑说，我这有个 Zookeeper 该用哪种 K8s 的工作负载接入呢？我们当然会想到可以让他们使用 Operator 了，于是他们就很懵逼地说到 Operator 是啥？

然后我们耐心的给他解释相关概念 CRD、Controller、Informer、Reflector、Indexer 这些就可以了，当然他们就更懵了，当然理论上也不需要理解。业务方更应该专注于他们的业务本身，当然我们就不得不帮他们一起写这个控制器了。为此我们需要一个统一的模型去解决研发对应用管理的诉求。

除了研发侧的问题之外，在运维侧同样也会有很多挑战。

云原生应用有一个很大的特点，那就是它往往会依赖云上的资源，包括数据库、网络、负载均衡、缓存等一系列资源。

当我们交付应用的时候比如使用 Helm 进行打包，我们只能针对 K8s 原生 API，而如果我们还想启动 RDS 数据库，就比较困难了。如果不想去数据库的交互页面，想通过 K8s 的 API 来管理，那就又不得不去写一个 CRD 来定义了，然后通过 Operator 去调用实际云资源的 API。

这一整套交付物实际上就是一个应用的完整描述，即我们所说的“应用定义”。这种定义方式最终所有的配置还是会全部堆叠到一个 yaml 文件里，这跟前面说的 all-in-one 问题其实是一样的，而且，这些应用定义最终也都成为了黑盒，除了对应项目本身可以使用，其他系统基本无法复用了。所以，我们需要一个新的方法来解决这个问题。

（编辑：马鞍山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!