阿里雲攜手微軟與 Crossplane 社區發佈 OAM Kubernetes 標準實現與核心依賴庫

做者 | 張磊  阿里雲高級技術專家、CNCF 官方大使，CNCF 應用交付領域 co-chair，Kubernetes 項目資深維護者

美國西部時間 2020 年 5 月 27 日，阿里雲和微軟雲共同宣佈，Open Application Model （OAM） 社區攜手知名混合雲管理項目 Crossplane，聯合發佈了 OAM  在 Kubernetes 平臺上的標準實現與核心依賴庫項目。新版的 OAM 核心依賴庫以 Go 語言編寫，由來自阿里、微軟和 Crossplane 三方的工程師共同維護，可以以 Kubernetes 插件或者 Go 語言依賴庫的方式被社區所使用。在內置了 OAM 核心依賴庫以後，Crossplane 項目也實現了「華麗升級」，從原先的混合雲管理項目一躍成爲了一個可以面向全部雲環境、提供「應用 + 雲服務」一站式管理與交付體驗的 OAM 標準實現平臺。

• OAM 核心依賴庫項目：https://github.com/crossplane/oam-kubernetes-runtime
• Crossplane 項目：https://github.com/crossplane/crossplane

OAM 是阿里雲與微軟雲在 2019 年底聯合推出的標準化雲原生應用管理模型。相比於傳統 PaaS 封閉、不能同「以 Operator 爲基礎的雲原生生態」銜接的現狀，基於 OAM 和 Kubernetes 構建的現代雲原生應用管理平臺，本質上是一個「以應用爲中心」的  Kubernetes ，保證了這個應用平臺在可以無縫接入整個雲原生生態。同時，OAM 能夠進一步屏蔽掉容器基礎設施的複雜性和差別性，爲平臺的使用者帶來低心智負擔的、標準化的、一致的應用管理與交付體驗。

OAM 項目：https://github.com/oam-dev/spec

「Cloud 2.0」時代的應用定義模型

應用容器技術自誕生開始，就以「完全改變了軟件打包與分發方式」的魅力迅速征服了幾乎全部的雲廠商與數據中心。 不過，軟件打包與分發方式的革新，並無可以讓軟件自己的定義與描述發生本質的變化，基於 K8s 的應用管理體驗，也沒有讓業務研發與運維的工做變得更簡單。

實際上，Kubernetes 帶來的雲原生技術革命，在於實現了基礎設施層的標準化和抽象，但這一層抽象距離業務研發與運維仍是太過遙遠了。一個最典型的例子，直到今天，Kubernetes 裏面始終都沒有「應用」這個概念，它提供的是更細粒度的「工做負載」原語，好比 Deployment 或者 DaemonSet。而在實際環境中，一個應用每每是由一系列獨立組件的組合，好比一個「PHP 應用容器」和一個「數據庫實例」組成的電商網站；一個「參數服務節點」和一個「工做節點」組成的機器學習訓練任務；一個由「Deployment + StatefulSet + HPA + Service + Ingress」組成的** Kubernetes 應用**。

而 OAM 項目，是一個基於 Kubernetes API 資源模型（Kubernetes Resource Model）的標準應用定義規範。在 OAM 中，它強調一個現代應用是多個組件的集合，而非一個簡單的工做負載或者 K8s Operator。因此在 OAM 的語境中，一個 PHP 容器和它所依賴的數據庫，以及它所須要使用的各類雲服務，都是一個「電商網站」應用的組成部分。更進一步的，OAM 把這個應用所需的「運維策略」也認爲是一個應用的一部分，好比這個 PHP 容器所需的 HPA（水平自動擴展策略）：

與此同時，OAM 模型依據「關注點分離」的思想，對上述應用的組成部分進行了分類。其中，應用研發所關注的部分被稱做「Component」，應用運維所關注的運維策略等被稱做「Traits」 和 「Scope」，以下所示：

自發布 6 個月以來，OAM 模型正在迅速成爲了阿里和微軟內部進行應用定義的事實標準，而且已經成爲了阿里雲企業級分佈式應用服務 EDAS 等雲端應用管理產品的核心架構。在 2020 年 4 月，國外知名技術媒體 TheNewStack 提出了一個《爲何 Kubernetes 時代的應用如此不同凡響》的疑問，引起了巨大的反響。TheNewStack 在文中把 OAM 稱做「Cloud 2.0 時代的應用定義模型」，並在最後講到：

