关于模型: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 团队进行交换。

Github 地址：https://github.com/alibaba/sr…

文章参考

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