上周，微軟和阿里巴巴共同推出了開放應用模型(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等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的技術公眾號。”

總結

以上是生活随笔為你收集整理的阿里云和微软共同开源的 OAM 对 Kubernetes 开发人员意味着什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。