作者 | 鄧洪超 阿里云高級技術(shù)專家

來源|阿里巴巴云原生公眾號

在 KubeVela 項目發(fā)布以后，很多國內(nèi)外的社區(qū)同學(xué)們都會問到一個類似的問題：KubeVela 的體驗真的非常棒，可以說是 Kubernetes 上的 Heroku 了。這么看來， KubeVela 跟 Heroku 這樣的 PaaS 產(chǎn)品到底是不是一類項目呢？

今天，我們就專門來聊一個這個話題：KubeVela 與 PaaS 有何不同？

備注：本文所提到的 PaaS，既包括 Heroku 這樣的經(jīng)典 PaaS 產(chǎn)品，也包括各種各樣的基于 Kubernetes 的“云原生” PaaS。它們雖然底層實現(xiàn)不同，但是對用戶提供的使用接口和體驗是相似的。但 OpenShift 是一個例外，作為一個比 Kubernetes 本身還復(fù)雜的項目，OpenShift 不屬于本文所討論的簡單易用、面向用戶的 PaaS 之列，而是一個地道的 Kubernetes 發(fā)行版。

首先，我們先說結(jié)論：KubeVela 能夠為用戶帶來非常接近 PaaS 的體驗，但 KubeVela 并不是 PaaS。

為什么說 KubeVela 不是 PaaS？

大多數(shù) PaaS 都能提供完整的應(yīng)用生命周期管理功能，同時也非常關(guān)注提供簡單友好的用戶體驗，以及對研發(fā)效能的提升。在這些點上，KubeVela 跟 PaaS 的目標(biāo)和提供的用戶體驗，是高度一致的。但如果你去研究 KubeVela 的實現(xiàn)細節(jié)，就不難發(fā)現(xiàn) KubeVela 的整體設(shè)計與實現(xiàn)其實與各類 PaaS 項目的差別是非常大的。如果從用戶視角來看，這些區(qū)別則會直接反應(yīng)在整個項目的“可擴展性”上。

進一步來說，PaaS 的用戶體驗雖好，但卻往往是不可擴展的。我們可以直接拿比較新的 Kubernetes PaaS，比如 Rancher Rio 項目來看。這個項目提供了很好的應(yīng)用部署體驗，比如 Rio run 來讓你快速部署一個容器化應(yīng)用、自動分配域名和訪問規(guī)則等等。但是，如果我們想讓 Rio 支持更多的能力以滿足不同的用戶訴求呢？

比如：

• 能否幫助我運行一個 定時任務(wù)？
• 能不能幫我運行一個 OpenKruise 的 CloneSet 工作負載？
• 能不能幫我運行一個 MySQL Operator？
• 能不能根據(jù)我的自定義 metrics 來做水平擴容？
• 能不能基于 Flagger 和 Istio來幫我做漸進式灰度發(fā)布？
• 能不能 ……

而這里的關(guān)鍵點在于，上述這些能力在 Kubernetes 生態(tài)中都是非常常見的的能力，有的甚至是 Kubernetes 內(nèi)置就可以支持。可是到了 PaaS 這里，要支持上述任何一個能力，都必須對 PaaS 進行一輪開發(fā)，而且由于先前的一些假設(shè)和設(shè)計，甚至很可能需要大規(guī)模的重構(gòu)。

舉個例子，我有一個 PaaS 系統(tǒng)，它所有的應(yīng)用都是通過 Deployment 來執(zhí)行的，那么這個 PaaS 的發(fā)布、擴容等功能，也都會直接按照 Deployment 來進行實現(xiàn)。而現(xiàn)在，用戶提出了原地升級的訴求，需要讓這個 PaaS 再支持 CloneSet，那整套系統(tǒng)很可能就得掀翻重來。再到運維能力這一側(cè)，這個問題會更加嚴(yán)重，比如現(xiàn)在這個 PaaS 支持的是藍綠發(fā)布策略，那么它跟流量管理、監(jiān)控系統(tǒng)等依賴之間，都是需要大量交互和集成的。而現(xiàn)在我們要讓 PaaS 支持一個新的策略叫做“金絲雀”發(fā)布，那么所有的這些交互和執(zhí)行邏輯基本全得重重構(gòu)一遍，工作量是巨大的。

