阿里雲和微軟共同開源的 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等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。」