KubeVela 正式開源：一個高可擴展的雲原生應用平台與核心引擎

【來源：阿里巴巴雲原生公眾號】

美國西部時間 2020 年 11 月 18 日，在雲原生技術“最高盛宴”的 KubeCon 北美峰會 2020 上，CNCF 應用交付領域小組（CNCF SIG App Delivery) 與 Open Application Model (OAM) 社區，以及來自阿里雲、微軟雲的 OAM 項目維護者們在演講中共同宣布了** KubeVela 開源項目的正式發布**。

從 11 月 18 號到 20 號，在為期三天的 KubeCon 北美峰會上有連續 3 場技術演講，會從不同維度介紹關於 KubeVela 項目的具體細節，其中還包括一個長達 1 個半小時的 KubeVela 互動教學環節。多個重量級組織以如此規模和密度在 KubeCon 北美峰會演講中介紹一個首次發布的社區開源項目，在 KubeCon 誕生以來並不多見。

什么是 KubeVela ？

一言以蔽之，KubeVela 是一個簡單易用且高度可擴展的應用管理平台與核心引擎。KubeVela 是基於 Kubernetes 與 OAM 技術構建的。

詳細的說，對於應用開發人員來講，KubeVela 是一個非常低心智負擔的雲原生應用管理平台，核心功能是讓開發人員方便快捷地在 Kubernetes 上定義與交付現代微服務應用，無需了解任何 Kubernetes 本身相關的細節。在這一點上，KubeVela 可以被認為是雲原生社區的 Heroku。

另一方面，對於平台團隊來講，KubeVela 是一個強大並且高可擴展的雲原生應用平台核心引擎。基於這樣一個引擎，平台團隊可以快速、高效地以 Kubernetes 原生的方式在 KubeVela 中植入任何來自雲原生社區的應用管理能力，從而基於 KubeVela 打造出自己需要的雲原生平台，比如：雲原生數據庫 PaaS、雲原生 AI 平台、甚至 Serverless 服務。在這一點上，KubeVela 可以被認為是一個“以應用為中心”的 Kubernetes 發行版，以 OAM 為核心，讓平台團隊可以基於 KubeVela 快速打造出屬於自己的 PaaS、Serverless 乃至任何面向用戶的雲原生平台項目。

KubeVela 解決了什么問題？

現如今，雲原生技術的迅猛發展可能讓很多人都感覺到眼花繚亂，但實際上，這個生態的總體發展趨勢和主旋律，是通過 Kubernetes 搭建了一個統一的基礎設施抽象層，為平台團隊屏蔽掉了“計算”、“網絡”、“存儲”等過去我們不得不關注的基礎設施概念，使得我們能夠基於 Kubernetes 方便地構建出任何我們想要的垂直業務系統而無需關心任何基礎設施層的細節。這正是 Kubernetes 被稱為雲計算界的 Linux 以及 “Platform for Platforms” 的根本原因。

但是，當我們把視角從平台團隊提升到垂直業務系統的最終用戶（如：應用開發人員）的時候，我們會發現 Kubernetes 這樣的定位和設計在解決了平台團隊的大問題之后，卻也為應用開發者們帶來了挑戰和困擾。比如，太多的用戶都在抱怨 Kubernetes “太復雜了”。究其原因，其實在於 Kubernetes 中的核心概念與體系，如：Pod、sidecar、Service、資源管理、調度算法和 CRD 等等，主要是面向平台團隊而非最終用戶設計的。缺乏面向用戶的設計不僅帶來了陡峭的學習曲線，影響了用戶的使用體驗，拖慢了研發效能，甚至在很多情況下還會引發錯誤操作乃至生產故障（畢竟不可能每個業務開發人員都是 Kubernetes 專家）。

這也是為什么在雲原生生態中，幾乎每一個平台團隊都會基於 Kubernetes 構建一個上層平台給用戶使用。最簡單的也會給 Kubernetes 做一個圖形界面，稍微正式一些的則往往會基於 Kubernetes 開發一個類 PaaS 平台來滿足自己的需求。理論上講，在 Kubernetes 生態中各種能力已經非常豐富的今天，開發一個類 PaaS 平台應該是比較容易的。

