云端应用里程碑：OAM发布Kubernetes的标准实现和依赖库

今年 5 月，阿里云和微软云共同宣布，Open Application Model （OAM） 社区携手知名混合云管理项目Crossplane 社区，联合发布了 OAM 在 Kubernetes 平台上的标准实现与核心依赖库。本次合作达成后，OAM 社区成功的将标准应用定义和标准化的云服务管理能力统一起来，迈出了实现真正意义上的无差别云端应用交付的关键一步 。

去年 10 月 ，阿里云和微软共同推出了 OAM 项目，旨在构建围绕 Kubernetes 的云原生应用规范。OAM 描述了一个模型 —— 开发人员可以在其中定义应用程序组件；应用程序操作员负责创建这些组件的实例并为它们分配应用程序配置；基础架构运营商负责定义、安装和维护平台上可用的基础服务。

本次合作是阿里云、微软与 Crossplane 社区的三方技术合作，主要围绕 OAM 在 Kubernetes 上的标准实现以及 Crossplane 项目的 OAM 化展开。因为 Kubernetes 社区在落地 OAM 模型的过程中，提出了关于 OAM 标准实现的诉求。所以这次合作的一个重点，就是三方工程师使用 Go 语言开发了一个 OAM Kubernetes 核心依赖库。这个项目的名字叫做 oam-kubernetes-runtime 。OAM Kubernetes Runtime 将会成为 OAM 社区官方维护的基础组件，目标是在 Kubernetes 上提供稳定且统一的 OAM 核心插件。

为进一步了解本次合作的细节以及 OAM 项目的现状，我们邀请到了阿里云技术专家孙健波（花名：天元）、阿里云高级技术专家 Andy Shi ，共同探讨了 OAM 项目存在的意义。

OAM 因何而生

我们知道，应用容器技术自诞生开始，就以 “彻底改变了软件打包与分发方式” 的魅力迅速征服了几乎所有的云厂商与数据中心。 不过，软件打包与分发方式的革新，并没有能够让软件本身的定义与描述发生本质的变化，基于 K8s 的应用管理体验，也没有让业务研发与运维的工作变得更简单。

实际上，Kubernetes 带来的云原生技术革命，在于实现了基础设施层的标准化和抽象，但这一层抽象距离业务研发与运维还是太过遥远了。一个最典型的例子，直到今天，Kubernetes 里面始终都没有 “应用” 这个概念，它提供的是更细粒度的 “工作负载” 原语，比如 Deployment 或者 DaemonSet。

而在实际环境中，一个应用往往是由一系列独立组件的组合，比如一个 “ PHP 应用容器” 和一个 “数据库实例” 组成的电商网站；一个 “参数服务节点” 和一个 “工作节点” 组成的机器学习训练任务；一个由 “Deployment + StatefulSet + HPA + Service + Ingress” 组成的微服务应用。

“应用” 这个概念在 Kubernetes 项目中的缺失，既是一个有意而为之的设计，却也造成了今天云原生应用管理生态的极度碎片化和极高的学习门槛。如何通过标准化的方式去解决这个 “ Kubernetes 里到底什么是应用” 的问题，正是 OAM 项目发布的最初始动机。

有什么意义？

在 OAM 发布之前，云原生生态里其实并没有一个叫做 “应用” 的概念。哪怕在今天，全世界几乎每一个在落地云原生的团队，都有一个自己定义的 “应用” 的概念，它们的抽象程度层次不齐，定义方式也丰富多样，这就导致了所有围绕着这些 “应用” 构建出来的系统，就成为了一个又一个的大烟囱。

对于整个云原生生态来说，这种应用层的碎片化和烟囱化，其实对于整个生态演进是非常不利的。而今天的现状也已经证明了这一点，在 Kubernetes 逐渐标准化了基础设施能力的接入方式之后，原本更加接近用户、更加重要的应用管理层，却几乎停滞了演进，在最近几年里没有提出任何一个创新性的思想出来。

应用管理层停滞不前的结果，就是全世界的业务研发和运维一夜之间都被迫变成了 “容器专家”，一边学习着根本不应该是他们关心的各种 “基础设施即数据（Infrastructure as Data）” 领域的概念（比如：声明式 API，控制器等），一边吐槽 Kubernetes 实在是太复杂了、设计太奇葩了。