當(dāng)然，并不是所有的 PaaS 都完全沒有可擴展性。工程能力比較強的 PaaS，比如 Cloud Foundry 和 Heroku，它們都提供了自己的插件能力和插件中心，在確保平臺本身的用戶體驗和能力的可控制性的前提下開放一定的插件能力，比如允許用戶接入自己的數(shù)據(jù)庫，或者開發(fā)一些簡單的 Feature 進去。但這種插件機制無論怎么做，說白了只能是這個 PaaS 專屬的封閉小生態(tài)能力。而在云原生時代，我們開源社區(qū)已經(jīng)有了 Kubernetes 生態(tài)這樣一個近乎“無限”的能力池，在這個能力池面前，任何 PaaS 專屬的小生態(tài)都顯得太蒼白無力了。

上述問題，我們可以統(tǒng)稱為 PaaS 的“能力困境”。

相比之下，KubeVela 的目標(biāo)從一開始就是利用整個 Kubernetes 生態(tài)作為自己的“插件中心”，并且“有意”把它的每一個內(nèi)置能力都設(shè)計成獨立的、可插拔的插件。這種高度可擴展的模型，背后其實有著精密的設(shè)計與實現(xiàn)。比如，KubeVela 如何確保某個完全獨立的 Trait 一定能夠綁定于某種 Workload Type？如何檢查這些相互獨立的 Trait 間是否存在沖突？這些挑戰(zhàn)正是 Open Application Model（OAM）作為 KubeVela 模型層的起到的關(guān)鍵作用，一言以蔽之：OAM 是一個高度可擴展的應(yīng)用定義與能力裝配模型。

而且，大家設(shè)計和制作任何 Workload Type 和 Trait 的定義文件，只要存放在 GitHub 上，全世界任何一個 KubeVela 用戶就都可以在自己的 Appfile 里使用這些能力。具體的方式，請參考 $ vela cap （即：插件能力管理命令）的使用文檔。

所以說，KubeVela 提倡的是一種面向未來的云原生平臺架構(gòu)，這種架構(gòu)認為：

• 應(yīng)用平臺本身架構(gòu)徹底模塊化，其所有的能力都是可插拔的，而平臺核心框架通過模型層提供標(biāo)準(zhǔn)化的能力封裝與裝配流程。
• 該流程能夠無縫接入云原生生態(tài)中的任何應(yīng)用管理能力，使得平臺工程師完全專注于能力本身的研發(fā)和基于該模型的能力封裝過程，使平臺團隊在為用戶帶來簡單易用的平臺層抽象的同時，快速、敏捷地響應(yīng)用戶千變?nèi)f化的應(yīng)用管理訴求。

KubeVela 整體架構(gòu)與能力可插拔機制

KubeVela 整體架構(gòu)如下圖所示：

在架構(gòu)上，KubeVela 只有一個 controller 并且以插件的方式運行在 Kubernetes 之上，為 Kubernetes 帶來了面向應(yīng)用層的抽象，以及以此為基礎(chǔ)的面向用戶的使用界面，即Appfile。Appfile 乃至 KubeVela 運行機制背后的核心，則是其能力管理模型 Open Application Model (OAM) 。基于這個模型，KubeVela 為系統(tǒng)管理員提供了一套基于注冊與自發(fā)現(xiàn)的能力裝配流程，來接入 Kubernetes 生態(tài)中的任意能力到 KubeVela 中，從而以“一套核心框架搭配不同能力”的方式，適配各種使用場景（比如 AI PaaS，數(shù)據(jù)庫 PaaS 等等）。

具體操作上，作為系統(tǒng)管理員或者平臺開發(fā)者，上述能力裝配流程允許他們把任意的 Kubernetes API 資源（含 CRD）以及對應(yīng)的 Controller 作為“能力”一鍵注冊到 KubeVela 中，然后通過 CUE 模板語言將這些能力封裝成用戶可用的抽象（即成為 Appfile 中的一部分）。

接下來，我們就來 Demo 一下如何將 kubewatch 這個社區(qū)中的告警機制直接插入到 KubeVela 中作為一個告警 Trait 來使用：

Step 1：將平臺能力注冊為 OAM 對象

首先，你需要確定 CRD 所表示的能力是對應(yīng)一個 Workload Type 還是 Trait？這里的區(qū)別在于 Workload Type 指的是如何運行你的代碼。而 Trait 指的是如何運維、管理或者操作已經(jīng)運行起來的代碼實例。