然而現實卻往往不盡如人意。在大量的社區訪談當中，我們發現在雲原生技術極大普及的今天，基於 Kubernetes 構建一個功能完善、用戶友好的上層應用平台，依然是中大型公司們的“專利”。這里的原因在於：

Kubernetes 生態本身的能力池固然豐富，但是社區里卻並沒有一個可擴展的、方便快捷的方式，能夠幫助平台團隊把這些能力快速“組裝”成面向最終用戶的功能（Feature）。

這種困境帶來的結果，就是盡管大家今天都在基於 Kubernetes 在構建上層應用平台，但這些平台本質上卻並不能夠與 Kubernetes 生態完全打通，而都變成一個又一個的垂直“煙囪”。

在開源社區中，這個問題會更加明顯。在今天的 Kubernetes 社區中，不乏各種“面向用戶”、“面向應用”的 Kubernetes 上層系統。但正如前文所述，這些平台都無一例外的引入了自己的專屬上層抽象、用戶界面和插件機制。這里最典型的例子包括經典 PaaS 項目比如 Cloud Foundry，也包括各種 Serverless 平台。作為一個公司的平台團隊，我們實際上只有兩個選擇：要么把自己局限在某種垂直的場景中來適配和采納某個開源上層平台項目；要么就只能自研一個符合自己訴求的上層平台並且造無數個社區中已經存在的“輪子”。

那么，有沒有”第三種選擇”能夠讓平台團隊在不造輪子、完全打通 Kubernetes 生態的前提下，輕松的構建面向用戶的上層平台呢？

KubeVela 如何解決上述問題？

KubeVela 項目的創立初衷，就是以一個統一的方式同時解決上述最終用戶與平台團隊所面臨的困境。這也是為何在設計中，KubeVela 對最終用戶和平台團隊這兩種群體進行了單獨的畫像，以滿足他們不同的訴求。

由於 KubeVela 默認的功能集與“Heroku”類似（即：主要面向應用開發人員），所以在下文中，我們會以應用開發人員或者開發者來代替最終用戶。但我們很快也會講到，KubeVela 里的每一個功能，都是一個插件，作為平台團隊，你可以輕松地“卸載”它的所有內置能力、然后“安裝”自己需要的任何社區能力，讓 KubeVela 變成一個完全不一樣的系統。

1. 應用開發者眼中的 KubeVela

前面已經提到，對於開發者來說，KubeVela 是一個簡單、易用、又高可擴展的雲原生應用管理工具，它可以讓開發者以極低的心智負擔和上手成本在 Kubernetes 上定義與部署應用。而關於整個系統的使用，開發者只需要編寫一個 docker-compose 風格應用描述文件 Appfile 即可，不需要接觸和學習任何 Kubernetes 層的相關細節。

1）一個 Appfile 示例

在下述例子中，我們會將一個叫做 vela.yaml 的 Appfile 放在你的應用代碼目錄中（比如應用的 GitHub Repo）。這個 Appfile 定義了如何將這個應用編譯成 Docker 鏡像，如何將鏡像部署到 Kubernetes，如何配置外界訪問應用的路由和域名，又如何讓 Kubernetes 自動根據 CPU 使用量來水平擴展這個應用。

只要有了這個 20 行的配置文件，你接下來唯一需要的事情就是 $ vela up，這個應用就會被部署到 Kubernetes 中然后被外界以 https://example.com/testapp 的方式訪問到。

2）Appfile 是如何工作的？

在 KubeVela 的 Appfile 背后，有着非常精妙的設計。首先需要指出的就是，這個 Appfile 是沒有固定的 Schema 的。

什么意思呢？這個 Appfile 里面你能夠填寫的每一個字段，都是直接取決於當前平台中有哪些工作負載類型（Workload Types）和應用特征（Traits）是可用的。而熟悉 OAM 的同學都知道，這兩個概念，正是 OAM 規范的核心內容，其中：

• 工作負載類型（Workload Type），定義的是底層基礎設施如何運行這個應用。在上面的例子中，我們聲明：名叫 testapp 的應用會啟動一個類型為“在線 Web 服務（Web Service）” 的工作負載，其實例的名字是 express-server。

