![阿里云和微软共同开源的 OAM 对 Kubernetes 开发人员意味着什么？[kubernetes最新资讯]](/upload/image/2023/08/10/1-1.png)
上周，微软和阿里巴巴共同推出了开放应用模型( 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 也是个很棘手的事情。
![阿里云和微软共同开源的 OAM 对 Kubernetes 开发人员意味着什么？[kubernetes最新资讯]](/upload/image/2023/08/10/2-1.png)
当转换为可部署的文件时，一个简单的两层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 ，内存和磁盘需求。
组件中的每个工作节点类型如下：
![阿里云和微软共同开源的 OAM 对 Kubernetes 开发人员意味着什么？[kubernetes最新资讯]](/upload/image/2023/08/10/3-1.png)
配置通常在处理后以参数的形式传递给工作节点。例如在配置中定义了发送到应用程序服务工作节点的连接数据库的字符串。
这些特性定义了工作节点的运行时行为，从而定义了一个应用程序。 Rudr 就是 OAM 的参考实现的，并有以下特征：
![阿里云和微软共同开源的 OAM 对 Kubernetes 开发人员意味着什么？[kubernetes最新资讯]](/upload/image/2023/08/10/4-1.png)
如果我们仔细观察 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等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术公众号。”
