Kubernetes資源編排系列之五: OAM篇

語言: CN / TW / HK

作者 雪堯(郭耀星) 炯思(鍾炯恩)

前文我們提到了 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地址:https://github.com/alibaba/sreworks

文章參考 https://developer.aliyun.com/article/741494 《OAM 深入解讀(一):OAM 為雲原生應用帶來哪些價值?》