![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/63e8b648a94c45eb98e003daecf22e0c.png)

作者 | 張磊  阿里雲高階技術專家、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](https://github.com/crossplane/oam-kubernetes-runtime)
- **Crossplane 專案**：[https://github.com/crossplane/crossplane](https://github.com/crossplane/crossplane)

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

**OAM 專案**：[https://github.com/oam-dev/spec](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（水平自動擴充套件策略）：

![1.png](https://ucc.alicdn.com/pic/developer-ecology/bc8de0b8fa634bc3a6f657e443bee269.png)

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

![2.png](https://ucc.alicdn.com/pic/developer-ecology/6956a3133b6a42da906a40afd8b5489a.png)

自發布 6 個月以來，OAM 模型正在迅速成為了阿里和微軟內部進行應用定義的事實標準，並且已經成為了阿里雲企業級分散式應用服務 EDAS 等雲端應用管理產品的核心架構。在 2020 年 4 月，國外知名技術媒體 TheNewStack 提出了一個[《為什麼 Kubernetes 時代的應用如此與眾不同》](https://thenewstack.io/why-apps-are-fundamentally-different-in-the-kubernetes-era/)的疑問，引發了巨大的反響。TheNewStack 在文中把 OAM 稱作“Cloud 2.0 時代的應用定義模型”，並在最後講到：

> “OAM 的核心思想是，業務研發人員的工作以從編寫原始碼開始，到構建完容器映象結束。而應用運維人員或者應用管理平臺會負責將這個應用所需的所有元件配置和部署為一個完整的應用程式。而我們已經能夠看到，在以 Kubernetes 為代表的 Cloud 2.0 時代，一個現代化應用程式是由許多物件組成的，其中一些物件已經超出了業務研發人員的認知範圍。 這可能是網際網路歷史上第一次研發人員不再完全控制自己開發製品的完整生命週期。”

# 解讀：OAM Kubernetes 核心依賴庫

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

所以在本次釋出中，三方工程師使用 Go 語言開發了一個 OAM Kubernetes 核心依賴庫。這個專案的名字叫做 [oam-kubernetes-runtime](https://github.com/crossplane/oam-kubernetes-runtime) ，它的主要功能包括：

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

2. **可漂移的 Workload/Trait 能力**：基於這個依賴庫構建的 OAM 平臺，上面新增的所有 Workload 和 Trait，都可以複用和漂移到其他同樣基於該依賴庫的平臺，像外掛一樣可以輕鬆插拔，不需要做程式碼的變動。

3. **通用邏輯內建**：所有公共的邏輯，如依賴管理等，也將內建到這個依賴庫中，使得大家使用 OAM 基於 K8s 構建以“應用為中心”的管理平臺更加容易。

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

![3.png](https://ucc.alicdn.com/pic/developer-ecology/48c5aba5505443ea8f652cc93e1dc3ad.png)

在這樣的平臺中，平臺構建者可以基於 OAM 模組化新增 Workload 和 Trait，而這些模組也可以在不同的 OAM 平臺複用。比如，Workload 可以包括函式、容器、雲資源、虛擬機器等多種不同形態的工作負載；Trait 則可以包含流量管理、釋出策略、彈性策略、可觀測性策略等多種不同的運維能力。最終，平臺本身可以透過不同 Workload 和 Trait 組合，來對終端使用者提供差異化的場景。

[oam-kubernetes-runtime](https://github.com/crossplane/oam-kubernetes-runtime) 使用起來非常便利，可以直接按照[樣例程式碼](https://github.com/crossplane/oam-kubernetes-runtime/blob/master/examples/containerized-workload/main.go)中所描述的那樣，透過一個 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 的不二之選。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/ca8dfd60785549aabacefc82a0870028.png)

## 功能二：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 ](https://en.wikipedia.org/wiki/Duck_typing)（鴨子型別）的機制，在 Trait 物件上自動記錄與之繫結的 Workload 關係，從而實現了工作負載（Workload）和運維能力（Trait）之間的雙向記錄關係：

1. 給定任何一工作負載（Workload） ，系統可以直接獲取到同它繫結的所有運維能力（Trait）；

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

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

除此之外，OAM 社群還 Kubernetes 核心依賴庫中目前還有幾個非常重要的基礎功能同大家見面，包括：

- [Component 版本管理](https://github.com/crossplane/oam-kubernetes-runtime/pull/29)：對於任何一次 Component 的變更，OAM 平臺都可以記錄下來它對於的變更歷史，從而允許運維透過 Trait 來進行回滾、藍綠髮布等運維操作。

- [Component 間依賴關係與引數傳遞](https://github.com/crossplane/oam-kubernetes-runtime/pull/24)：該功能將解決大家亟需的元件間依賴問題，包括 Component 之間的依賴和傳輸傳遞，以及 Trait 與 Component 之間的依賴和引數傳遞。

- [Component 運維策略](https://github.com/crossplane/oam-kubernetes-runtime/pull/33)：該功能將允許研發在 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 生態中上線更加豐富的應用運維能力，共同建立一個專注於標準應用程式與基礎設施管理的開放社群。

> “[阿里巴巴雲原生](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247491076&idx=1&sn=7f451ab123ac782ef3b5a14009ccc0dc&chksm=fae515cbcd929cdd7b2e3c807358dd59f0615e5ecca631df8932cda86b88c302447e07843d9b&token=1970015759&lang=zh_CN#rd)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

阿里雲攜手微軟與 Crossplane 社群釋出 OAM Kubernetes 標準實現與核心依賴庫

相關文章