• 應用特征（Traits），則為工作負載實例加上了運維時配置。在上面的例子中，我們定義了一個 Route Trait 來描述應用如何被從外界訪問，以及一個 Autoscale Trait 來描述應用如何根據 CPU 使用量進行自動的水平擴容。

而正是基於這種模塊化的設計，這個 Appfile 本身是高度可擴展的。當任何一個新的 Workload Type 或者 Trait 被安裝到平台后，用戶就可以立刻在 Appfile 里聲明使用這個新增的能力。舉個例子，比如后面平台團隊新開發了一個用來配置應用監控屬性的運維側能力，叫做 Metrics。那么只需要舉手之撈，應用開發者就可以立刻使用 $ vela show metrics 命令查看這個新增能力的詳情，並且在 Appfile 中使用它，如下所示：

這種簡單友好、又高度敏捷的使用體驗，正是 KubeVela 在最終用戶側提供的主要體感。

3）Vela Up 命令

前面提到，一旦 Appfile 准備好，開發者只需要一句 vela up 命令就可以把整個應用連同它的運維特征部署到 Kubernetes 中。部署成功后，你可以使用 vela status 來查看整個應用的詳情，包括如何訪問這個應用。

通過 KubeVela 部署的應用會被自動設置好訪問 URL（以及不同版本對應的不同 URL），並且會由 cert-manager 生成好證書。與此同時，KubeVela 還提供了一系列輔助命令（比如：vela logs 和 vela exec）來幫助你在無需成為 Kubernetes 專家的情況下更好地管理和調試你的應用。如果你對上述由 KubeVela 帶來的開發者體驗感興趣的話，歡迎前往 KubeVela 項目的用戶使用文檔來了解更多。

而接下來，我們要切換一下視角，感受一下平台團隊眼中的 KubeVela 又是什么樣子的。

2. 平台工程師眼中的 KubeVela

實際上，前面介紹到的所有開發者側體驗，都離不開 KubeVela 在平台側進行的各種創新性設計與實現。也正是這些設計的存在，才使得 KubeVela 不是一個簡單的 PaaS 或者 Serverless，而是一個可以由平台工程師擴展成任意垂直系統的雲原生平台內核。

具體來說，KubeVela 為平台工程師提供了三大核心能力，使得基於 Kubernetes 構建上述面向用戶的雲原生平台從“陽春白雪”變成了“小菜一碟”：

第一：以應用為中心。在 Appfile 背后，其實就是“應用”這個概念，它是基於 OAM 模型實現的。通過這樣的方式，KubeVela 讓“應用”這個概念成為了整個平台對用戶暴露的核心 API。KubeVela 中的所有能力，都是圍繞着“應用”展開的。這正是為何基於 KubeVela 擴展和構建出來的平台，天然是用戶友好的：對於一個開發者來說，他只關心“應用”，而不是容器或者 Kubernetes；而 KubeVela 會確保構建整個平台的過程，也只與應用層的需求有關。

第二：Kubernetes 原生的高可擴展性。在前面我們已經提到過，Appfile 是一個由 Workload Type 和 Trait 組成的、完全模塊化的對象。而 OAM 模型的一個特點，就是任意一個 Kubernetes API 資源，都可以直接基於 Kubernetes 的 CRD 發現機制注冊為一個 Workload Type 或者 Trait。這種可擴展性，使得 KubeVela 並不需要設計任何“插件系統”：KubeVela 里的每一個能力，都是插件，而整個 Kubernetes 社區，就是 KubeVela 原生的插件中心。

第三：簡單友好但高度可擴展的用戶側抽象體系。在了解了 Appfile 之后，你可能已經對這個對象的實現方式產生了好奇。實際上，KubeVela 中並不是簡單的實現了一個 Appfile。在平台層，KubeVela 在 OAM 模型層實現中集成了 CUELang 這種簡潔強大的模板語言，從而為平台工程師基於 Kubernetes API 對象定義用戶側抽象（即：“最后一公里”抽象）提供了一個標准、通用的配置工具。更重要的是，平台工程師或者系統管理員，可以隨時隨地的每個能力對應的 CUE 模板進行修改，這些修改一旦提交到 Kubernetes，用戶在 Appfile 里就可以立刻使用到新的抽象，不需要重新部署或者安裝 KubeVela。

