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