OAM创始团队:揭秘OAMKubernetes实现核心原理
作者 |?Andy Shi(阿里云高級(jí)技術(shù)專家)、天元(阿里云技術(shù)專家)
今年 5 月,阿里云和微軟云共同宣布,Open Application Model (OAM) 社區(qū)攜手知名混合云管理項(xiàng)目 Crossplane 社區(qū),聯(lián)合發(fā)布了 OAM 在 Kubernetes 平臺(tái)上的標(biāo)準(zhǔn)實(shí)現(xiàn)與核心依賴庫(kù)。本次合作達(dá)成后,OAM 社區(qū)成功的將標(biāo)準(zhǔn)應(yīng)用定義和標(biāo)準(zhǔn)化的云服務(wù)管理能力統(tǒng)一起來(lái),邁出了實(shí)現(xiàn)真正意義上的無(wú)差別云端應(yīng)用交付的關(guān)鍵一步 。
去年 10 月 ,阿里云和微軟共同推出了?OAM?項(xiàng)目,旨在構(gòu)建圍繞 Kubernetes 的云原生應(yīng)用規(guī)范。OAM 描述了一個(gè)模型 —— 開發(fā)人員可以在其中定義應(yīng)用程序組件;應(yīng)用程序操作員負(fù)責(zé)創(chuàng)建這些組件的實(shí)例并為它們分配應(yīng)用程序配置;基礎(chǔ)架構(gòu)運(yùn)營(yíng)商負(fù)責(zé)定義、安裝和維護(hù)平臺(tái)上可用的基礎(chǔ)服務(wù)。?
本次合作是阿里云、微軟與 Crossplane 社區(qū)的三方技術(shù)合作,主要圍繞 OAM 在 Kubernetes 上的標(biāo)準(zhǔn)實(shí)現(xiàn)以及 Crossplane 項(xiàng)目的 OAM 化展開。因?yàn)?Kubernetes 社區(qū)在落地 OAM 模型的過(guò)程中,提出了關(guān)于 OAM 標(biāo)準(zhǔn)實(shí)現(xiàn)的訴求。所以這次合作的一個(gè)重點(diǎn),就是三方工程師使用 Go 語(yǔ)言開發(fā)了一個(gè) OAM Kubernetes 核心依賴庫(kù)。這個(gè)項(xiàng)目的名字叫做?oam-kubernetes-runtime。OAM Kubernetes Runtime 將會(huì)成為 OAM 社區(qū)官方維護(hù)的基礎(chǔ)組件,目標(biāo)是在 Kubernetes 上提供穩(wěn)定且統(tǒng)一的 OAM 核心插件。?
為進(jìn)一步了解本次合作的細(xì)節(jié)以及 OAM 項(xiàng)目的現(xiàn)狀,阿里云高級(jí)技術(shù)專家 Andy Shi 以及阿里云技術(shù)專家孫健波(花名:天元)接受開源中國(guó)的專訪,共同探討了 OAM 項(xiàng)目存在的意義。
詳情戳:https://www.oschina.net/question/4487475_2317219
OAM 因何而生
我們知道,應(yīng)用容器技術(shù)自誕生開始,就以 “徹底改變了軟件打包與分發(fā)方式” 的魅力迅速征服了幾乎所有的云廠商與數(shù)據(jù)中心。不過(guò),軟件打包與分發(fā)方式的革新,并沒有能夠讓軟件本身的定義與描述發(fā)生本質(zhì)的變化,基于 K8s 的應(yīng)用管理體驗(yàn),也沒有讓業(yè)務(wù)研發(fā)與運(yùn)維的工作變得更簡(jiǎn)單。?
實(shí)際上,Kubernetes 帶來(lái)的云原生技術(shù)革命,在于實(shí)現(xiàn)了基礎(chǔ)設(shè)施層的標(biāo)準(zhǔn)化和抽象,但這一層抽象距離業(yè)務(wù)研發(fā)與運(yùn)維還是太過(guò)遙遠(yuǎn)了。一個(gè)最典型的例子,直到今天,Kubernetes 里面始終都沒有 “應(yīng)用” 這個(gè)概念,它提供的是更細(xì)粒度的 “工作負(fù)載” 原語(yǔ),比如 Deployment 或者 DaemonSet。
而在實(shí)際環(huán)境中,一個(gè)應(yīng)用往往是由一系列獨(dú)立組件的組合,比如一個(gè) “PHP 應(yīng)用容器” 和一個(gè) “數(shù)據(jù)庫(kù)實(shí)例” 組成的電商網(wǎng)站;一個(gè) “參數(shù)服務(wù)節(jié)點(diǎn)” 和一個(gè) “工作節(jié)點(diǎn)” 組成的機(jī)器學(xué)習(xí)訓(xùn)練任務(wù);一個(gè)由 “Deployment + StatefulSet + HPA + Service + Ingress” 組成的微服務(wù)應(yīng)用。
“應(yīng)用” 這個(gè)概念在 Kubernetes 項(xiàng)目中的缺失,既是一個(gè)有意而為之的設(shè)計(jì),卻也造成了今天云原生應(yīng)用管理生態(tài)的極度碎片化和極高的學(xué)習(xí)門檻。如何通過(guò)標(biāo)準(zhǔn)化的方式去解決這個(gè)?“Kubernetes 里到底什么是應(yīng)用”?的問題,正是 OAM 項(xiàng)目發(fā)布的最初始動(dòng)機(jī)。?
有什么意義?
在 OAM 發(fā)布之前,云原生生態(tài)里其實(shí)并沒有一個(gè)叫做 “應(yīng)用” 的概念。哪怕在今天,全世界幾乎每一個(gè)在落地云原生的團(tuán)隊(duì),都有一個(gè)自己定義的 “應(yīng)用” 的概念,它們的抽象程度層次不齊,定義方式也豐富多樣,這就導(dǎo)致了所有圍繞著這些 “應(yīng)用” 構(gòu)建出來(lái)的系統(tǒng),就成為了一個(gè)又一個(gè)的大煙囪。?
對(duì)于整個(gè)云原生生態(tài)來(lái)說(shuō),這種應(yīng)用層的碎片化和煙囪化,其實(shí)對(duì)于整個(gè)生態(tài)演進(jìn)是非常不利的。而今天的現(xiàn)狀也已經(jīng)證明了這一點(diǎn),在 Kubernetes 逐漸標(biāo)準(zhǔn)化了基礎(chǔ)設(shè)施能力的接入方式之后,原本更加接近用戶、更加重要的應(yīng)用管理層,卻幾乎停滯了演進(jìn),在最近幾年里沒有提出任何一個(gè)創(chuàng)新性的思想出來(lái)。?
應(yīng)用管理層停滯不前的結(jié)果,就是全世界的業(yè)務(wù)研發(fā)和運(yùn)維一夜之間都被迫變成了 “容器專家”,一邊學(xué)習(xí)著根本不應(yīng)該是他們關(guān)心的各種 “基礎(chǔ)設(shè)施即數(shù)據(jù)(Infrastructure as Data)” 領(lǐng)域的概念(比如:聲明式 API,控制器等),一邊吐槽 Kubernetes 實(shí)在是太復(fù)雜了、設(shè)計(jì)太奇葩了。?
簡(jiǎn)而言之,Kubernetes 作為一個(gè)面向基礎(chǔ)設(shè)施工程師的系統(tǒng)級(jí)項(xiàng)目,主要負(fù)責(zé)提供松耦合的基礎(chǔ)設(shè)施語(yǔ)義,這就使得用戶學(xué)習(xí)和操作 Kubernetes YAML 文件的時(shí)候,往往會(huì)感覺這些文件里的關(guān)注點(diǎn)非常底層,學(xué)習(xí)門檻很高。?
實(shí)際上,對(duì)于Kubernetes 真正的最終用戶比如業(yè)務(wù)研發(fā)人員和運(yùn)維人員來(lái)說(shuō),他們并不想配置這些如此底層的資源信息,而是希望有更高維度的抽象。這就要求一個(gè)真正面向最終用戶側(cè)的應(yīng)用定義,需要能夠?yàn)闃I(yè)務(wù)研發(fā)和應(yīng)用運(yùn)維人員提供各自視角的應(yīng)用定義原語(yǔ)。所以說(shuō),OAM 帶來(lái)的第一個(gè)改變,就是提供了一種大家都可以遵循的、標(biāo)準(zhǔn)化的方式來(lái)定義更高層級(jí)的應(yīng)用層抽象,并且把“關(guān)注點(diǎn)分離”作為這個(gè)定義模型的核心思想。
而 OAM 帶來(lái)的第二個(gè)變化,則是為 Kubernetes 項(xiàng)目帶來(lái)了應(yīng)用定義,更確切地說(shuō),是對(duì)應(yīng)用本身和它所需運(yùn)維能力進(jìn)行定義與描述的標(biāo)準(zhǔn)開源規(guī)范。站在 Kubernetes 項(xiàng)目的角度來(lái)講,OAM 是一個(gè) Kubernetes 原生的標(biāo)準(zhǔn)的“應(yīng)用定義”項(xiàng)目,同時(shí)也是一個(gè)專注于封裝、組織和管理 Kubernetes 中各種“運(yùn)維能力”、以及連接“運(yùn)維能力”與“應(yīng)用”的平臺(tái)層框架。?
詳細(xì)的說(shuō),OAM 基于 Kubernetes API 資源模型(Kubernetes Resource Model)來(lái)標(biāo)準(zhǔn)化應(yīng)用定義的規(guī)范,它強(qiáng)調(diào)一個(gè)現(xiàn)代應(yīng)用是多個(gè)組件的集合,而非一個(gè)簡(jiǎn)單的工作負(fù)載或者 K8s Operator。所以在 OAM 的語(yǔ)境中,一個(gè) PHP 容器和它所依賴的數(shù)據(jù)庫(kù),以及它所需要使用的各種云服務(wù),都是一個(gè)“電商網(wǎng)站”應(yīng)用的組成部分。更進(jìn)一步的,OAM 把這個(gè)應(yīng)用所需的“運(yùn)維策略”也認(rèn)為是一個(gè)應(yīng)用的一部分,比如這個(gè) PHP 容器所需的 HPA(水平自動(dòng)擴(kuò)展策略):
以 Crossplane 項(xiàng)目為例,它在本次合作中通過(guò) OAM 升級(jí)之后得到了怎樣的變化呢?
“ 作為混合云管理領(lǐng)域中的佼佼者,Crossplane 的 OAM 化保證了今天任何一個(gè)符合 OAM 規(guī)范的待運(yùn)行程序、運(yùn)維能力和它所依賴的云服務(wù),可以組成一個(gè)整體在混合云環(huán)境中無(wú)縫漂移。”?
這種平臺(tái)無(wú)關(guān)的應(yīng)用定義范式,使得應(yīng)用研發(fā)人員只需要通過(guò) OAM 規(guī)范來(lái)描述他們的應(yīng)用程序,那么該應(yīng)用程序就可以在任何 Kubernetes 群集或者 Serverless 應(yīng)用平臺(tái)甚至邊緣環(huán)境上運(yùn)行,而無(wú)需對(duì)應(yīng)用描述做任何修改。本次合作中 Crossplane OAM 版的發(fā)布,則意味著 OAM 社區(qū)正在將標(biāo)準(zhǔn)應(yīng)用定義和標(biāo)準(zhǔn)化的云服務(wù)管理能力統(tǒng)一起來(lái),從而實(shí)現(xiàn)真正的 “云端應(yīng)用交付” 。
OAM 如何發(fā)揮作用?
那么 OAM 在一個(gè)項(xiàng)目中是如何運(yùn)作的呢?
據(jù)介紹,OAM 以原生插件的方式運(yùn)行在 Kubernetes 當(dāng)中。OAM 強(qiáng)調(diào)整個(gè)模型是關(guān)注點(diǎn)分離的。即業(yè)務(wù)研發(fā)人員負(fù)責(zé)定義和維護(hù)組件 (Component) 來(lái)描述服務(wù)單元,而運(yùn)維人員定義運(yùn)維特征 (Trait),并將其附加到前面的組件上,最后構(gòu)成 OAM 可交付物 ——ApplicationConfiguration。
這種設(shè)計(jì)是 OAM 在能夠無(wú)限接入 Kubernetes 各種能力的同時(shí),保證給業(yè)務(wù)研發(fā)與運(yùn)維人員提供最佳的使用體驗(yàn)和最低的心智負(fù)擔(dān)的重要基礎(chǔ)。與此同時(shí),基礎(chǔ)設(shè)施工程師可以隨時(shí)在 Kubernetes 中添加更多工作負(fù)載(例如 FaaS)以運(yùn)行無(wú)服務(wù)器功能,或者添加運(yùn)維特性(例如 CronHPA)來(lái)定義 CronJob 類型的 HPA 策略。OAM 以標(biāo)準(zhǔn)的聲明方式在整個(gè)平臺(tái)中管理應(yīng)用交付能力和流程,并且提供面向各個(gè)角色的 API 原語(yǔ)來(lái)表達(dá)各自的訴求,最后通過(guò) Kubernetes 把這些訴求落實(shí)。
什么樣的項(xiàng)目需要 OAM?
實(shí)際上,幾乎所有基于 Kubernetes 的應(yīng)用管理平臺(tái)都對(duì)通過(guò) OAM 來(lái)以標(biāo)準(zhǔn)化的方式去構(gòu)建自己的應(yīng)用模型有明確的訴求。另一方面,由于 OAM 是原生的 Kubernetes API 資源模型,這里的遷移過(guò)程難度很低,可以通過(guò) API 對(duì)象灰度納管的方式逐步完成遷移操作(通過(guò) OAM 對(duì)象逐步接管現(xiàn)有 Kubernetes 對(duì)象)。
而相比于傳統(tǒng) PaaS 封閉的、不能同 “以 Operator 為基礎(chǔ)的云原生生態(tài)” 銜接的現(xiàn)狀,基于 OAM 和 Kubernetes 構(gòu)建的現(xiàn)代云原生應(yīng)用管理平臺(tái),本質(zhì)上是一個(gè) “以應(yīng)用為中心” 的? Kubernetes ,保證了這個(gè)應(yīng)用平臺(tái)在能夠無(wú)縫接入整個(gè)云原生生態(tài)。同時(shí),OAM 可以進(jìn)一步屏蔽掉容器基礎(chǔ)設(shè)施的復(fù)雜性和差異性,為平臺(tái)的使用者帶來(lái)低心智負(fù)擔(dān)的、標(biāo)準(zhǔn)化的、一致的應(yīng)用管理與交付體驗(yàn)。這就使得一個(gè)基于OAM 構(gòu)建的 Kubernetes 應(yīng)用平臺(tái),首先能夠隱藏底層基礎(chǔ)設(shè)施的細(xì)節(jié)(例如,是云還是物聯(lián)網(wǎng)),專注于應(yīng)用層抽象,提供以應(yīng)用為中心的資源模型。
其次,OAM 劃分了應(yīng)用交付路徑上的開發(fā)、運(yùn)維、基礎(chǔ)架構(gòu)三種角色,分離了關(guān)注點(diǎn),讓流程更加清晰和易于管理。
第三,OAM 站在 K8s ?API 資源模型的肩膀之上,提供了可移植的應(yīng)用與基礎(chǔ)設(shè)施抽象,讓一個(gè)應(yīng)用描述可以完全不加修改的云、邊、端等任何環(huán)境下直接交付運(yùn)行起來(lái)。
除此之外,OAM 還定義了一組核心工作負(fù)載/運(yùn)維特征/應(yīng)用范疇,作為應(yīng)用程序交付平臺(tái)的基石。而平臺(tái)開發(fā)者也可以添加更多工作負(fù)載(例如 FaaS 或者任意云服務(wù)),或者添加運(yùn)維特性(例如 CronHPA)來(lái)定義 CronJob 類型的 HPA 策略。OAM 以標(biāo)準(zhǔn)的聲明方式在整個(gè)平臺(tái)中管理應(yīng)用交付能力和流程。當(dāng)模塊化的 Workload 和 Trait 越來(lái)越多,就會(huì)形成組件市場(chǎng)。而 OAM 就像是這個(gè)組件市場(chǎng)的管理者,處理組件之間的關(guān)系,把許多組件集成起來(lái)變成一個(gè)產(chǎn)品交付給用戶。OAM 加持下的 Kubernetes 應(yīng)用管理平臺(tái),可以像樂高積木一樣靈活組裝底層能力、運(yùn)維特征、以及開發(fā)組件。使得應(yīng)用管理變得統(tǒng)一,功能卻更加強(qiáng)大。
OAM 社區(qū)現(xiàn)狀
談到 OAM 項(xiàng)目社區(qū)的現(xiàn)狀。“ 作為一個(gè)沒有同商業(yè)訴求綁定的中立開源社區(qū),OAM 生態(tài)自成立以來(lái)保持著較高的活躍度和參與度,大量的社區(qū) Issue/PR貢獻(xiàn)都來(lái)自阿里和微軟之外的團(tuán)隊(duì)比如 AWS、騰訊、字節(jié)跳動(dòng)、諧云、青云、好雨云、第四范式等生態(tài)參與者。除了阿里和微軟本身以及基于 OAM 實(shí)現(xiàn)了內(nèi)部應(yīng)用管理架構(gòu)的統(tǒng)一和標(biāo)準(zhǔn)化之外,不少基于 OAM 的云服務(wù)比如阿里云 EDAS 也已經(jīng)上線。”??
與此同時(shí),OAM 技術(shù)體系也開始在很多大型社區(qū)用戶(比如 MasterCard 萬(wàn)事達(dá)卡)中落地,同時(shí)也出現(xiàn)了產(chǎn)品和商業(yè)化的實(shí)踐(比如:諧云的可視化OAM實(shí)現(xiàn)),甚至來(lái)自其它云廠商比如 AWS 的開源項(xiàng)目整合與對(duì)接。可以看到,OAM 社區(qū)正在迅速成長(zhǎng)和壯大中。?
開源社區(qū)的運(yùn)作模式一直是我們比較好奇的地方。據(jù)介紹,OAM 項(xiàng)目目前完全由社區(qū)驅(qū)動(dòng),由各子項(xiàng)目的 Maintainer 小組進(jìn)行維護(hù)和管理。社區(qū)有每?jī)芍芤淮蔚纳鐓^(qū)會(huì)議(美國(guó)和北京時(shí)間各一個(gè))來(lái)進(jìn)行重大事項(xiàng)的討論與決策和同步項(xiàng)目進(jìn)度。整個(gè)社區(qū)的的工作流程按照 Maintainer 席位的投票機(jī)制來(lái)運(yùn)轉(zhuǎn),同時(shí)兼顧最終用戶的投票權(quán)。目前 OAM 社區(qū)的核心 Maintainer 來(lái)自阿里云,微軟和 Crossplane 項(xiàng)目原有的成員。在推廣策略上,由多個(gè)國(guó)際化大廠團(tuán)隊(duì)維護(hù)的 OAM 項(xiàng)目從誕生起就是完全面向國(guó)際化開源社區(qū)的運(yùn)作方式,憑借阿里與微軟自身場(chǎng)景,以及整個(gè)云原生社區(qū)和貢獻(xiàn)者的高質(zhì)量輸入來(lái)驅(qū)動(dòng)整個(gè)項(xiàng)目向正確的方向持續(xù)演進(jìn),在溝通、分享、協(xié)作的氛圍中鼓勵(lì)貢獻(xiàn)和發(fā)展社區(qū)。這種模式下,一旦突破早期破冰階段,在隨后社區(qū)傳播和推廣方面會(huì)帶來(lái)病毒式的效果。?
目前 OAM 的版本是 v1alpha2 ,OAM 的版本之后會(huì)不停迭代,根據(jù)實(shí)際的場(chǎng)景持續(xù)演進(jìn);當(dāng)然,同時(shí) spec 本身也會(huì)保證規(guī)范的穩(wěn)定和兼容。這個(gè)標(biāo)準(zhǔn)的更新速度主要是取決于用戶的接受程度和反饋的情況,并且會(huì)在今年發(fā)布 Beta 版。本次合作中,OAM 已經(jīng)發(fā)布了 Kubernetes 的標(biāo)準(zhǔn)實(shí)現(xiàn)與核心依賴庫(kù),這也就意味著未來(lái)整個(gè)開源生態(tài)都可以直接通過(guò)對(duì)接 Crossplane 或者 oam-kubernetes-runtime 來(lái)支持 OAM 標(biāo)準(zhǔn),所以這樣的項(xiàng)目很快會(huì)越來(lái)越多。
如果你有任何疑問:
釘釘掃碼進(jìn)入 OAM 項(xiàng)目中文討論群
- 通過(guò) Gitter 直接參與討論
- OAM 開源實(shí)現(xiàn)地址
- 點(diǎn)擊 star 一下
作者簡(jiǎn)介
Andy Shi? 阿里云高級(jí)技術(shù)專家,阿里巴巴集團(tuán)開發(fā)者布道師,常年在硅谷從事開源技術(shù)推廣,在云平臺(tái)使用和網(wǎng)絡(luò)基礎(chǔ)架構(gòu)方面擁有豐富經(jīng)驗(yàn)。
孫健波(花名:天元)? 阿里云技術(shù)專家,是 OAM 規(guī)范的主要制定者之一,致力于推動(dòng)云原生應(yīng)用標(biāo)準(zhǔn)化。同時(shí)也在阿里巴巴參與大規(guī)模云原生應(yīng)用交付與應(yīng)用管理相關(guān)工作。
課程推薦
為了更多開發(fā)者能夠享受到 Serverless 帶來(lái)的紅利,這一次,我們集結(jié)了 10+ 位阿里巴巴 Serverless 領(lǐng)域技術(shù)專家,打造出最適合開發(fā)者入門的 Serverless 公開課,讓你即學(xué)即用,輕松擁抱云計(jì)算的新范式——Serverless。
點(diǎn)擊即可免費(fèi)觀看課程:https://developer.aliyun.com/learning/roadmap/serverless
“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐,做最懂云原生開發(fā)者的公眾號(hào)。”
原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容,未經(jīng)允許不得轉(zhuǎn)載。
總結(jié)
以上是生活随笔為你收集整理的OAM创始团队:揭秘OAMKubernetes实现核心原理的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 流批一体机器学习算法平台
- 下一篇: 分享实录 | 企业CICD规模化落地浅析