阿里云和微软共同开源的 OAM 对 Kubernetes 开发人员意味着什么？

上周，微软和阿里巴巴共同推出了开放应用模型(OAM)，用于定义部署在任何地方的应用模型的一种规范。Rudr是Microsoft基于Kubernetes环境的OAM标准实现。

我用了一个周末来了解OAM试图解决的问题，为此我还以Rudr为基础重构了一些我喜欢的基础微服务的应用程序。本文和以下教程将帮助普通的Kubernetes用户了解OAM背后的动机。

众所周知，Kubernetes是一个复杂的平台，包含许多活动组件。在编排和部署简单的两层Web应用程序时，需要涉及到创建Storage Classes，PVC，PV，Secret，ConfigMap，Service，Deployment和 Ingress。在实际生产部署中还需要健全的日志收集，监控告警，安全性，高可用性和可扩容性，我们将用到StatefulSet(有状态应用)，网络策略，RBAC，准入控制，Pod横向自动伸缩等知识。

对于从传统IT环境过渡的开发工程师和运维工程师，Kubernetes强劲的发展势头让人感到害怕。甚至一些熟悉容器化的DevOps专业人员都发现想要完全理解Kubernetes也是个很棘手的事情。

当转换为可部署的文件时，一个简单的两层Web应用程序可能具有十几个YAML文件，里面包含了这个应用程序针对于每个对象的定义描述。

Kubernetes的核心设计原则之一是对象的可解耦性。例如一个服务可以独立于Pod而存在，创建一个PV无需任何使用者，还可以配置一个无需任何后端来处理请求的Ingress。基于一组标签，注释和选择器，这些特点在运行时可以拼凑在一起共同使用。一个服务会将请求转发到符合条件的一个或多个Pod上。Ingress将流量路由到某个服务也是相同的用法。

Kubernetes中的每个对象都是自我治理并且完全独立的。尽管这种设计使Kubernetes具有极高的可扩展性，但其缺点是缺乏应用程序上下文关系。Kubernetes中的一个应用程序是一系列协同工作的自治对象的集合。当转换为可部署的文件时，一个简单的两层Web应用程序可能具有十几个YAML文件，里面包含了这个应用程序针对于每个对象的定义描述。在单一环境下管理和维护这些编排文件是与Kubernetes接触时面临的最大挑战。

Helm工具想要通过图表的概念来解决这个问题。但是即使这样，你往往还是在部署后丢失上下文关系。毕竟Helm只是应用程序运行所需的多个Kubernetes对象定义的集合编排文件生成工具。

Kubernetes的其他挑战之一是开发人员和运维人员之间有个很模糊的界限。为了有效利用平台，开发人员需要对运行时环境有一定的了解。他们需要了解ConfigMap如何对Pod中包装的容器可见。他们需要知道初始化代码的哪一部分应打包为Init容器。运维人员负责确保正确的命名规则来保证服务发现的正常工作。他们需要知道需要传递给Pod的所有环境变量。运维人员应根据应用程序的特性来决定将容器部署为ReplicationController，DaemonSet还是StatefulSet。他们需要在生产环境部署的时候，选择使用ClusterIP还是NodePort。

如上所述，开发人员期望熟悉运行时程序需要哪些必要的决策，并且运维人员应了解软件设计方面的知识。OAM想要通过以下方法解决这些存在的问题：

• 将应用程序上下文带入微服务部署
• 在开发人员和运维人员之间明确关注点
• 与运行时无关的应用程序模型

从更高的层次上来说，OAM是用于定义微服务或一组属于应用程序的微服务组件的规范。每个组件都有一个或多个工作节点，它们可以作为一个服务，或者是个消费者，或者是个需要完成的任务。每个工作节点之间可能具有关联的配置和特征。这些配置转换为传递给工作节点的参数，这些特性会影响组件的运行环境，同一类组件的集合属于一个应用程序。

OAM的核心前提是，开发人员的工作以从源代码在构建容器镜像的时候结束，而运维人员负责的工作正好从此处开始。Ops团队将负责为单个应用程序的一组容器镜像进行配置和部署。

OAM中的组件意在使开发人员能够以与基础结构无关的格式声明，来区分执行单元的操作特性。组件定义了在基础系统结构中的CPU，GPU，内存和磁盘需求。

组件中的每个工作节点类型如下：

配置通常在处理后以参数的形式传递给工作节点。例如在配置中定义了发送到应用程序服务工作节点的连接数据库的字符串。

这些特性定义了工作节点的运行时行为，从而定义了一个应用程序。Rudr就是OAM的参考实现的，并有以下特征：

如果我们仔细观察Workload和Trait的概念描述，它们可以轻松将这些概念对应到到Kubernetes。服务本质上是Deployment，而Singleton服务是具有一个replica的Deployment。它们都要使用ClusterIP或NodePort。Worker和单独的Worker是没有关联服务的Pods。任务是一个可并行化的Kubernetes Job，而单个任务是个单次运行的Job。

同样这些特性也能对应到到Kubernetes的自动扩容，Ingress，Deployment和PVC等概念。

因此使用OAM和Rudr，开发人员可以提交代码并构建可转换为工作节点的容器镜像。运维人通过这些组件的特性进行配置定义，将其组成工作节点。

从技术上讲，OAM这一规范可以适用于虚拟机基础设施平台（IaaS），PaaS和容器管理平台（CaaS）。OAM的每个构建模块都可以映射到相应的环境。就是说OAM定义的YAML文件可以在没有任何修改的情况下部署在任何环境中。

在本系列的下一篇文章中，我将带你逐步了解Rudr的端到端教程，其中展示了以Node.js Web应用程序部署组件，配置其特性所涉及的工作流程。敬请关注~

作者|Janakiram MSV
翻译|Big dimple
原文链接 https://thenewstack.io/what-does-the-open-application-model-oam-and-rudr-mean-for-kubernetes-developers/ 已获原作者授权翻译转载

“ 阿里巴巴云原生微信公众号（ID：Alicloudnative）关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术公众号。”