作者 雪尧(郭耀星) 炯思(钟炯恩)
前文我们提到了 Helm / Kustomize / CRD+Operator 这些方式,都可以在各自的领域很好的承载一个组件 (Component) 的概念。但是都没有解决一个完整的面向业务场景的应用 (Application) 的问题。
OAM (Open Application Model) 是 2019 年阿里云与微软联合推出的开放应用模型。下面我们来看这个模型是什么。
在应用部署上,大家或多或少有过一些这样的经历:面对复杂的K8S YAML手足无措,有些字段能理解含义,有些字段光从字面上又无法确认影响,有些已经确认的字段一提交修改就被提示报错,说这个字段运行态不能动。如果说k8s内置资源的字段基本都还有迹可循的话,通过CRD+Operator创建的自定义资源的很多字段都会放飞自我,连文档都找不到。那么这些YAML能不能做得像乐高积木一样呢?既能自由地插拔创造发挥,又有一些限制约束,使得创意不会太剑走偏锋,让后续使用者也能快速理解其中的作用和价值。
于是 OAM 应运而生。OAM(Open Application Model)是一个标准的、基础设施无关的跨云应用部署模型。有以下几个特性:
其实上面这些点写几个Operator也都能解决,但OAM的亮点在于他并不是一个程序的实现,他是一个文字定义的标准,大家只要依照这个标准去落地,就能把已有的东西整合起来发挥作用。下面来看一下OAM模型抽象:
如上图所示,OAM将一个模型分成了Application(应用)、Component(组件)、Trait(运维特征) 这样几层,于是相关角色的关注点也都被巧妙地分解开来,各角色只要聚焦于自己的内容就能一起协作完成一个复杂的应用工程,如下图所示:
OAM 通过一系列概念的定义,完成了对一个应用的抽象,实现了角色职责的分离,将应用交付这件事情与底座解耦,使得跨云快速交付应用成为可能。开发同学也不再关心底座实现细节,只关心自己的应用模型即可。OAM 的诞生,旨在定义云原生应用标准。
OAM 只是一纸协议,并没有应用/组件管理的能力,但它却定义了一个良好的管理应用/组件的系统应该是什么样子,通过一套统一的概念收拢社区中分散在各处的垂直能力工具。下面我们就来讲讲SREWorks如何基于这个协议构建完整的云原生运维生态。
SREWorks作为阿里大数据运维平台,在设计之初,云原生应用管理在满足内部业务需求时候,遇到了这样一些问题和挑战:
当SREWorks-Appmanager基于OAM实现了底层引擎,驱动各个服务的开发与交付流程之后,这些问题基本都有了答案,让我们来看看这些问题是如何被解决的。
如上图的YAML所示:
上面提到了各种组件(compent)和运维能力(trait),那么这些能力是从哪里来的呢?这些也是用插件机制增强出来的,可以看下图:
在Appmanager中预先定好了各种能力的接口(interface),一个插件只要实现这些接口(interface)就能够将能力增强到Appmanager中。用户可以基于这个机制来满足各种能力需求,比如将一个Flink服务制作成一个组件(compent),用户只要寥寥几行在YAML中加上这个组件,就能在自己应用中瞬间就有了流计算以及其管理能力。
在将一个应用做组件化拆解的时候,我们会遇到一个问题,像MySQL、Redis这种要如何拆。拆成一个普通的组件(compent)的话,有些资源少的场景,每个应用分配一个独享MySQL实例会导致资源不够分;拆成一个运维特征(trait)的话,每次申请一个实例的逻辑太重,不太符合一个特征的轻量级行为。所以我们将这类组件定义为addon。
在OAM模型定义中没有包含构建,在Appmanager中,我们对此进行了增强,将应用的生命周期延展到构建环节,用户可以基于源代码直接构建出组件,进而组成一个完整应用模型。下面是构建过程的拓扑:
总结一下,SREWorks中基于OAM的Appmanager基本满足了如下的核心诉求:
后续文章我们会分享更多的Kubernetes科普文章,均会发布在我们的公众号“阿里智能运维”上,请大家持续关注~也欢迎大家在公众号后台留言想了解的内容和感兴趣的相关话题,与SR EWorks团队进行交流。
Github地址:https://github.com/alibaba/sreworks