KubeVela篇02:初识KubeVela,进一步理解OAM模型

原创 吴就业 159 0 2023-07-22

本文为博主原创文章,未经博主允许不得转载。

本文链接:https://wujiuye.com/article/fdcfcadc59694907b296b6e4bd6def2b

作者:吴就业
链接:https://wujiuye.com/article/fdcfcadc59694907b296b6e4bd6def2b
来源:吴就业的网络日记
本文为博主原创文章,未经博主允许不得转载。

KubeVela是面向混合云环境的应用交付控制面,不与任何云产商绑定。KubeVela通过提供插件扩展机制,打通了应用交付涉及的基础设施即代码-terraform等能力。编写一个符合OAM模型的application.yaml就能实现将应用部署起来,包括申请基础设施。实现了声明式部署,且一次编写,到处部署。

在KubeVela上部署一个应用涉及的几个系统

从我们定义一个Application.yaml,使用kubevela安装,到申请云资源,如VPC,涉及到kubevela、terraform、和kubevela的terraform controller。

kubevela核心引擎是基于Kubernetes开发的控制平台,无论哪种部署形式,底层都运行着一个Kubernetes,kubevela和Kubernetes相当于Java和JVM的关系。可以同应用使用同一个集群,也可以独立部署在一个k3s集群中,例如应用交付使用云平台,kubevela本地独立部署。

kubevela与kubernetes的关系 kubevela和terraform controller都是基于kubebuilder开发的operator,operator可以说是k8s提供的非常强大的扩展能力,所有的控制逻辑都是基于crd+controller实现。

kubevela的一些核心概念

Application(oam应用)

以下内容摘抄自官方文档

KubeVela 的核心是将应用部署所需的所有组件和各项运维动作,描述为一个统一的、与基础设施无关的“部署计划”,进而实现在混合环境中标准化和高效率的应用交付。

oam模型

oam模型组成

一个OAM应用主要包括四大模块:

Definition(模块定义)

官方文档把模块定义比作乐高积木,非常形象且易于理解:模块定义是组成 KubeVela 平台的基本扩展能力单元,一个模块定义就像乐高积木,它将底层的能力封装成抽象的模块,使得这些能力可以被最终用户快速理解、使用并和其他能力组装、衔接,最终构成一个具有丰富功能的业务应用。

大白话理解什么是模块定义:假设定义一辆车必须包含发动机+方向盘+四个轮+四个沙发,那么不管是保时捷还是法拉利,都是一辆车。k8s中的Service、Pod、Deployment我们也可以理解成一种模块定义,如根据Service定义创建出来的资源对象就是Service。

KubeVela根据OAM模型一共提供四种不同类型的模块定义,是构成OAM应用的四个基本概念:组件定义(ComponentDefinition)、运维特征定义(TraitDefinition)、策略定义(PolicyDefinition)以及工作流步骤定义(WorkflowStepDefinition)

ComponentDefinition、TraitDefinition、PolicyDefinition、WorkflowStepDefinition放到k8s上,其实就是四种CRD(自定义资源定义),每种CRD,kubevela都提供了对应的Controller实现逻辑。基于这四种CRD,我们可以提供非常丰富的组件、运维特征、策略定义、以及工作流步骤。例如,我们可以基于ComponentDefinition,自定义如微服务组件、中间件组件、云资源/云服务组件。

我们编写的多租户中间件Operator,其中定义了CRD提供给用户自主接入使用中间件。类似的,以ComponentDefinition为例,kubevela利用CRD提供不同的自定义组件接入。 kubevela工作原理 kubevela定义了不同的组件抽象(ComponentDefinition),比如使用terraform交付的自定义组件,比如kubevela提供的webservice组件,而每种类型的组件也提供对应的控制器去实现交付逻辑。如terraform类的组件由terraform-controller控制器实现控制逻辑,webservice组件是kubevela内置的其中一个组件,并且这个组件不需要额外的控制器实现,因为它的工作负载类型是Deployment。

怎么知道一个组件的工作负载类型?查看组件定义。

自定义的terrafrom类的组件,工作负载为terraform-controller的Configuration:

workload:
    definition:
      apiVersion: terraform.core.oam.dev/v1beta2
      kind: Configuration
    type: configurations.terraform.core.oam.dev

webservice组件,工作负责为Deployment:

workload:
  definition:
    apiVersion: apps/v1
    kind: Deployment
  type: deployments.apps

参考文献

  1. 官方文档:https://kubevela.io/zh/docs/
#云原生

声明:公众号、CSDN、掘金的曾用名:“Java艺术”,因此您可能看到一些早期的文章的图片有“Java艺术”的水印。

文章推荐

KubeVela篇05:为kubevela开发terraform-mycloud Addon插件

通过前面的章节,我们已经学习了解terraform,并通过vpc资源例子,为私有云/混合云开发了terraform provider,这一节介绍如何将我们开发的mycloud terraform provider整合到kubevela控制平台上,以通过在application中声明一个kubevela组件的方式去申请基础设施资源。

KubeVela篇04:KubeVela打通Terraform申请云资源

以使用阿里云的基础设施为例,理解KubeVela打通Terraform申请云资源。

KubeVela篇03:了解KubeVela安装一个应用的过程

以一个简单的first-vela-app应用在kubevela上部署为例,介绍应用安装流程。

KubeVela篇01:部署即代码-编写yaml在KubeVela上交付第一个应用

“部署即代码”即用代码描述一个应用的部署计划。KubeVela就是实现这一目标的平台,让我们可以编写一个符合OAM模型的yaml来描述应用的部署。

terraform篇03:terraform provider开发避坑指南

Go sdk本地开发调试sdk依赖问题;关于复杂嵌套结构体的schema声明;状态死循环监听,以及terraform命令终止时如何终止死循环;资源创建接口的默认可选字段不填遇到的坑;HCL代码输入变量的复杂校验。

terraform篇02:为私有云开发一个terraform provider

很多企业内部为了不与云厂商绑定,避免上云容易下云难的尴尬,以及企业内部可能也会做私有云,或者封装一个混合云平台,因此不能直接用云厂商提供的provider。