作者 |?Andy Shi（阿里云高級技術(shù)專家）、天元（阿里云技術(shù)專家）

今年 5 月，阿里云和微軟云共同宣布，Open Application Model （OAM） 社區(qū)攜手知名混合云管理項目 Crossplane 社區(qū)，聯(lián)合發(fā)布了 OAM 在 Kubernetes 平臺上的標(biāo)準(zhǔn)實現(xiàn)與核心依賴庫。本次合作達成后，OAM 社區(qū)成功的將標(biāo)準(zhǔn)應(yīng)用定義和標(biāo)準(zhǔn)化的云服務(wù)管理能力統(tǒng)一起來，邁出了實現(xiàn)真正意義上的無差別云端應(yīng)用交付的關(guān)鍵一步 。

去年 10 月 ，阿里云和微軟共同推出了?OAM?項目，旨在構(gòu)建圍繞 Kubernetes 的云原生應(yīng)用規(guī)范。OAM 描述了一個模型 —— 開發(fā)人員可以在其中定義應(yīng)用程序組件；應(yīng)用程序操作員負責(zé)創(chuàng)建這些組件的實例并為它們分配應(yīng)用程序配置；基礎(chǔ)架構(gòu)運營商負責(zé)定義、安裝和維護平臺上可用的基礎(chǔ)服務(wù)。

本次合作是阿里云、微軟與 Crossplane 社區(qū)的三方技術(shù)合作，主要圍繞 OAM 在 Kubernetes 上的標(biāo)準(zhǔn)實現(xiàn)以及 Crossplane 項目的 OAM 化展開。因為 Kubernetes 社區(qū)在落地 OAM 模型的過程中，提出了關(guān)于 OAM 標(biāo)準(zhǔn)實現(xiàn)的訴求。所以這次合作的一個重點，就是三方工程師使用 Go 語言開發(fā)了一個 OAM Kubernetes 核心依賴庫。這個項目的名字叫做 oam-kubernetes-runtime。OAM Kubernetes Runtime 將會成為 OAM 社區(qū)官方維護的基礎(chǔ)組件，目標(biāo)是在 Kubernetes 上提供穩(wěn)定且統(tǒng)一的 OAM 核心插件。

為進一步了解本次合作的細節(jié)以及 OAM 項目的現(xiàn)狀，阿里云高級技術(shù)專家 Andy Shi 以及阿里云技術(shù)專家孫健波（花名：天元）接受開源中國的專訪，共同探討了 OAM 項目存在的意義。

詳情戳：https://www.oschina.net/question/4487475_2317219

OAM 因何而生

我們知道，應(yīng)用容器技術(shù)自誕生開始，就以 “徹底改變了軟件打包與分發(fā)方式” 的魅力迅速征服了幾乎所有的云廠商與數(shù)據(jù)中心。不過，軟件打包與分發(fā)方式的革新，并沒有能夠讓軟件本身的定義與描述發(fā)生本質(zhì)的變化，基于 K8s 的應(yīng)用管理體驗，也沒有讓業(yè)務(wù)研發(fā)與運維的工作變得更簡單。

實際上，Kubernetes 帶來的云原生技術(shù)革命，在于實現(xiàn)了基礎(chǔ)設(shè)施層的標(biāo)準(zhǔn)化和抽象，但這一層抽象距離業(yè)務(wù)研發(fā)與運維還是太過遙遠了。一個最典型的例子，直到今天，Kubernetes 里面始終都沒有 “應(yīng)用” 這個概念，它提供的是更細粒度的 “工作負載” 原語，比如 Deployment 或者 DaemonSet。

而在實際環(huán)境中，一個應(yīng)用往往是由一系列獨立組件的組合，比如一個 “PHP 應(yīng)用容器” 和一個 “數(shù)據(jù)庫實例” 組成的電商網(wǎng)站；一個 “參數(shù)服務(wù)節(jié)點” 和一個 “工作節(jié)點” 組成的機器學(xué)習(xí)訓(xùn)練任務(wù)；一個由 “Deployment + StatefulSet + HPA + Service + Ingress” 組成的微服務(wù)應(yīng)用。

“應(yīng)用” 這個概念在 Kubernetes 項目中的缺失，既是一個有意而為之的設(shè)計，卻也造成了今天云原生應(yīng)用管理生態(tài)的極度碎片化和極高的學(xué)習(xí)門檻。如何通過標(biāo)準(zhǔn)化的方式去解決這個**?“Kubernetes 里到底什么是應(yīng)用”?**的問題，正是 OAM 項目發(fā)布的最初始動機。

有什么意義？