在具體實現層，KubeVela 是基於 OAM Kubernetes Runtime 構建的，同時采用 KEDA ，Flagger，Prometheus 等生態項目作為 Trait 的背后的依賴。當然，這些依賴只是 KubeVela 的選型，你可以隨時為 KubeVela 定制和安裝你喜歡的任何能力作為 Workload Type 或者 Trait。綜合以上講解，KubeVela 項目的整體架構由用戶界面層，模型層，和能力管理層三部分組成，如下所示：

有了 KubeVela，平台工程師終於擁有了一個可以方便快捷地將任何一個 Kubernetes 社區能力封裝抽象成一個面向用戶的上層平台特性的強大工具。而作為這個平台的最終用戶，應用開發者們只需要學習這些上層抽象，在一個配置文件中描述應用，就可以一鍵交付出去。

3. KubeVela VS 經典 PaaS

很多人可能會問，KubeVela 跟經典 PaaS 的主要區別和聯系是什么呢？

事實上，大多數經典 PaaS 都能提供完整的應用生命周期管理功能，同時也非常關注提供簡單友好的用戶體驗，提升研發效能。在這些點上，KubeVela 跟經典 PaaS 的目標，是非常一致的。

但另一方面，經典 PaaS 往往是不可擴展的（比如 Rancher 的 Rio 項目），或者會引入屬於自己的插件生態（哪怕這個 PaaS 是完全基於 Kubernetes 構建的），以此來確保平台本身的用戶體驗和能力的可控制性（比如 Cloud Foundry 或者 Heroku 的插件中心）。

相比之下，KubeVela 的設計是完全不同的。KubeVela 的目標，從一開始就是利用整個 Kubernetes 社區作為自己的“插件中心”，並且“故意”把它的每一個內置能力都設計成是獨立的、可插拔的插件。這種高度可擴展的模型，背后其實有着精密的設計與實現。比如，KubeVela 如何確保某個完全獨立的 Trait 一定能夠綁定於某種 Workload Type？如何檢查這些相互獨立的 Trait 是否沖突？這些挑戰，正是 Open Application Model（OAM）作為 KubeVela 模型層的起到的關鍵作用，一言以蔽之：OAM 是一個高度可擴展的應用定義與能力管理模型。

KubeVela 和 OAM 社區歡迎大家設計和制作任何 Workload Type 和 Trait 的定義文件。只要把它們存放在 GitHub 上，全世界任何一個 KubeVela 用戶就都可以在自己的 Appfile 里使用你所設計的能力。具體的方式，請參考 $ vela cap （即：插件能力管理命令）的使用文檔。

了解更多

KubeVela 項目是 OAM 社區的官方項目，旨在取代原先的 Rudr 項目。不過，與 Rudr 主要作為“參考實現”的定位不同，KubeVela 既是一個端到端、面向全量場景的 OAM Kubernetes 完整實現，同時也是阿里雲 EDAS 服務和內部多個核心 PaaS/Serverless 生產系統底層的核心組件。此外，KubeVela 中 Apppfile 的設計，也是 OAM 社區在 OAM 規范中即將引入的“面向用戶側對象”的核心部分。

如果你想要更好的了解 KubeVela 項目，歡迎前往其官方網站上學習具體的示例和手冊。以下也是一些非常好的學習內容和方式：

• 前往學習 KubeVela Quick Start（新手教程），一步步了解 KubeVela 的使用方法。

• 前往 OAM 社區深入交流和反饋。中文：釘釘群 23310022，英文：Gitter 和 CNCF Slack。

• 嘗試為 KubeVela 添加來自開源社區的插件能力。此外，如果你有任何關於擴展 KubeVela 的奇妙想法，比如，基於 KubeVela 開發一個自己的雲原生數據庫場景 PaaS 或者 AI 場景 PaaS，歡迎前往 OAM 社區通過 Issue 來進行討論。

• 為 KubeVela 貢獻代碼。KubeVela 項目是一個誕生自雲原生社區的開源項目（感謝來自 8 家不同公司的初始貢獻者，並特別鳴謝 KubeVela 網站的發起者 guoxudong）。KubeVela 項目的維護者會在項目穩定后，即將整個項目所有權捐贈給中立開源基金會。

如果你有任何疑問，歡迎釘釘搜索群號：23310022 進群交流！