简而言之，Kubernetes 作为一个面向基础设施工程师的系统级项目，主要负责提供松耦合的基础设施语义，这就使得用户学习和操作 Kubernetes YAML 文件的时候，往往会感觉这些文件里的关注点非常底层，学习门槛很高。

实际上，对于Kubernetes 真正的最终用户比如业务研发人员和运维人员来说，他们并不想配置这些如此底层的资源信息，而是希望有更高维度的抽象。这就要求一个真正面向最终用户侧的应用定义，需要能够为业务研发和应用运维人员提供各自视角的应用定义原语。所以说，OAM 带来的第一个改变，就是提供了一种大家都可以遵循的、标准化的方式来定义更高层级的应用层抽象，并且把“关注点分离”作为这个定义模型的核心思想。

而 OAM 带来的第二个变化，则是为 Kubernetes 项目带来了应用定义，更确切地说，是对应用本身和它所需运维能力进行定义与描述的标准开源规范。站在 Kubernetes 项目的角度来讲，OAM 是一个 Kubernetes 原生的标准的“应用定义”项目，同时也是一个专注于封装、组织和管理 Kubernetes 中各种“运维能力”、以及连接“运维能力”与“应用”的平台层框架。

详细的说，OAM 基于 Kubernetes API 资源模型（Kubernetes Resource Model）来标准化应用定义的规范，它强调一个现代应用是多个组件的集合，而非一个简单的工作负载或者 K8s Operator。所以在 OAM 的语境中，一个 PHP 容器和它所依赖的数据库，以及它所需要使用的各种云服务，都是一个“电商网站”应用的组成部分。更进一步的，OAM 把这个应用所需的“运维策略”也认为是一个应用的一部分，比如这个 PHP 容器所需的 HPA（水平自动扩展策略）：

以 Crossplane 项目为例，它在本次合作中通过 OAM 升级之后得到了怎样的变化呢？

“ 作为混合云管理领域中的佼佼者，Crossplane 的 OAM 化保证了今天任何一个符合 OAM 规范的待运行程序、运维能力和它所依赖的云服务，可以组成一个整体在混合云环境中无缝漂移。”

这种平台无关的应用定义范式，使得应用研发人员只需要通过 OAM 规范来描述他们的应用程序，那么该应用程序就可以在任何 Kubernetes 群集或者 Serverless 应用平台甚至边缘环境上运行，而无需对应用描述做任何修改。本次合作中 Crossplane OAM 版的发布，则意味着 OAM 社区正在将标准应用定义和标准化的云服务管理能力统一起来，从而实现真正的 “云端应用交付” 。

OAM 如何发挥作用

那么 OAM 在一个项目中是如何运作的呢？

据介绍，OAM 以原生插件的方式运行在 Kubernetes 当中。OAM 强调整个模型是关注点分离的。即业务研发人员负责定义和维护组件 （Component） 来描述服务单元，而运维人员定义运维特征 （Trait），并将其附加到前面的组件上，最后构成 OAM 可交付物 ——ApplicationConfiguration。

这种设计是 OAM 在能够无限接入 Kubernetes 各种能力的同时，保证给业务研发与运维人员提供最佳的使用体验和最低的心智负担的重要基础。与此同时，基础设施工程师可以随时在 Kubernetes 中添加更多工作负载（例如 FaaS）以运行无服务器功能，或者添加运维特性（例如 CronHPA）来定义 CronJob 类型的 HPA 策略。OAM 以标准的声明方式在整个平台中管理应用交付能力和流程，并且提供面向各个角色的 API 原语来表达各自的诉求，最后通过 Kubernetes 把这些诉求落实。

什么样的项目需要 OAM

实际上，几乎所有基于 Kubernetes 的应用管理平台都对通过 OAM 来以标准化的方式去构建自己的应用模型有明确的诉求。另一方面，由于 OAM 是原生的 Kubernetes API 资源模型，这里的迁移过程难度很低，可以通过 API 对象灰度纳管的方式逐步完成迁移操作（通过 OAM 对象逐步接管现有 Kubernetes 对象）。