在 OAM 發(fā)布之前，云原生生態(tài)里其實并沒有一個叫做 “應(yīng)用” 的概念。哪怕在今天，全世界幾乎每一個在落地云原生的團隊，都有一個自己定義的 “應(yīng)用” 的概念，它們的抽象程度層次不齊，定義方式也豐富多樣，這就導(dǎo)致了所有圍繞著這些 “應(yīng)用” 構(gòu)建出來的系統(tǒng)，就成為了一個又一個的大煙囪。

對于整個云原生生態(tài)來說，這種應(yīng)用層的碎片化和煙囪化，其實對于整個生態(tài)演進是非常不利的。而今天的現(xiàn)狀也已經(jīng)證明了這一點，在 Kubernetes 逐漸標(biāo)準(zhǔn)化了基礎(chǔ)設(shè)施能力的接入方式之后，原本更加接近用戶、更加重要的應(yīng)用管理層，卻幾乎停滯了演進，在最近幾年里沒有提出任何一個創(chuàng)新性的思想出來。

應(yīng)用管理層停滯不前的結(jié)果，就是全世界的業(yè)務(wù)研發(fā)和運維一夜之間都被迫變成了 “容器專家”，一邊學(xué)習(xí)著根本不應(yīng)該是他們關(guān)心的各種 “基礎(chǔ)設(shè)施即數(shù)據(jù)（Infrastructure as Data）” 領(lǐng)域的概念（比如：聲明式 API，控制器等），一邊吐槽 Kubernetes 實在是太復(fù)雜了、設(shè)計太奇葩了。

簡而言之，Kubernetes 作為一個面向基礎(chǔ)設(shè)施工程師的系統(tǒng)級項目，主要負責(zé)提供松耦合的基礎(chǔ)設(shè)施語義，這就使得用戶學(xué)習(xí)和操作 Kubernetes YAML 文件的時候，往往會感覺這些文件里的關(guān)注點非常底層，學(xué)習(xí)門檻很高。

實際上，對于Kubernetes 真正的最終用戶比如業(yè)務(wù)研發(fā)人員和運維人員來說，他們并不想配置這些如此底層的資源信息，而是希望有更高維度的抽象。這就要求一個真正面向最終用戶側(cè)的應(yīng)用定義，需要能夠為業(yè)務(wù)研發(fā)和應(yīng)用運維人員提供各自視角的應(yīng)用定義原語。所以說，OAM 帶來的第一個改變，就是提供了一種大家都可以遵循的、標(biāo)準(zhǔn)化的方式來定義更高層級的應(yīng)用層抽象，并且把“關(guān)注點分離”作為這個定義模型的核心思想。

**而 OAM 帶來的第二個變化，則是為 Kubernetes 項目帶來了應(yīng)用定義，更確切地說，是對應(yīng)用本身和它所需運維能力進行定義與描述的標(biāo)準(zhǔn)開源規(guī)范。**站在 Kubernetes 項目的角度來講，OAM 是一個 Kubernetes 原生的標(biāo)準(zhǔn)的“應(yīng)用定義”項目，同時也是一個專注于封裝、組織和管理 Kubernetes 中各種“運維能力”、以及連接“運維能力”與“應(yīng)用”的平臺層框架。

詳細的說，OAM 基于 Kubernetes API 資源模型（Kubernetes Resource Model）來標(biāo)準(zhǔn)化應(yīng)用定義的規(guī)范，它強調(diào)一個現(xiàn)代應(yīng)用是多個組件的集合，而非一個簡單的工作負載或者 K8s Operator。所以在 OAM 的語境中，一個 PHP 容器和它所依賴的數(shù)據(jù)庫，以及它所需要使用的各種云服務(wù)，都是一個“電商網(wǎng)站”應(yīng)用的組成部分。更進一步的，OAM 把這個應(yīng)用所需的“運維策略”也認(rèn)為是一個應(yīng)用的一部分，比如這個 PHP 容器所需的 HPA（水平自動擴展策略）：

以 Crossplane 項目為例，它在本次合作中通過 OAM 升級之后得到了怎樣的變化呢？

“ 作為混合云管理領(lǐng)域中的佼佼者，Crossplane 的 OAM 化保證了今天任何一個符合 OAM 規(guī)范的待運行程序、運維能力和它所依賴的云服務(wù)，可以組成一個整體在混合云環(huán)境中無縫漂移。”

這種平臺無關(guān)的應(yīng)用定義范式，使得應(yīng)用研發(fā)人員只需要通過 OAM 規(guī)范來描述他們的應(yīng)用程序，那么該應(yīng)用程序就可以在任何 Kubernetes 群集或者 Serverless 應(yīng)用平臺甚至邊緣環(huán)境上運行，而無需對應(yīng)用描述做任何修改。本次合作中 Crossplane OAM 版的發(fā)布，則意味著 OAM 社區(qū)正在將標(biāo)準(zhǔn)應(yīng)用定義和標(biāo)準(zhǔn)化的云服務(wù)管理能力統(tǒng)一起來，從而實現(xiàn)真正的 “云端應(yīng)用交付” 。