「OAM 的核心思想是，業務研發人員的工做以從編寫源代碼開始，到構建完容器鏡像結束。而應用運維人員或者應用管理平臺會負責將這個應用所需的全部組件配置和部署爲一個完整的應用程序。而咱們已經可以看到，在以 Kubernetes 爲表明的 Cloud 2.0 時代，一個現代化應用程序是由許多對象組成的，其中一些對象已經超出了業務研發人員的認知範圍。 這多是互聯網歷史上第一次研發人員再也不徹底控制本身開發製品的完整生命週期。」

解讀：OAM Kubernetes 核心依賴庫

社區在落地 OAM 模型的過程當中，提出了不少關於 OAM 統一實現庫的訴求。一方面，一個統一的實現庫可以更好的對規範進行詮釋，加強複用性；另外一方面，大量共性需求好比依賴管理、參數傳遞、衝突管理、編排等，也能夠在這個核心依賴庫構建。

因此在本次發佈中，三方工程師使用 Go 語言開發了一個 OAM Kubernetes 核心依賴庫。這個項目的名字叫作 oam-kubernetes-runtime ，它的主要功能包括：

1. 穩定且統一的 OAM 內核：全部基於 OAM 的應用交付平臺的構建者都將基於這個依賴庫開始構建，OAM 內核將會是統一的。同時該依賴庫也由三方的頂級工程師共同維護，確保其具有生產級的穩定性。

2. 可漂移的 Workload/Trait 能力：基於這個依賴庫構建的 OAM 平臺，上面新增的全部 Workload 和 Trait，均可以複用和漂移到其餘一樣基於該依賴庫的平臺，像插件同樣能夠輕鬆插拔，不須要作代碼的變更。

3. 通用邏輯內置：全部公共的邏輯，如依賴管理等，也將內置到這個依賴庫中，使得你們使用 OAM 基於 K8s 構建以「應用爲中心」的管理平臺更加容易。

**而 OAM 核心依賴庫最大的使用場景，就是構建開放、用戶友好、標準化的應用管理平臺。**這樣一個管理平臺的核心架構以下圖所示。

在這樣的平臺中，平臺構建者能夠基於 OAM 模塊化添加 Workload 和 Trait，而這些模塊也能夠在不一樣的 OAM 平臺複用。好比，Workload 能夠包括函數、容器、雲資源、虛擬機等多種不一樣形態的工做負載；Trait 則能夠包含流量管理、發佈策略、彈性策略、可觀測性策略等多種不一樣的運維能力。最終，平臺自己能夠經過不一樣 Workload 和 Trait 組合，來對最終用戶提供差別化的場景。

oam-kubernetes-runtime 使用起來很是便利，能夠直接按照樣例代碼中所描述的那樣，經過一個 main 函數把這個依賴庫運行起來。OAM Kubernetes 核心依賴庫自己是一個 Kubernetes Controller ，經過響應 ApplicationConfiguration 的變化來建立和管理 Workload 和 Trait。具體來講，OAM Kubernetes 核心依賴庫會提供兩個很是重要的功能：

功能一：無縫對接現有 K8s API 資源 

oam-kubernetes-runtime 支持將任何現有的 CRD 被聲明爲 Workload 或者 Trait 而不須要作任何改動。固然，這也意味着任何 K8s 原生的 API 資源也能夠被聲明爲 Workload 或者 Trait。經過這種設計，現有 Kubernetes 集羣裏的全部能力進行 OAM 化變得就」易如反掌「了。這也使得 OAM 成爲告終構化管理當前集羣中的各類 Operator 的不二之選。

功能二：Workload 與 Trait 標準化交互機制

前面的例子告訴咱們，OAM 能夠模塊式的接入、部署和管理任何 Kubernetes 工做負載和運維能力。而這些工做負載和運維能力之間的交互，則須要經過第二個功能來實現標準化和統一化。

