Cloud 2.0 和 OAM Kubernetes 核心依赖库

OAM - Open Application Model

“Cloud 2.0”时代的应用定义模型

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

实际上，Kubernetes 带来的云原生技术革命，在于实现了基础设施层的标准化和抽象，但这一层抽象距离业务研发与运维还是太过遥远了。一个最典型的例子，直到今天，Kubernetes 里面始终都没有“应用”这个概念，它提供的是更细粒度的“工作负载”原语，比如 Deployment 或者 DaemonSet。而在实际环境中，一个应用往往是由一系列独立组件的组合，比如一个“PHP 应用容器”和一个“数据库实例”组成的电商网站；一个“参数服务节点”和一个“工作节点”组成的机器学习训练任务；一个由“Deployment + StatefulSet + HPA + Service + Ingress”组成的 Kubernetes 应用。

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

与此同时，OAM 模型依据“关注点分离”的思想，对上述应用的组成部分进行了分类。其中，应用研发所关注的部分被称作“Component”，应用运维所关注的运维策略等被称作“Traits” 和 “Scope”，如下所示：

OAM Kubernetes 核心依赖库

社区在落地 OAM 模型的过程中，提出了很多关于 OAM 统一实现库的诉求。一方面，一个统一的实现库能够更好的对规范进行诠释，增强复用性；另一方面，大量共性需求比如依赖管理、参数传递、冲突管理、编排等，也可以在这个核心依赖库构建。

所以在本次发布中，三方工程师使用 Go 语言开发了一个 OAM Kubernetes 核心依赖库。这个项目的名字叫做 oam-kubernetes-runtime ，它的主要功能包括：

1. 稳定且统一的 OAM 内核：所有基于 OAM 的应用交付平台的构建者都将基于这个依赖库开始构建，OAM 内核将会是统一的。同时该依赖库也由三方的顶级工程师共同维护，确保其具备生产级的稳定性。
2. 可漂移的 Workload/Trait 能力：基于这个依赖库构建的 OAM 平台，上面新增的所有 Workload 和 Trait，都可以复用和漂移到其他同样基于该依赖库的平台，像插件一样可以轻松插拔，不需要做代码的变动。
3. 通用逻辑内置：所有公共的逻辑，如依赖管理等，也将内置到这个依赖库中，使得大家使用 OAM 基于 K8s 构建以“应用为中心”的管理平台更加容易。

而 OAM 核心依赖库最大的使用场景，就是构建开放、用户友好、标准化的应用管理平台。这样一个管理平台的核心架构如下图所示。