OAM 如何發(fā)揮作用？

那么 OAM 在一個項目中是如何運作的呢？

據(jù)介紹，OAM 以原生插件的方式運行在 Kubernetes 當(dāng)中。OAM 強調(diào)整個模型是關(guān)注點分離的。即業(yè)務(wù)研發(fā)人員負責(zé)定義和維護組件 (Component) 來描述服務(wù)單元，而運維人員定義運維特征 (Trait)，并將其附加到前面的組件上，最后構(gòu)成 OAM 可交付物 ——ApplicationConfiguration。

這種設(shè)計是 OAM 在能夠無限接入 Kubernetes 各種能力的同時，保證給業(yè)務(wù)研發(fā)與運維人員提供最佳的使用體驗和最低的心智負擔(dān)的重要基礎(chǔ)。與此同時，基礎(chǔ)設(shè)施工程師可以隨時在 Kubernetes 中添加更多工作負載（例如 FaaS）以運行無服務(wù)器功能，或者添加運維特性（例如 CronHPA）來定義 CronJob 類型的 HPA 策略。OAM 以標(biāo)準(zhǔn)的聲明方式在整個平臺中管理應(yīng)用交付能力和流程，并且提供面向各個角色的 API 原語來表達各自的訴求，最后通過 Kubernetes 把這些訴求落實。

什么樣的項目需要 OAM？

實際上，幾乎所有基于 Kubernetes 的應(yīng)用管理平臺都對通過 OAM 來以標(biāo)準(zhǔn)化的方式去構(gòu)建自己的應(yīng)用模型有明確的訴求。另一方面，由于 OAM 是原生的 Kubernetes API 資源模型，這里的遷移過程難度很低，可以通過 API 對象灰度納管的方式逐步完成遷移操作（通過 OAM 對象逐步接管現(xiàn)有 Kubernetes 對象）。

而相比于傳統(tǒng) PaaS 封閉的、不能同 “以 Operator 為基礎(chǔ)的云原生生態(tài)” 銜接的現(xiàn)狀，基于 OAM 和 Kubernetes 構(gòu)建的現(xiàn)代云原生應(yīng)用管理平臺，本質(zhì)上是一個 “以應(yīng)用為中心” 的? Kubernetes ，保證了這個應(yīng)用平臺在能夠無縫接入整個云原生生態(tài)。同時，OAM 可以進一步屏蔽掉容器基礎(chǔ)設(shè)施的復(fù)雜性和差異性，為平臺的使用者帶來低心智負擔(dān)的、標(biāo)準(zhǔn)化的、一致的應(yīng)用管理與交付體驗。這就使得一個基于OAM 構(gòu)建的 Kubernetes 應(yīng)用平臺，首先能夠隱藏底層基礎(chǔ)設(shè)施的細節(jié)（例如，是云還是物聯(lián)網(wǎng)），專注于應(yīng)用層抽象，提供以應(yīng)用為中心的資源模型。

其次，OAM 劃分了應(yīng)用交付路徑上的開發(fā)、運維、基礎(chǔ)架構(gòu)三種角色，分離了關(guān)注點，讓流程更加清晰和易于管理。

第三，OAM 站在 K8s ?API 資源模型的肩膀之上，提供了可移植的應(yīng)用與基礎(chǔ)設(shè)施抽象，讓一個應(yīng)用描述可以完全不加修改的云、邊、端等任何環(huán)境下直接交付運行起來。

除此之外，OAM 還定義了一組核心工作負載/運維特征/應(yīng)用范疇，作為應(yīng)用程序交付平臺的基石。而平臺開發(fā)者也可以添加更多工作負載（例如 FaaS 或者任意云服務(wù)），或者添加運維特性（例如 CronHPA）來定義 CronJob 類型的 HPA 策略。OAM 以標(biāo)準(zhǔn)的聲明方式在整個平臺中管理應(yīng)用交付能力和流程。當(dāng)模塊化的 Workload 和 Trait 越來越多，就會形成組件市場。而 OAM 就像是這個組件市場的管理者，處理組件之間的關(guān)系，把許多組件集成起來變成一個產(chǎn)品交付給用戶。OAM 加持下的 Kubernetes 應(yīng)用管理平臺，可以像樂高積木一樣靈活組裝底層能力、運維特征、以及開發(fā)組件。使得應(yīng)用管理變得統(tǒng)一，功能卻更加強大。

