作者：邓洪超阿里巴巴应用交付专家

前言

通过 K8s，用户能够自定义基础设施，可以平行的替换或改造平台的已有功能，而非只能局限在平台提供的能力之上构建。但正是这样的“白盒化”体验，正在为越来越多的研发和运维带来“太复杂”的困扰。

从 Kubernetes 到“以应用为中心”的美好未来之间，全世界的 PaaS 工程师其实都在期待一项全新的技术能够弥补这之间的鸿沟。阿里云原生应用平台团队的做法是，通过为应用“建模”的方式来解决这个问题，这也正是 Open Application Model (OAM) 开源项目得以创建的重要目的。

阿里巴巴的容器化之旅

阿里巴巴的容器化之旅始于 2013 年。在 Docker 诞生之前，阿里巴巴基于 lxc 的容器引擎研发了容器技术 T4，用于在裸机上部署和管理应用程序。

2017 年, 阿里巴巴内部孵化了类似于 K8s 的容器编排引擎 Sigma 作为资源统一层，用于管理内部机器池，平均利用率达到 40％。

2018 年，Sigma 重新设计并迁移成兼容 K8s API，阿里巴巴重新编写了自定义控制器和调度算法，并向暴露声明式 API 给用户试用。

2019 年底，阿里巴巴中的大多数应用都在 K8s 上运行，并且在 K8s 之上构建了数十个原生框架，构筑 K8s 生态系统。而 2019 年的双11 活动不仅仅是商业上的成功，更是 K8s 基础设施可以支持如此大规模的有力证明。

在解决了 K8s 中的规模化和稳定性问题之后，我们开始面临一个新的挑战：K8s API 过于复杂，开发人员很难学习。

导致 K8s API 复杂的 3 个原因

K8s API 之所以复杂，主要有以下三个主要原因：

1. K8s 缺乏以“应用”为中心的资源模型

K8s 中没有“应用”的概念，只有松散耦合的基础架构资源。部署应用需要编写 Pod、设置网络和存储之类的基础设施资源，非常底层。然而，对于开发人员来说，他们不想配置这些复杂的底层资源信息，他们想从开发层面指定应用部署规范，例如具有自动扩容、监控、Ingress 等功能的无状态服务组件。我们需要提供更高层级的应用层抽象和以应用程序为中心的资源模型，以弥合部署应用程序和配置之间的差距。

2. K8s API 中没有分离开发和运维的关注点

其次，K8s API 中没有分离开发和运维的关注点。从上图可以看出，K8s 将所有属于不同角色的字段封装在一个 API 中。例如，开发人员仅需指定容器映像、端口和运行状况检查；运维人员则负责配置副本大小、滚动更新策略、存储卷访问模式等。

对于 K8s API 来说这样的声明是没有问题的。K8s 意在公开基础架构功能，并用于构建其他平台。因此，它需要包含所有内容，并提供多合一的 API。但是，我们发现多合一 API 不适合写应用程序的终端用户。在 K8s API 之上，我们需要区分角色、将开发和运维的关注点分离开。

3. 在 K8s 上没有可移植的应用抽象定义

K8s 定义了使用基础资源的标准方法。但是如上所述，部署应用程序需要网络接入、监控、日志等。我们需要对那些应用程序操作接口进行标准化，实现可移植的应用层抽象。

OAM 开启下一代云原生 DevOps 技术革命

针对上述 K8s API 过于复杂、开发人员难学习的问题，这里来介绍一下由阿里巴巴联合微软在社区推出的用于构建和交付云原生应用的标准规范 -- 开放应用程序模型 OAM（Open Application Model）。

2019 年 10 月，阿里巴巴宣布联合微软共同推出开放应用模型项目（Open Application Model - OAM）。

所谓“应用模型”，其实是一个专门用来对云原生应用本身和它所需运维能力进行定义与描述的标准开源规范。所以对于 Kubernetes 来说，OAM 即是一个标准的“应用定义”项目（类比已经不再活跃的 Kubernetes Application CRD 项目），同时也是一个专注于封装、组织和管理 Kubernetes 中各种“运维能力”、以及连接“运维能力”与“应用”的平台层项目。

在 OAM 中，一个应用程序包含三个核心理念：第一个核心理念是组成应用程序的服务组件（Component），它包含微服务、数据库、云服务等；第二个核心理念是描述应用程序运维特征（Trait）的集合，例如，弹性伸缩和 Ingress 等功能。它们对应用程序的运行至关重要，但在不同环境中其实现方式各不相同；最后，为了将这些描述转化为具体的应用实例，运维人员使用应用配置（Application Configuration）来组合组件和相应的特征，以构建可部署的应用交付实例。

如上图所示，我们可以看到开发人员定义了组件 (Component) 来描述服务单元。然后运维人员定义运维特征 (Trait)，并将其附加到前面的组件上，最后构成 OAM 可交付物 -- ApplicationConfiguration。在图中最下方，底层的基础设施资源将通过 OAM 平台呈现。

那么 OAM 如何解决上述三个 Kuberntes API 的问题？首先，OAM 隐藏了底层基础架构细节（例如，是云还是物联网），专注于应用层抽象，提供以应用为中心的资源模型。其次，OAM 划分了应用交付路径上的开发、运维、基础架构三种角色，分离了关注点，让流程更加清晰和易于管理。第三，K8s 定义了基础架构的可移植抽象，而 OAM 站在 K8s 的肩膀上，提供了可移植的应用层抽象，让同一个应用可以跨平台运行。

OAM 还定义了一组核心工作负载/运维特征/应用范畴，作为应用程序交付平台的基石。并且，这些核心规范有一个开源实现 -- Crossplane。Crossplane 提供了让用户扩展其功能的机制。例如 Crossplane core 提供的 ContainerizedWorkload，在容器中运行应用程序并管理应用程序的生命周期。此外，我们还可以添加更多工作负载（例如 FaaS）以运行无服务器功能，或者添加运维特性（例如 CronHPA）来定义 CronJob 类型的 HPA 策略。OAM 以标准的声明方式在单个平台中管理应用交付能力和流程。当模块化的 Workload 和 Trait 越来越多，就会形成组件市场。而 OAM 就像是这个组件市场的管理者，处理组件之间的关系，把许多组件集成起来变成一个产品交付给用户。OAM 加持下的 PaaS，可以像乐高积木一样灵活组装底层能力、运维特征、以及开发组件。使得应用管理变得统一，功能却更加强大！