作者 |?張磊? 阿里云高級技術專家、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 時代，一個現代化應用程序是由許多對象組成的，其中一些對象已經超出了業務研發人員的認知范圍。 這可能是互聯網歷史上第一次研發人員不再完全控制自己開發制品的完整生命周期?！?/p>

解讀：OAM Kubernetes 核心依賴庫

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

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

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

可漂移的 Workload/Trait 能力：基于這個依賴庫構建的 OAM 平臺，上面新增的所有 Workload 和 Trait，都可以復用和漂移到其他同樣基于該依賴庫的平臺，像插件一樣可以輕松插拔，不需要做代碼的變動。

通用邏輯內置：所有公共的邏輯，如依賴管理等，也將內置到這個依賴庫中，使得大家使用 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）之間的雙向記錄關系：

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

給定任何一個運維能力（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 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的公眾號?！?/p>

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的阿里云发布OAMKubernetes标准实现与核心依赖库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。