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

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

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

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

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

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

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

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

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

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

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

简而言之，Kubernetes作为一个面向基础设施工程师的系统级项目，主要负责提供松耦合的基础设施语义，这就使得用户学习和操作KubernetesYAML文件的时候，往往会感觉这些文件里的
转载请注明原文网址：http://www.coolofsoul.com/phpkf/phpkf/24331.html