【來源： 阿裡巴巴雲原生公衆号
】
美國西部時間 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 進群交流！