Kubernetes資源編排系列之五: OAM篇
作者 雪堯(郭耀星) 炯思(鍾炯恩)
前文我們提到了 Helm / Kustomize / CRD+Operator 這些方式，都可以在各自的領域很好的承載一個組件 (Component) 的概念。但是都沒有解決一個完整的面向業務場景的應用 (Application) 的問題。
OAM (Open Application Model) 是 2019 年阿里雲與微軟聯合推出的開放應用模型。下面我們來看這個模型是什麼。
1. OAM是什麼
在應用部署上，大家或多或少有過一些這樣的經歷：面對複雜的K8S YAML手足無措，有些字段能理解含義，有些字段光從字面上又無法確認影響，有些已經確認的字段一提交修改就被提示報錯，說這個字段運行態不能動。如果說k8s內置資源的字段基本都還有跡可循的話，通過CRD+Operator創建的自定義資源的很多字段都會放飛自我，連文檔都找不到。那麼這些YAML能不能做得像樂高積木一樣呢？既能自由地插拔創造發揮，又有一些限制約束，使得創意不會太劍走偏鋒，讓後續使用者也能快速理解其中的作用和價值。
於是 OAM 應運而生。OAM（Open Application Model）是一個標準的、基礎設施無關的跨雲應用部署模型。有以下幾個特性：
- 應用為先。一個應用的交付與部署應該是自包含的，其中的各類操作行為應該作為應用定義的一部分，這些內容與實際基礎設施無關。
- 清晰和可擴展性。定義一套開放標準，可以模塊化整個應用交付流程，根據個人需要將這些模塊自由組裝，達成自己想要的結果。
- 雲服務供應商無關。定義的開放標準應該是一套更高級別的抽象，可以跨本地集群、跨雲服務供應商，不會被鎖定到任何一個廠商的底座。
其實上面這些點寫幾個Operator也都能解決，但OAM的亮點在於他並不是一個程序的實現，他是一個文字定義的標準，大家只要依照這個標準去落地，就能把已有的東西整合起來發揮作用。下面來看一下OAM模型抽象：
如上圖所示，OAM將一個模型分成了Application(應用)、Component(組件)、Trait(運維特徵) 這樣幾層，於是相關角色的關注點也都被巧妙地分解開來，各角色只要聚焦於自己的內容就能一起協作完成一個複雜的應用工程，如下圖所示：
* 應用開發人員：負責組件 Component 的定義及研發。
-
應用運維人員：
- 定義適用於不同 Workload 的運維屬性 Trait 和管理 Component 的 ApplicationScope (or Policy)
- 將應用開發人員定義好的 Component 與運維屬性 Trait 綁定在一起，輔以 Policy + Workflow，生成 Application，提交到 Runtime 實現，維護應用程序的生命周期
-
基礎設施運維人員：提供不同的 Workload 類型映射到實際的基礎設施。
OAM 通過一系列概念的定義，完成了對一個應用的抽象，實現了角色職責的分離，將應用交付這件事情與底座解耦，使得跨雲快速交付應用成為可能。開發同學也不再關心底座實現細節，只關心自己的應用模型即可。OAM 的誕生，旨在定義雲原生應用標準。
OAM 只是一紙協議，並沒有應用/組件管理的能力，但它卻定義了一個良好的管理應用/組件的系統應該是什麼樣子，通過一套統一的概念收攏社區中分散在各處的垂直能力工具。下面我們就來講講SREWorks如何基於這個協議構建完整的雲原生運維生態。
2. SREWorks的OAM落地實踐
SREWorks作為阿里大數據運維平台，在設計之初，雲原生應用管理在滿足內部業務需求時候，遇到了這樣一些問題和挑戰：
- 需要應用異地多活，避免單 Region 故障。
- 需要環境分離，區分開發測試與生產環境。
- 需要一定的集群擴展性，突破單一集群容量上限。
- 需要多雲部署，避免受限於單一雲底座，或降低成本。
- 開發者花費了太多的時間在基礎設施的細節中。機器從哪來，網絡環境怎麼樣，中間件資源/DNS/負載均衡怎麼生成，服務怎麼適配到各種底座等等。或者更進一步，每個開發者都是 YAML 工程師，哪怕都是 K8S，但每個底座讓你提交的 YAML 都不一樣。
- 可擴展性低。有越來越多的平台 or 底座在嘗試去支撐各種類型需求的業務，但一般來說，應用本身對於平台的訴求會很快超越平台的能力。
- 雲服務供應商綁定。當選擇了一個固定的底座後，應用交付的方方面面將會打上這個底座的烙印，當想嘗試轉到另一個底座的時候難於登天。
當SREWorks-Appmanager基於OAM實現了底層引擎，驅動各個服務的開發與交付流程之後，這些問題基本都有了答案，讓我們來看看這些問題是如何被解決的。
應用模塊插拔
如上圖的YAML所示：
- 通過運維能力(trait)注入進行運維能力的增強，使部署者不用關注太多底座基礎設施的細節。
- 通過各種組件(compent)的插拔和參數變量(parameterValues)的定製來滿足應用的功能需求。
- 通過工作(workflow)和策略(policy)來定製部署策略，滿足灰度發佈、金絲雀發佈等多樣的發佈策略。
應用插件機制
上面提到了各種組件(compent)和運維能力(trait)，那麼這些能力是從哪裡來的呢？這些也是用插件機制增強出來的，可以看下圖：
在Appmanager中預先定好了各種能力的接口(interface)，一個插件只要實現這些接口(interface)就能夠將能力增強到Appmanager中。用戶可以基於這個機制來滿足各種能力需求，比如將一個Flink服務製作成一個組件(compent)，用戶只要寥寥幾行在YAML中加上這個組件，就能在自己應用中瞬間就有了流計算以及其管理能力。
應用組件Addon體系
在將一個應用做組件化拆解的時候，我們會遇到一個問題，像MySQL、Redis這種要如何拆。拆成一個普通的組件(compent)的話，有些資源少的場景，每個應用分配一個獨享MySQL實例會導致資源不夠分；拆成一個運維特徵(trait)的話，每次申請一個實例的邏輯太重，不太符合一個特徵的輕量級行為。所以我們將這類組件定義為addon。
應用組件構建
在OAM模型定義中沒有包含構建，在Appmanager中，我們對此進行了增強，將應用的生命周期延展到構建環節，用戶可以基於源代碼直接構建出組件，進而組成一個完整應用模型。下面是構建過程的拓撲：
總結一下，SREWorks中基於OAM的Appmanager基本滿足了如下的核心訴求：
- 構建：易於獲取且一致的開發、測試環境；易於發現和使用的 API
- 交付：安全、可灰度的發佈環境；可回滾的版本管理能力
- 運行：異常行為可觀測；運行穩定且能夠自愈
後續文章我們會分享更多的Kubernetes科普文章，均會發佈在我們的公眾號「阿里智能運維」上，請大家持續關注～也歡迎大家在公眾號後台留言想了解的內容和感興趣的相關話題，與SREWorks團隊進行交流。
Github地址：//github.com/alibaba/sreworks
文章參考
- //developer.aliyun.com/article/741494 《OAM 深入解讀(一)：OAM 為雲原生應用帶來哪些價值？》