OAM 社區(qū)現(xiàn)狀

談到 OAM 項目社區(qū)的現(xiàn)狀。“ 作為一個沒有同商業(yè)訴求綁定的中立開源社區(qū)，OAM 生態(tài)自成立以來保持著較高的活躍度和參與度，大量的社區(qū) Issue/PR貢獻都來自阿里和微軟之外的團隊比如 AWS、騰訊、字節(jié)跳動、諧云、青云、好雨云、第四范式等生態(tài)參與者。除了阿里和微軟本身以及基于 OAM 實現(xiàn)了內(nèi)部應(yīng)用管理架構(gòu)的統(tǒng)一和標(biāo)準(zhǔn)化之外，不少基于 OAM 的云服務(wù)比如阿里云 EDAS 也已經(jīng)上線。”

與此同時，OAM 技術(shù)體系也開始在很多大型社區(qū)用戶（比如 MasterCard 萬事達卡）中落地，同時也出現(xiàn)了產(chǎn)品和商業(yè)化的實踐（比如：諧云的可視化OAM實現(xiàn)），甚至來自其它云廠商比如 AWS 的開源項目整合與對接。可以看到，OAM 社區(qū)正在迅速成長和壯大中。

開源社區(qū)的運作模式一直是我們比較好奇的地方。據(jù)介紹，OAM 項目目前完全由社區(qū)驅(qū)動，由各子項目的 Maintainer 小組進行維護和管理。社區(qū)有每兩周一次的社區(qū)會議（美國和北京時間各一個）來進行重大事項的討論與決策和同步項目進度。整個社區(qū)的的工作流程按照 Maintainer 席位的投票機制來運轉(zhuǎn)，同時兼顧最終用戶的投票權(quán)。目前 OAM 社區(qū)的核心 Maintainer 來自阿里云，微軟和 Crossplane 項目原有的成員。在推廣策略上，由多個國際化大廠團隊維護的 OAM 項目從誕生起就是完全面向國際化開源社區(qū)的運作方式，憑借阿里與微軟自身場景，以及整個云原生社區(qū)和貢獻者的高質(zhì)量輸入來驅(qū)動整個項目向正確的方向持續(xù)演進，在溝通、分享、協(xié)作的氛圍中鼓勵貢獻和發(fā)展社區(qū)。這種模式下，一旦突破早期破冰階段，在隨后社區(qū)傳播和推廣方面會帶來病毒式的效果。

目前 OAM 的版本是 v1alpha2 ，OAM 的版本之后會不停迭代，根據(jù)實際的場景持續(xù)演進；當(dāng)然，同時 spec 本身也會保證規(guī)范的穩(wěn)定和兼容。這個標(biāo)準(zhǔn)的更新速度主要是取決于用戶的接受程度和反饋的情況，并且會在今年發(fā)布 Beta 版。本次合作中，OAM 已經(jīng)發(fā)布了 Kubernetes 的標(biāo)準(zhǔn)實現(xiàn)與核心依賴庫，這也就意味著未來整個開源生態(tài)都可以直接通過對接 Crossplane 或者 oam-kubernetes-runtime 來支持 OAM 標(biāo)準(zhǔn)，所以這樣的項目很快會越來越多。

如果你有任何疑問：
釘釘掃碼進入 OAM 項目中文討論群

• 通過 Gitter 直接參與討論
• OAM 開源實現(xiàn)地址
• 點擊 star 一下

作者簡介

Andy Shi? 阿里云高級技術(shù)專家，阿里巴巴集團開發(fā)者布道師，常年在硅谷從事開源技術(shù)推廣，在云平臺使用和網(wǎng)絡(luò)基礎(chǔ)架構(gòu)方面擁有豐富經(jīng)驗。

孫健波（花名：天元）? 阿里云技術(shù)專家，是 OAM 規(guī)范的主要制定者之一，致力于推動云原生應(yīng)用標(biāo)準(zhǔn)化。同時也在阿里巴巴參與大規(guī)模云原生應(yīng)用交付與應(yīng)用管理相關(guān)工作。

課程推薦

為了更多開發(fā)者能夠享受到 Serverless 帶來的紅利，這一次，我們集結(jié)了 10+ 位阿里巴巴 Serverless 領(lǐng)域技術(shù)專家，打造出最適合開發(fā)者入門的 Serverless 公開課，讓你即學(xué)即用，輕松擁抱云計算的新范式——Serverless。

點擊即可免費觀看課程：https://developer.aliyun.com/learning/roadmap/serverless

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的公眾號。”

總結(jié)

以上是生活随笔為你收集整理的OAM 创始团队：揭秘 OAM Kubernetes 实现核心原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。