深入解读:KubeVela 与 PaaS 有何不同?
作者 | 鄧洪超 阿里云高級(jí)技術(shù)專(zhuān)家
來(lái)源|阿里巴巴云原生公眾號(hào)
在 KubeVela 項(xiàng)目發(fā)布以后,很多國(guó)內(nèi)外的社區(qū)同學(xué)們都會(huì)問(wèn)到一個(gè)類(lèi)似的問(wèn)題:KubeVela 的體驗(yàn)真的非常棒,可以說(shuō)是 Kubernetes 上的 Heroku 了。這么看來(lái), KubeVela 跟 Heroku 這樣的 PaaS 產(chǎn)品到底是不是一類(lèi)項(xiàng)目呢?
今天,我們就專(zhuān)門(mén)來(lái)聊一個(gè)這個(gè)話(huà)題:KubeVela 與 PaaS 有何不同?
備注:本文所提到的 PaaS,既包括 Heroku 這樣的經(jīng)典 PaaS 產(chǎn)品,也包括各種各樣的基于 Kubernetes 的“云原生” PaaS。它們雖然底層實(shí)現(xiàn)不同,但是對(duì)用戶(hù)提供的使用接口和體驗(yàn)是相似的。但 OpenShift 是一個(gè)例外,作為一個(gè)比 Kubernetes 本身還復(fù)雜的項(xiàng)目,OpenShift 不屬于本文所討論的簡(jiǎn)單易用、面向用戶(hù)的 PaaS 之列,而是一個(gè)地道的 Kubernetes 發(fā)行版。
首先,我們先說(shuō)結(jié)論:KubeVela 能夠?yàn)橛脩?hù)帶來(lái)非常接近 PaaS 的體驗(yàn),但 KubeVela 并不是 PaaS。
為什么說(shuō) KubeVela 不是 PaaS?
大多數(shù) PaaS 都能提供完整的應(yīng)用生命周期管理功能,同時(shí)也非常關(guān)注提供簡(jiǎn)單友好的用戶(hù)體驗(yàn),以及對(duì)研發(fā)效能的提升。在這些點(diǎn)上,KubeVela 跟 PaaS 的目標(biāo)和提供的用戶(hù)體驗(yàn),是高度一致的。但如果你去研究 KubeVela 的實(shí)現(xiàn)細(xì)節(jié),就不難發(fā)現(xiàn) KubeVela 的整體設(shè)計(jì)與實(shí)現(xiàn)其實(shí)與各類(lèi) PaaS 項(xiàng)目的差別是非常大的。如果從用戶(hù)視角來(lái)看,這些區(qū)別則會(huì)直接反應(yīng)在整個(gè)項(xiàng)目的“可擴(kuò)展性”上。
進(jìn)一步來(lái)說(shuō),PaaS 的用戶(hù)體驗(yàn)雖好,但卻往往是不可擴(kuò)展的。我們可以直接拿比較新的 Kubernetes PaaS,比如 Rancher Rio 項(xiàng)目來(lái)看。這個(gè)項(xiàng)目提供了很好的應(yīng)用部署體驗(yàn),比如 Rio run 來(lái)讓你快速部署一個(gè)容器化應(yīng)用、自動(dòng)分配域名和訪問(wèn)規(guī)則等等。但是,如果我們想讓 Rio 支持更多的能力以滿(mǎn)足不同的用戶(hù)訴求呢?
比如:
- 能否幫助我運(yùn)行一個(gè) 定時(shí)任務(wù)?
- 能不能幫我運(yùn)行一個(gè) OpenKruise 的 CloneSet 工作負(fù)載?
- 能不能幫我運(yùn)行一個(gè) MySQL Operator?
- 能不能根據(jù)我的自定義 metrics 來(lái)做水平擴(kuò)容?
- 能不能基于 Flagger 和 Istio來(lái)幫我做漸進(jìn)式灰度發(fā)布?
- 能不能 ……
而這里的關(guān)鍵點(diǎn)在于,上述這些能力在 Kubernetes 生態(tài)中都是非常常見(jiàn)的的能力,有的甚至是 Kubernetes 內(nèi)置就可以支持。可是到了 PaaS 這里,要支持上述任何一個(gè)能力,都必須對(duì) PaaS 進(jìn)行一輪開(kāi)發(fā),而且由于先前的一些假設(shè)和設(shè)計(jì),甚至很可能需要大規(guī)模的重構(gòu)。
舉個(gè)例子,我有一個(gè) PaaS 系統(tǒng),它所有的應(yīng)用都是通過(guò) Deployment 來(lái)執(zhí)行的,那么這個(gè) PaaS 的發(fā)布、擴(kuò)容等功能,也都會(huì)直接按照 Deployment 來(lái)進(jìn)行實(shí)現(xiàn)。而現(xiàn)在,用戶(hù)提出了原地升級(jí)的訴求,需要讓這個(gè) PaaS 再支持 CloneSet,那整套系統(tǒng)很可能就得掀翻重來(lái)。再到運(yùn)維能力這一側(cè),這個(gè)問(wèn)題會(huì)更加嚴(yán)重,比如現(xiàn)在這個(gè) PaaS 支持的是藍(lán)綠發(fā)布策略,那么它跟流量管理、監(jiān)控系統(tǒng)等依賴(lài)之間,都是需要大量交互和集成的。而現(xiàn)在我們要讓 PaaS 支持一個(gè)新的策略叫做“金絲雀”發(fā)布,那么所有的這些交互和執(zhí)行邏輯基本全得重重構(gòu)一遍,工作量是巨大的。
當(dāng)然,并不是所有的 PaaS 都完全沒(méi)有可擴(kuò)展性。工程能力比較強(qiáng)的 PaaS,比如 Cloud Foundry 和 Heroku,它們都提供了自己的插件能力和插件中心,在確保平臺(tái)本身的用戶(hù)體驗(yàn)和能力的可控制性的前提下開(kāi)放一定的插件能力,比如允許用戶(hù)接入自己的數(shù)據(jù)庫(kù),或者開(kāi)發(fā)一些簡(jiǎn)單的 Feature 進(jìn)去。但這種插件機(jī)制無(wú)論怎么做,說(shuō)白了只能是這個(gè) PaaS 專(zhuān)屬的封閉小生態(tài)能力。而在云原生時(shí)代,我們開(kāi)源社區(qū)已經(jīng)有了 Kubernetes 生態(tài)這樣一個(gè)近乎“無(wú)限”的能力池,在這個(gè)能力池面前,任何 PaaS 專(zhuān)屬的小生態(tài)都顯得太蒼白無(wú)力了。
上述問(wèn)題,我們可以統(tǒng)稱(chēng)為 PaaS 的“能力困境”。
相比之下,KubeVela 的目標(biāo)從一開(kāi)始就是利用整個(gè) Kubernetes 生態(tài)作為自己的“插件中心”,并且“有意”把它的每一個(gè)內(nèi)置能力都設(shè)計(jì)成獨(dú)立的、可插拔的插件。這種高度可擴(kuò)展的模型,背后其實(shí)有著精密的設(shè)計(jì)與實(shí)現(xiàn)。比如,KubeVela 如何確保某個(gè)完全獨(dú)立的 Trait 一定能夠綁定于某種 Workload Type?如何檢查這些相互獨(dú)立的 Trait 間是否存在沖突?這些挑戰(zhàn)正是 Open Application Model(OAM)作為 KubeVela 模型層的起到的關(guān)鍵作用,一言以蔽之:OAM 是一個(gè)高度可擴(kuò)展的應(yīng)用定義與能力裝配模型。
而且,大家設(shè)計(jì)和制作任何 Workload Type 和 Trait 的定義文件,只要存放在 GitHub 上,全世界任何一個(gè) KubeVela 用戶(hù)就都可以在自己的 Appfile 里使用這些能力。具體的方式,請(qǐng)參考 $ vela cap (即:插件能力管理命令)的使用文檔。
所以說(shuō),KubeVela 提倡的是一種面向未來(lái)的云原生平臺(tái)架構(gòu),這種架構(gòu)認(rèn)為:
- 應(yīng)用平臺(tái)本身架構(gòu)徹底模塊化,其所有的能力都是可插拔的,而平臺(tái)核心框架通過(guò)模型層提供標(biāo)準(zhǔn)化的能力封裝與裝配流程。
- 該流程能夠無(wú)縫接入云原生生態(tài)中的任何應(yīng)用管理能力,使得平臺(tái)工程師完全專(zhuān)注于能力本身的研發(fā)和基于該模型的能力封裝過(guò)程,使平臺(tái)團(tuán)隊(duì)在為用戶(hù)帶來(lái)簡(jiǎn)單易用的平臺(tái)層抽象的同時(shí),快速、敏捷地響應(yīng)用戶(hù)千變?nèi)f化的應(yīng)用管理訴求。
KubeVela 整體架構(gòu)與能力可插拔機(jī)制
KubeVela 整體架構(gòu)如下圖所示:
在架構(gòu)上,KubeVela 只有一個(gè) controller 并且以插件的方式運(yùn)行在 Kubernetes 之上,為 Kubernetes 帶來(lái)了面向應(yīng)用層的抽象,以及以此為基礎(chǔ)的面向用戶(hù)的使用界面,即Appfile。Appfile 乃至 KubeVela 運(yùn)行機(jī)制背后的核心,則是其能力管理模型 Open Application Model (OAM) 。基于這個(gè)模型,KubeVela 為系統(tǒng)管理員提供了一套基于注冊(cè)與自發(fā)現(xiàn)的能力裝配流程,來(lái)接入 Kubernetes 生態(tài)中的任意能力到 KubeVela 中,從而以“一套核心框架搭配不同能力”的方式,適配各種使用場(chǎng)景(比如 AI PaaS,數(shù)據(jù)庫(kù) PaaS 等等)。
具體操作上,作為系統(tǒng)管理員或者平臺(tái)開(kāi)發(fā)者,上述能力裝配流程允許他們把任意的 Kubernetes API 資源(含 CRD)以及對(duì)應(yīng)的 Controller 作為“能力”一鍵注冊(cè)到 KubeVela 中,然后通過(guò) CUE 模板語(yǔ)言將這些能力封裝成用戶(hù)可用的抽象(即成為 Appfile 中的一部分)。
接下來(lái),我們就來(lái) Demo 一下如何將 kubewatch 這個(gè)社區(qū)中的告警機(jī)制直接插入到 KubeVela 中作為一個(gè)告警 Trait 來(lái)使用:
Step 1:將平臺(tái)能力注冊(cè)為 OAM 對(duì)象
首先,你需要確定 CRD 所表示的能力是對(duì)應(yīng)一個(gè) Workload Type 還是 Trait?這里的區(qū)別在于 Workload Type 指的是如何運(yùn)行你的代碼。而 Trait 指的是如何運(yùn)維、管理或者操作已經(jīng)運(yùn)行起來(lái)的代碼實(shí)例。
而 KubeWatch 作為一種告警機(jī)制,自然作為 Trait 來(lái)使用的。這時(shí)候,我們就可以通過(guò)寫(xiě)一個(gè) TraitDefinition yaml 來(lái)將它注冊(cè):
KubeVela 內(nèi)置的服務(wù)器端 Runtime 會(huì)識(shí)別監(jiān)聽(tīng)的 TraitDefinition 注冊(cè)事件,然后將該能力納入平臺(tái)管理中。
這一步完成,KubeVela 就已經(jīng)注冊(cè)完畢在 KubeVela 平臺(tái)中可用了。但接下來(lái)我們還需要將它暴露給用戶(hù)使用,所以需要定義這個(gè)能力對(duì)外的使用接口。
Step 2:編寫(xiě) CUE template 來(lái)封裝對(duì)外暴露接口
實(shí)際上,大多數(shù)社區(qū)能力雖然很強(qiáng)大,但對(duì)于最終用戶(hù)來(lái)都比較復(fù)雜,學(xué)習(xí)和上手非常困難。所以在 KubeVela 中,它允許平臺(tái)管理員對(duì)能力做進(jìn)一步封裝以便對(duì)用戶(hù)暴露簡(jiǎn)單易用的使用接口,在絕大多數(shù)場(chǎng)景下,這些使用接口往往只有幾個(gè)參數(shù)就足夠了。在能力封裝這一步,KubeVela 選擇了 CUE 模板語(yǔ)言,來(lái)連接用戶(hù)界面和后端能力對(duì)象,并且天然就支持完全動(dòng)態(tài)的模板綁定(即變更模板不需要重啟或者重新部署系統(tǒng))。下面就是 KubeWatch Trait 的模板例子:
將這個(gè)模板放到 Definition 文件中并 $ kubectl apply -f 到 Kubernetes 中,KubeVela 就會(huì)自動(dòng)識(shí)別和處理相關(guān)輸入。這時(shí)候,用戶(hù)就可以直接在 Appfile 中聲明使用剛加進(jìn)來(lái)的能力了,比如發(fā)送告警信息到指定的 Slack channel:
可以看到,這個(gè) kubewatch 的配置是我們通過(guò)三方擴(kuò)展進(jìn)來(lái)的一個(gè)新的能力,通過(guò) KubeVela 平臺(tái)管理 Kubernetes 擴(kuò)展能力就是這么簡(jiǎn)單快速。有了 KubeVela,平臺(tái)開(kāi)發(fā)人員就可以簡(jiǎn)單快速地在 Kubernetes 上搭建起一個(gè) PaaS,且能夠?qū)⑷魏我粋€(gè) Kubernetes 能力快速封裝成面向最終用戶(hù)的上層抽象。
以上示例,僅僅是 KubeVela 可擴(kuò)展性的“冰山一角”。在后續(xù)的文章中,我們會(huì)繼續(xù)詳細(xì)介紹 KubeVela 能力裝配流程中更多的細(xì)節(jié)問(wèn)題,比如:
- 如何定義能力之間的沖突關(guān)系與協(xié)作關(guān)系?
- 如何快速的定義 CUE 模板文件?
- 如何基于 CUE 語(yǔ)言定義出功能強(qiáng)大的“能力模塊”,然后把這些模塊安裝到 KubeVela 中?
- 等等 ……
總結(jié)
原生的可擴(kuò)展性與能力裝配機(jī)制,是 KubeVela 與大多數(shù) PaaS 項(xiàng)目的根本性不同,這也導(dǎo)致 KubeVela 背后的實(shí)現(xiàn)和模型跟它們相比也有著本質(zhì)性的差異。所以說(shuō),KubeVela 的核心目標(biāo),乃是在為用戶(hù)帶來(lái)簡(jiǎn)單易用的應(yīng)用管理體驗(yàn)的同時(shí),為平臺(tái)管理員提供完全 Kubernetes 原生的可擴(kuò)展性與靈活度。
KubeVela 項(xiàng)目是 OAM 社區(qū)的官方項(xiàng)目,由來(lái)自阿里、微軟多位云原生社區(qū)資深成員共同維護(hù),同時(shí)也是阿里云 EDAS 服務(wù)和內(nèi)部多個(gè)雙十一級(jí)應(yīng)用管理平臺(tái)背后的核心組件。KubeVela 旨在構(gòu)建一個(gè)面向未來(lái)的云原生 PaaS 架構(gòu),將橫向可擴(kuò)展性和以應(yīng)用為中心這些最佳實(shí)踐帶給大家,推動(dòng)甚至引領(lǐng)云原生社區(qū)在應(yīng)用層的發(fā)展。
想要了解更多?歡迎前往官方網(wǎng)站上學(xué)習(xí)更多示例:
- 前往學(xué)習(xí) KubeVela Quick Start(新手教程),一步步了解 KubeVela 的使用方法。
- 前往 OAM 社區(qū)深入交流和反饋。中文:釘釘群 23310022,英文:Gitter 和 CNCF Slack。
作者簡(jiǎn)介
鄧洪超 阿里云高級(jí)技術(shù)專(zhuān)家, 人稱(chēng) “Kubernetes Operator 第二人”,OAM 與 KubeVela 項(xiàng)目核心維護(hù)者。
總結(jié)
以上是生活随笔為你收集整理的深入解读:KubeVela 与 PaaS 有何不同?的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: 从零入门 Serverless | SA
- 下一篇: 专访阿里云 Serverless 负责人