阿里云和微软共同开源的 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/ 已获原做者受权翻译转载

“ 阿里巴巴云×××icloudnative×××erverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发×××