上周，微軟和阿里巴巴共同推出了開放應用模型(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等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的技術公眾號，”
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/57248.html
標籤：其他
上一篇：論自信得影響