Kubernetes 资源编排系列之五: OAM 篇

作者 雪尧(郭耀星) 炯思(钟炯恩)

前文我们提到了 Helm / Kustomize / CRD+Operator 这些方式，都可以在各自的领域很好的承载一个组件 (Component) 的概念。但是都没有解决一个完整的面向业务场景的应用 (Application) 的问题。

OAM (Open Application Model) 是 2019 年阿里云与微软联合推出的开放应用模型。下面我们来看这个模型是什么。

1. OAM 是什么

在应用部署上，大家或多或少有过一些这样的经历：面对复杂的 K8S YAML 手足无措，有些字段能理解含义，有些字段光从字面上又无法确认影响，有些已经确认的字段一提交修改就被提示报错，说这个字段运行态不能动。如果说 k8s 内置资源的字段基本都还有迹可循的话，通过 CRD+Operator 创建的自定义资源的很多字段都会放飞自我，连文档都找不到。那么这些 YAML 能不能做得像乐高积木一样呢？既能自由地插拔创造发挥，又有一些限制约束，使得创意不会太剑走偏锋，让后续使用者也能快速理解其中的作用和价值。

于是 OAM 应运而生。OAM（Open Application Model）是一个标准的、基础设施无关的跨云应用部署模型。有以下几个特性：

• 应用为先。一个应用的交付与部署应该是自包含的，其中的各类操作行为应该作为应用定义的一部分，这些内容与实际基础设施无关。

• 清晰和可扩展性。定义一套开放标准，可以模块化整个应用交付流程，根据个人需要将这些模块自由组装，达成自己想要的结果。

• 云服务供应商无关。定义的开放标准应该是一套更高级别的抽象，可以跨本地集群、跨云服务供应商，不会被锁定到任何一个厂商的底座。

其实上面这些点写几个 Operator 也都能解决，但 OAM 的亮点在于他并不是一个程序的实现，他是一个文字定义的标准，大家只要依照这个标准去落地，就能把已有的东西整合起来发挥作用。下面来看一下 OAM 模型抽象：

如上图所示，OAM 将一个模型分成了 Application(应用)、Component(组件)、Trait(运维特征) 这样几层，于是相关角色的关注点也都被巧妙地分解开来，各角色只要聚焦于自己的内容就能一起协作完成一个复杂的应用工程，如下图所示：

• 应用开发人员：负责组件 Component 的定义及研发。

• 应用运维人员：

• 定义适用于不同 Workload 的运维属性 Trait 和管理 Component 的 ApplicationScope (or Policy)

• 将应用开发人员定义好的 Component 与运维属性 Trait 绑定在一起，辅以 Policy + Workflow，生成 Application，提交到 Runtime 实现，维护应用程序的生命周期

• 基础设施运维人员：提供不同的 Workload 类型映射到实际的基础设施。

OAM 通过一系列概念的定义，完成了对一个应用的抽象，实现了角色职责的分离，将应用交付这件事情与底座解耦，使得跨云快速交付应用成为可能。开发同学也不再关心底座实现细节，只关心自己的应用模型即可。OAM 的诞生，旨在定义云原生应用标准。

OAM 只是一纸协议，并没有应用/组件管理的能力，但它却定义了一个良好的管理应用/组件的系统应该是什么样子，通过一套统一的概念收拢社区中分散在各处的垂直能力工具。下面我们就来讲讲 SREWorks 如何基于这个协议构建完整的云原生运维生态。

2. SREWorks 的 OAM 落地实践

SREWorks 作为阿里大数据运维平台，在设计之初，云原生应用管理在满足内部业务需求时候，遇到了这样一些问题和挑战：

• 需要应用异地多活，避免单 Region 故障。

• 需要环境分离，区分开发测试与生产环境。

• 需要一定的集群扩展性，突破单一集群容量上限。

• 需要多云部署，避免受限于单一云底座，或降低成本。

• 开发者花费了太多的时间在基础设施的细节中。机器从哪来，网络环境怎么样，中间件资源/DNS/负载均衡怎么生成，服务怎么适配到各种底座等等。或者更进一步，每个开发者都是 YAML 工程师，哪怕都是 K8S，但每个底座让你提交的 YAML 都不一样。

• 可扩展性低。有越来越多的平台 or 底座在尝试去支撑各种类型需求的业务，但一般来说，应用本身对于平台的诉求会很快超越平台的能力。

• 云服务供应商绑定。当选择了一个固定的底座后，应用交付的方方面面将会打上这个底座的烙印，当想尝试转到另一个底座的时候难于登天。

当 SREWorks-Appmanager 基于 OAM 实现了底层引擎，驱动各个服务的开发与交付流程之后，这些问题基本都有了答案，让我们来看看这些问题是如何被解决的。

应用模块插拔

如上图的 YAML 所示：

• 通过运维能力(trait)注入进行运维能力的增强，使部署者不用关注太多底座基础设施的细节。

• 通过各种组件(compent)的插拔和参数变量(parameterValues)的定制来满足应用的功能需求。

• 通过工作(workflow)和策略(policy)来定制部署策略，满足灰度发布、金丝雀发布等多样的发布策略。

应用插件机制

上面提到了各种组件(compent)和运维能力(trait)，那么这些能力是从哪里来的呢？这些也是用插件机制增强出来的，可以看下图：

在 Appmanager 中预先定好了各种能力的接口(interface)，一个插件只要实现这些接口(interface)就能够将能力增强到 Appmanager 中。用户可以基于这个机制来满足各种能力需求，比如将一个 Flink 服务制作成一个组件(compent)，用户只要寥寥几行在 YAML 中加上这个组件，就能在自己应用中瞬间就有了流计算以及其管理能力。

应用组件 Addon 体系

在将一个应用做组件化拆解的时候，我们会遇到一个问题，像 MySQL、Redis 这种要如何拆。拆成一个普通的组件(compent)的话，有些资源少的场景，每个应用分配一个独享 MySQL 实例会导致资源不够分；拆成一个运维特征(trait)的话，每次申请一个实例的逻辑太重，不太符合一个特征的轻量级行为。所以我们将这类组件定义为 addon。

应用组件构建

在 OAM 模型定义中没有包含构建，在 Appmanager 中，我们对此进行了增强，将应用的生命周期延展到构建环节，用户可以基于源代码直接构建出组件，进而组成一个完整应用模型。下面是构建过程的拓扑：

总结一下，SREWorks 中基于 OAM 的 Appmanager 基本满足了如下的核心诉求：

• 构建：易于获取且一致的开发、测试环境；易于发现和使用的 API

• 交付：安全、可灰度的发布环境；可回滚的版本管理能力

• 运行：异常行为可观测；运行稳定且能够自愈

后续文章我们会分享更多的 Kubernetes 科普文章，均会发布在我们的公众号“阿里智能运维”上，请大家持续关注～也欢迎大家在公众号后台留言想了解的内容和感兴趣的相关话题，与 SREWorks 团队进行交流。

文章参考

1. https://developer.aliyun.com/article/741494 《OAM 深入解读(一)：OAM 为云原生应用带来哪些价值？》