而相比于传统 PaaS 封闭的、不能同 “以 Operator 为基础的云原生生态” 衔接的现状，基于 OAM 和 Kubernetes 构建的现代云原生应用管理平台，本质上是一个 “以应用为中心” 的 Kubernetes ，保证了这个应用平台在能够无缝接入整个云原生生态。同时，OAM 可以进一步屏蔽掉容器基础设施的复杂性和差异性，为平台的使用者带来低心智负担的、标准化的、一致的应用管理与交付体验。这就使得一个基于OAM 构建的 Kubernetes 应用平台，首先能够隐藏底层基础设施的细节（例如，是云还是物联网），专注于应用层抽象，提供以应用为中心的资源模型。

其次，OAM 划分了应用交付路径上的开发、运维、基础架构三种角色，分离了关注点，让流程更加清晰和易于管理。

第三，OAM 站在 K8s API 资源模型的肩膀之上，提供了可移植的应用与基础设施抽象，让一个应用描述可以完全不加修改的云、边、端等任何环境下直接交付运行起来。

除此之外，OAM 还定义了一组核心工作负载/运维特征/应用范畴，作为应用程序交付平台的基石。而平台开发者也可以添加更多工作负载（例如 FaaS 或者任意云服务），或者添加运维特性（例如 CronHPA）来定义 CronJob 类型的 HPA 策略。OAM 以标准的声明方式在整个平台中管理应用交付能力和流程。当模块化的 Workload 和 Trait 越来越多，就会形成组件市场。而 OAM 就像是这个组件市场的管理者，处理组件之间的关系，把许多组件集成起来变成一个产品交付给用户。OAM 加持下的 Kubernetes 应用管理平台，可以像乐高积木一样灵活组装底层能力、运维特征、以及开发组件。使得应用管理变得统一，功能却更加强大。

OAM 社区现状

谈到 OAM 项目社区的现状。“ 作为一个没有同商业诉求绑定的中立开源社区，OAM 生态自成立以来保持着较高的活跃度和参与度，大量的社区 Issue/PR贡献都来自阿里和微软之外的团队比如 AWS、腾讯、字节跳动、谐云、青云、好雨云、第四范式等生态参与者。除了阿里和微软本身以及基于 OAM 实现了内部应用管理架构的统一和标准化之外，不少基于 OAM 的云服务比如阿里云 EDAS 也已经上线。”

与此同时，OAM 技术体系也开始在很多大型社区用户（比如 MasterCard 万事达卡）中落地，同时也出现了产品和商业化的实践（比如：谐云的可视化OAM实现），甚至来自其它云厂商比如 AWS 的开源项目整合与对接。可以看到，OAM 社区正在迅速成长和壮大中。

开源社区的运作模式一直是我们比较好奇的地方。 据介绍，OAM 项目目前完全由社区驱动，由各子项目的 Maintainer 小组进行维护和管理。社区有每两周一次的社区会议（美国和北京时间各一个）来进行重大事项的讨论与决策和同步项目进度。整个社区的的工作流程按照 Maintainer 席位的投票机制来运转，同时兼顾最终用户的投票权。目前 OAM 社区的核心 Maintainer 来自阿里云，微软和 Crossplane 项目原有的成员。在推广策略上，由多个国际化大厂团队维护的 OAM 项目从诞生起就是完全面向国际化开源社区的运作方式，凭借阿里与微软自身场景，以及整个云原生社区和贡献者的高质量输入来驱动整个项目向正确的方向持续演进，在沟通、分享、协作的氛围中鼓励贡献和发展社区。这种模式下，一旦突破早期破冰阶段，在随后社区传播和推广方面会带来病毒式的效果。

目前 OAM 的版本是 v1alpha2 ，OAM 的版本之后会不停迭代，根据实际的场景持续演进；当然，同时 spec 本身也会保证规范的稳定和兼容。这个标准的更新速度主要是取决于用户的接受程度和反馈的情况，并且会在今年发布 Beta 版。本次合作中，OAM 已经发布了 Kubernetes 的标准实现与核心依赖库，这也就意味着未来整个开源生态都可以直接通过对接 Crossplane 或者 oam-kubernetes-runtime 来支持 OAM 标准，所以这样的项目很快会越来越多。