這個交互關係在 Kubernetes 裏很是常見，好比一個 Deployment 和 HPA（自動水平擴展控制器） 的協做關係。這裏 Deployment 在 OAM 模型中就屬於 Workload，而 HPA 則屬於 Trait。因此說在 OAM 當中，一個 ApplicationConfiguration 裏引用的 Workload 和 Trait 也必須經過協做的方式來操做具體的 k8s 資源。舉個例子，一個 HPA Trait 該如何去水平擴展上述 OpenFaaS 的 Function Workload 呢？這個協做關係就得依靠 OAM 插件來去管理了。

在 OAM Kubernetes 核心依賴庫中，它會經過一種叫作 DuckTyping （鴨子類型）的機制，在 Trait 對象上自動記錄與之綁定的 Workload 關係，從而實現了工做負載（Workload）和運維能力（Trait）之間的雙向記錄關係：

1. 給定任何一工做負載（Workload） ，系統能夠直接獲取到同它綁定的全部運維能力（Trait）；

2. 給定任何一個運維能力（Trait），系統能夠直接獲取到它所要做用於的全部工做負載（Workload）。

這種雙向記錄關係，對於在一個大規模的生產環境中保證運維能力的可管理性、可發現性和應用的穩定性，是相當重要的。

除此以外，OAM 社區還 Kubernetes 核心依賴庫中目前還有幾個很是重要的基礎功能同你們見面，包括：

• Component 版本管理：對於任何一次 Component 的變動，OAM 平臺均可以記錄下來它對於的變動歷史，從而容許運維經過 Trait 來進行回滾、藍綠髮布等運維操做。

• Component 間依賴關係與參數傳遞：該功能將解決你們亟需的組件間依賴問題，包括 Component 之間的依賴和傳輸傳遞，以及 Trait 與 Component 之間的依賴和參數傳遞。

• Component 運維策略：該功能將容許研發在 Component 中聲明對運維能力的訴求，指導運維人員或者系統給這個 Component 綁定和配置合理的運維能力。

OAM + Crossplane：定義雲原生應用的下一階段

可能你們會有這樣一個疑問，爲何這一次 OAM 會選擇 Crossplane 社區來做爲 OAM Kubernetes 核心依賴庫的合做團隊呢？

咱們知道，OAM 的主要思想是以 Kubernetes API 資源模型爲核心、以結構化和平臺無關的方式，對應用進行定義和管理。這裏的「應用」，既包括待運行的程序自己（好比一個容器），也包括它須要的全部其餘依賴（好比雲資源和運維能力的描述）。而若是你熟悉 Kubernetes 生態的話，就會知道這種經過 Kubernetes API 模型「定義一切」的思想，也正是 Crossplane 項目的設計理念。

只不過，做爲 Kubernetes 混合雲場景中的佼佼者，Crossplane 項目之前的關注點是以結構化和平臺無關的方式對雲服務進行定義和管理而已。而在通過 OAM 化以後，今天的 Crossplane 項目，已經成爲了 OAM 的標準實現，使用 OAM 做爲其應用定義的入口，而且直接經過 OAM Component 的方式來爲使用者暴露出平臺無關的雲服務定義。這樣，一個符合 OAM 規範的待運行程序、運維能力和它所依賴的雲服務，就能夠組成一個總體，在不一樣的平臺之間無縫漂移了。

這種平臺無關的應用定義範式，使得應用研發人員只須要經過 OAM 規範來描述他們的應用程序，那麼該應用程序就能夠在任何 Kubernetes 羣集或者 Serverless 應用平臺甚至邊緣環境上運行而無需對應用描述作任何修改。 這種體驗，一直是阿里雲和微軟雲在努力的構建「雲、邊、端」一致性體驗的核心思想。 而這次 OAM 與 Crossplane 的深度協做，也終於將標準應用定義和標準化的雲服務管理能力統一塊兒來，從而使「雲端應用交付」的故事真正成爲了現實。

在將來，這兩個社區將進一步緊密協做，在 OAM Kubernetes 標準實現中提供更好的 Component 和 Trait 可移植性、互操做性，在 OAM 生態中上線更加豐富的應用運維能力，共同創建一個專一於標準應用程序與基礎設施管理的開放社區。

「阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」