美國西部時間 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 是基於 Kubernetes 與 OAM 技術構建的。
詳細的說，對於應用開發人員來講，KubeVela 是一個非常低心智負擔的雲原生應用管理平臺，核心功能是讓開發人員方便快捷地在 Kubernetes 上定義與交付現代微服務應用，無需了解任何 Kubernetes 本身相關的細節。在這一點上，KubeVela 可以被認為是雲原生社區的 Heroku。
另一方面，對於平臺團隊來講，KubeVela 是一個強大並且高可擴展的雲原生應用平臺核心引擎。基於這樣一個引擎，平臺團隊可以快速、高效地以 Kubernetes 原生的方式在 KubeVela 中植入任何來自雲原生社區的應用管理能力，從而基於 KubeVela 打造出自己需要的雲原生平臺，比如：雲原生資料庫 PaaS、雲原生 AI 平臺、甚至 Serverless 服務。在這一點上，KubeVela 可以被認為是一個「以應用為中心」的 Kubernetes 發行版，以 OAM 為核心，讓平臺團隊可以基於 KubeVela 快速打造出屬於自己的 PaaS、Serverless 乃至任何面向用戶的雲原生平臺項目。
現如今，雲原生技術的迅猛發展可能讓很多人都感覺到眼花繚亂，但實際上，這個生態的總體發展趨勢和主旋律，是通過 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 默認的功能集與「Heroku」類似（即：主要面向應用開發人員），所以在下文中，我們會以應用開發人員或者開發者來代替最終用戶。但我們很快也會講到，KubeVela 裡的每一個功能，都是一個插件，作為平臺團隊，你可以輕鬆地「卸載」它的所有內置能力、然後「安裝」自己需要的任何社區能力，讓 KubeVela 變成一個完全不一樣的系統。
前面已經提到，對於開發者來說，KubeVela 是一個簡單、易用、又高可擴展的雲原生應用管理工具，它可以讓開發者以極低的心智負擔和上手成本在 Kubernetes 上定義與部署應用。而關於整個系統的使用，開發者只需要編寫一個 docker-compose 風格應用描述文件 Appfile 即可，不需要接觸和學習任何 Kubernetes 層的相關細節。
在下述例子中，我們會將一個叫做 vela.yaml 的 Appfile 放在你的應用代碼目錄中（比如應用的 GitHub Repo）。這個 Appfile 定義了如何將這個應用編譯成 Docker 鏡像，如何將鏡像部署到 Kubernetes，如何配置外界訪問應用的路由和域名，又如何讓 Kubernetes 自動根據 CPU 使用量來水平擴展這個應用。
只要有了這個 20 行的配置文件，你接下來唯一需要的事情就是 $ vela up，這個應用就會被部署到 Kubernetes 中然後被外界以 https://example.com/testapp 的方式訪問到。
在 KubeVela 的 Appfile 背後，有著非常精妙的設計。首先需要指出的就是，這個 Appfile 是沒有固定的 Schema 的。
什麼意思呢？這個 Appfile 裡面你能夠填寫的每一個欄位，都是直接取決於當前平臺中有哪些工作負載類型（Workload Types）和應用特徵（Traits）是可用的。而熟悉 OAM 的同學都知道，這兩個概念，正是 OAM 規範的核心內容，其中：
而正是基於這種模塊化的設計，這個 Appfile 本身是高度可擴展的。當任何一個新的 Workload Type 或者 Trait 被安裝到平臺後，用戶就可以立刻在 Appfile 裡聲明使用這個新增的能力。舉個例子，比如後面平臺團隊新開發了一個用來配置應用監控屬性的運維側能力，叫做 Metrics。那麼只需要舉手之撈，應用開發者就可以立刻使用 $ vela show metrics 命令查看這個新增能力的詳情，並且在 Appfile 中使用它，如下所示：
這種簡單友好、又高度敏捷的使用體驗，正是 KubeVela 在最終用戶側提供的主要體感。
前面提到，一旦 Appfile 準備好，開發者只需要一句 vela up 命令就可以把整個應用連同它的運維特徵部署到 Kubernetes 中。部署成功後，你可以使用 vela status 來查看整個應用的詳情，包括如何訪問這個應用。
通過 KubeVela 部署的應用會被自動設置好訪問 URL（以及不同版本對應的不同 URL），並且會由 cert-manager 生成好證書。與此同時，KubeVela 還提供了一系列輔助命令（比如：vela logs 和 vela exec）來幫助你在無需成為 Kubernetes 專家的情況下更好地管理和調試你的應用。如果你對上述由 KubeVela 帶來的開發者體驗感興趣的話，歡迎前往 KubeVela 項目的用戶使用文檔來了解更多。
而接下來，我們要切換一下視角，感受一下平臺團隊眼中的 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 社區能力封裝抽象成一個面向用戶的上層平臺特性的強大工具。而作為這個平臺的最終用戶，應用開發者們只需要學習這些上層抽象，在一個配置文件中描述應用，就可以一鍵交付出去。
很多人可能會問，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 項目，歡迎前往其官方網站上學習具體的示例和手冊。以下也是一些非常好的學習內容和方式：