![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/7fea86ab543141aea3ea3e2147bcb057.png)

作者 | 鄧洪超  阿里雲高階技術專家

**來源|**[**阿里巴巴雲原生公眾號**](https://mp.weixin.qq.com/s/Ej_cXFgdhiWpMyjqHswauQ)

在 KubeVela 專案釋出以後，很多國內外的社群同學們都會問到一個類似的問題：KubeVela 的體驗真的非常棒，可以說是 Kubernetes 上的 Heroku 了。這麼看來， KubeVela 跟 Heroku 這樣的 PaaS 產品到底是不是一類專案呢？

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

> 備註：本文所提到的 PaaS，既包括 Heroku 這樣的經典 PaaS 產品，也包括各種各樣的基於 Kubernetes 的“雲原生” PaaS。它們雖然底層實現不同，但是對使用者提供的使用介面和體驗是相似的。但 OpenShift 是一個例外，作為一個比 Kubernetes 本身還複雜的專案，OpenShift 不屬於本文所討論的簡單易用、面向使用者的 PaaS 之列，而是一個地道的 Kubernetes 發行版。

首先，我們先說結論：**KubeVela 能夠為使用者帶來非常接近 PaaS 的體驗，但 KubeVela 並不是 PaaS**。

# 為什麼說 KubeVela 不是 PaaS？

大多數 PaaS 都能提供完整的應用生命週期管理功能，同時也非常關注提供簡單友好的使用者體驗，以及對研發效能的提升。在這些點上，KubeVela 跟 PaaS 的目標和提供的使用者體驗，是高度一致的。但如果你去研究 KubeVela 的實現細節，就不難發現 KubeVela 的整體設計與實現其實與各類 PaaS 專案的差別是非常大的。如果從使用者視角來看，這些區別則會直接反應在整個專案的“可擴充套件性”上。

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

比如：

- 能否幫助我執行一個 定時任務？
- 能不能幫我執行一個 OpenKruise 的 CloneSet 工作負載？
- 能不能幫我執行一個 MySQL Operator？
- 能不能根據我的自定義 metrics 來做水平擴容？
- 能不能基於 Flagger 和 Istio來幫我做漸進式灰度釋出？
- 能不能 ……

而這裡的關鍵點在於，上述這些能力在 Kubernetes 生態中都是非常常見的的能力，有的甚至是 Kubernetes 內建就可以支援。**可是到了 PaaS 這裡，要支援上述任何一個能力，都必須對 PaaS 進行一輪開發，而且由於先前的一些假設和設計，甚至很可能需要大規模的重構**。

舉個例子，我有一個 PaaS 系統，它所有的應用都是透過 Deployment 來執行的，那麼這個 PaaS 的釋出、擴容等功能，也都會直接按照 Deployment 來進行實現。而現在，使用者提出了原地升級的訴求，需要讓這個 PaaS 再支援 CloneSet，那整套系統很可能就得掀翻重來。再到運維能力這一側，這個問題會更加嚴重，比如現在這個 PaaS 支援的是藍綠髮布策略，那麼它跟流量管理、監控系統等依賴之間，都是需要大量互動和整合的。而現在我們要讓 PaaS 支援一個新的策略叫做“金絲雀”釋出，那麼所有的這些互動和執行邏輯基本全得重重構一遍，工作量是巨大的。

當然，並不是所有的 PaaS 都完全沒有可擴充套件性。工程能力比較強的 PaaS，比如 Cloud Foundry 和 Heroku，它們都提供了自己的外掛能力和外掛中心，在確保平臺本身的使用者體驗和能力的可控制性的前提下開放一定的外掛能力，比如允許使用者接入自己的資料庫，或者開發一些簡單的 Feature 進去。**但這種外掛機制無論怎麼做，說白了只能是這個 PaaS 專屬的封閉小生態能力**。而在雲原生時代，我們開源社群已經有了 Kubernetes 生態這樣一個近乎“無限”的能力池，在這個能力池面前，任何 PaaS 專屬的小生態都顯得太蒼白無力了。

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

![1.png](https://ucc.alicdn.com/pic/developer-ecology/21ecb54a12264a248fdffe0f6b00028a.png)

相比之下，KubeVela 的目標從一開始就是利用整個 Kubernetes 生態作為自己的“外掛中心”，並且“有意”把它的每一個內建能力都設計成獨立的、可插拔的外掛。這種高度可擴充套件的模型，背後其實有著精密的設計與實現。比如，KubeVela 如何確保某個完全獨立的 Trait 一定能夠繫結於某種 Workload Type？如何檢查這些相互獨立的 Trait 間是否存在衝突？這些挑戰正是 Open Application Model（OAM）作為 KubeVela 模型層的起到的關鍵作用，**一言以蔽之：OAM 是一個高度可擴充套件的應用定義與能力裝配模型**。

而且，大家設計和製作任何 Workload Type 和 Trait 的定義檔案，只要存放在 GitHub 上，全世界任何一個 KubeVela 使用者就都可以在自己的 Appfile 裡使用這些能力。具體的方式，請參考 $ vela cap （即：外掛能力管理命令）的[使用文件](https://kubevela.io/#/en/developers/cap-center)。

所以說，**KubeVela 提倡的是一種面向未來的雲原生平臺架構，這種架構認為**：

- 應用平臺本身架構徹底模組化，其所有的能力都是可插拔的，而平臺核心框架透過模型層提供標準化的能力封裝與裝配流程。
- 該流程能夠無縫接入雲原生生態中的任何應用管理能力，使得平臺工程師完全專注於能力本身的研發和基於該模型的能力封裝過程，使平臺團隊在為使用者帶來簡單易用的平臺層抽象的同時，快速、敏捷地響應使用者千變萬化的應用管理訴求。

# KubeVela 整體架構與能力可插拔機制

KubeVela 整體架構如下圖所示：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/df518bfd030843658ee0d900bba75b3d.png)

在架構上，KubeVela 只有一個 controller 並且以外掛的方式執行在 Kubernetes 之上，為 Kubernetes 帶來了面向應用層的抽象，以及以此為基礎的面向使用者的使用介面，即Appfile。Appfile 乃至 KubeVela 執行機制背後的核心，則是其能力管理模型 Open Application Model (OAM) 。基於這個模型，KubeVela 為系統管理員提供了一套基於註冊與自發現的能力裝配流程，來接入 Kubernetes 生態中的任意能力到 KubeVela 中，從而以“一套核心框架搭配不同能力”的方式，適配各種使用場景（比如 AI PaaS，資料庫 PaaS 等等）。

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

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

## Step 1：將平臺能力註冊為 OAM 物件

首先，你需要確定 CRD 所表示的能力是對應一個 Workload Type 還是 Trait？這裡的區別在於 Workload Type 指的是如何執行你的程式碼。而 Trait 指的是如何運維、管理或者操作已經執行起來的程式碼例項。

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

![3.png](https://ucc.alicdn.com/pic/developer-ecology/2279c379c83242678c7f6f68e600bddd.png)

KubeVela 內建的伺服器端 Runtime 會識別監聽的 TraitDefinition 註冊事件，然後將該能力納入平臺管理中。

這一步完成，KubeVela 就已經註冊完畢在 KubeVela 平臺中可用了。但接下來我們還需要將它暴露給使用者使用，所以需要定義這個能力對外的使用介面。

## Step 2：編寫 CUE template 來封裝對外暴露介面

實際上，大多數社群能力雖然很強大，但對於終端使用者來都比較複雜，學習和上手非常困難。所以在 KubeVela 中，它允許平臺管理員對能力做進一步封裝以便對使用者暴露簡單易用的使用介面，在絕大多數場景下，這些使用介面往往只有幾個引數就足夠了。在能力封裝這一步，KubeVela 選擇了 CUE 模板語言，來連線使用者介面和後端能力物件，並且天然就支援完全動態的模板繫結（即變更模板不需要重啟或者重新部署系統）。下面就是 KubeWatch Trait 的模板例子：

![4.png](https://ucc.alicdn.com/pic/developer-ecology/bdae6959d94742bb9c7f44459602a780.png)

將這個模板放到 Definition 檔案中並 $ kubectl apply -f 到 Kubernetes 中，KubeVela 就會自動識別和處理相關輸入。這時候，使用者就可以直接在 Appfile 中宣告使用剛加進來的能力了，比如傳送告警資訊到指定的 Slack channel：

![5.png](https://ucc.alicdn.com/pic/developer-ecology/cf231c8fe99442be885ac75623918732.png)

可以看到，這個 kubewatch 的配置是我們透過三方擴充套件進來的一個新的能力，透過 KubeVela 平臺管理 Kubernetes 擴充套件能力就是這麼簡單快速。有了 KubeVela，平臺開發人員就可以簡單快速地在 Kubernetes 上搭建起一個 PaaS，且能夠將任何一個 Kubernetes 能力快速封裝成面向終端使用者的上層抽象。

以上示例，僅僅是 KubeVela 可擴充套件性的“冰山一角”。在後續的文章中，我們會繼續詳細介紹 KubeVela 能力裝配流程中更多的細節問題，比如：

- 如何定義能力之間的衝突關係與協作關係？
- 如何快速的定義 CUE 模板檔案？
- 如何基於 CUE 語言定義出功能強大的“能力模組”，然後把這些模組安裝到 KubeVela 中？
- 等等 ……

# 總結

原生的可擴充套件性與能力裝配機制，是 KubeVela 與大多數 PaaS 專案的根本性不同，這也導致 KubeVela 背後的實現和模型跟它們相比也有著本質性的差異。所以說，KubeVela 的核心目標，乃是在**為使用者帶來簡單易用的應用管理體驗的同時，為平臺管理員提供完全 Kubernetes 原生的可擴充套件性與靈活度**。

KubeVela 專案是 OAM 社群的官方專案，由來自阿里、微軟多位雲原生社群資深成員共同維護，同時也是阿里雲 EDAS 服務和內部多個雙十一級應用管理平臺背後的核心元件。KubeVela 旨在構建一個面向未來的雲原生 PaaS 架構，將橫向可擴充套件性和以應用為中心這些最佳實踐帶給大家，推動甚至引領雲原生社群在應用層的發展。

想要了解更多？歡迎前往[官方網站](https://kubevela.io/)上學習更多示例：

- 前往學習 [KubeVela Quick Start（新手教程）](https://kubevela.io/#/en/quick-start)，一步步瞭解 KubeVela 的使用方法。
- 前往 OAM 社群深入交流和反饋。中文：釘釘群 23310022，英文：[Gitter](https://gitter.im/oam-dev/community) 和 [CNCF Slack](https://cloud-native.slack.com/archives/C01BLQ3HTJA)。

## 作者簡介

**鄧洪超  **阿里雲高階技術專家， 人稱 “Kubernetes Operator 第二人”，OAM 與 KubeVela 專案核心維護者。

深入解讀：KubeVela 與 PaaS 有何不同？

相關文章