KubeVela與PaaS的不同點(diǎn)有哪些

本篇內(nèi)容介紹了“KubeVela與PaaS的不同點(diǎn)有哪些”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

首先，我們先說(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)分配域名和訪(fǎ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 中？

• 等等 ……

“KubeVela與PaaS的不同點(diǎn)有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！