而 KubeWatch 作為一種告警機制，自然作為 Trait 來使用的。這時候，我們就可以通過寫一個 TraitDefinition yaml 來將它注冊：

KubeVela 內(nèi)置的服務(wù)器端 Runtime 會識別監(jiān)聽的 TraitDefinition 注冊事件，然后將該能力納入平臺管理中。

這一步完成，KubeVela 就已經(jīng)注冊完畢在 KubeVela 平臺中可用了。但接下來我們還需要將它暴露給用戶使用，所以需要定義這個能力對外的使用接口。

Step 2：編寫 CUE template 來封裝對外暴露接口

實際上，大多數(shù)社區(qū)能力雖然很強大，但對于最終用戶來都比較復(fù)雜，學(xué)習(xí)和上手非常困難。所以在 KubeVela 中，它允許平臺管理員對能力做進一步封裝以便對用戶暴露簡單易用的使用接口，在絕大多數(shù)場景下，這些使用接口往往只有幾個參數(shù)就足夠了。在能力封裝這一步，KubeVela 選擇了 CUE 模板語言，來連接用戶界面和后端能力對象，并且天然就支持完全動態(tài)的模板綁定（即變更模板不需要重啟或者重新部署系統(tǒng)）。下面就是 KubeWatch Trait 的模板例子：

將這個模板放到 Definition 文件中并 $ kubectl apply -f 到 Kubernetes 中，KubeVela 就會自動識別和處理相關(guān)輸入。這時候，用戶就可以直接在 Appfile 中聲明使用剛加進來的能力了，比如發(fā)送告警信息到指定的 Slack channel：

可以看到，這個 kubewatch 的配置是我們通過三方擴展進來的一個新的能力，通過 KubeVela 平臺管理 Kubernetes 擴展能力就是這么簡單快速。有了 KubeVela，平臺開發(fā)人員就可以簡單快速地在 Kubernetes 上搭建起一個 PaaS，且能夠?qū)⑷魏我粋€ Kubernetes 能力快速封裝成面向最終用戶的上層抽象。

以上示例，僅僅是 KubeVela 可擴展性的“冰山一角”。在后續(xù)的文章中，我們會繼續(xù)詳細介紹 KubeVela 能力裝配流程中更多的細節(jié)問題，比如：

• 如何定義能力之間的沖突關(guān)系與協(xié)作關(guān)系？
• 如何快速的定義 CUE 模板文件？
• 如何基于 CUE 語言定義出功能強大的“能力模塊”，然后把這些模塊安裝到 KubeVela 中？
• 等等 ……

總結(jié)

原生的可擴展性與能力裝配機制，是 KubeVela 與大多數(shù) PaaS 項目的根本性不同，這也導(dǎo)致 KubeVela 背后的實現(xiàn)和模型跟它們相比也有著本質(zhì)性的差異。所以說，KubeVela 的核心目標(biāo)，乃是在為用戶帶來簡單易用的應(yīng)用管理體驗的同時，為平臺管理員提供完全 Kubernetes 原生的可擴展性與靈活度。

KubeVela 項目是 OAM 社區(qū)的官方項目，由來自阿里、微軟多位云原生社區(qū)資深成員共同維護，同時也是阿里云 EDAS 服務(wù)和內(nèi)部多個雙十一級應(yīng)用管理平臺背后的核心組件。KubeVela 旨在構(gòu)建一個面向未來的云原生 PaaS 架構(gòu)，將橫向可擴展性和以應(yīng)用為中心這些最佳實踐帶給大家，推動甚至引領(lǐng)云原生社區(qū)在應(yīng)用層的發(fā)展。

想要了解更多？歡迎前往官方網(wǎng)站上學(xué)習(xí)更多示例：

• 前往學(xué)習(xí) KubeVela Quick Start（新手教程），一步步了解 KubeVela 的使用方法。
• 前往 OAM 社區(qū)深入交流和反饋。中文：釘釘群 23310022，英文：Gitter 和 CNCF Slack。

作者簡介

鄧洪超 阿里云高級技術(shù)專家， 人稱 “Kubernetes Operator 第二人”，OAM 與 KubeVela 項目核心維護者。

總結(jié)

以上是生活随笔為你收集整理的深入解读：KubeVela 与 PaaS 有何不同？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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