美國西部時間 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 誕生以來並很少見。docker
什麼是 KubeVela ？
一言以蔽之，KubeVela 是一個簡單易用且高度可擴展的應用管理平臺與核心引擎。KubeVela 是基於 Kubernetes 與 OAM 技術構建的。數據庫
詳細的說，對於應用開發人員來說，KubeVela 是一個很是低心智負擔的雲原生應用管理平臺，核心功能是讓開發人員方便快捷地在 Kubernetes 上定義與交付現代微服務應用，無需瞭解任何 Kubernetes 自己相關的細節。在這一點上，KubeVela 能夠被認爲是雲原生社區的 Heroku。express
另外一方面，對於平臺團隊來說，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 專家）。app
這也是爲何在雲原生生態中，幾乎每個平臺團隊都會基於 Kubernetes 構建一個上層平臺給用戶使用。最簡單的也會給 Kubernetes 作一個圖形界面，稍微正式一些的則每每會基於 Kubernetes 開發一個類 PaaS 平臺來知足本身的需求。理論上講，在 Kubernetes 生態中各類能力已經很是豐富的今天，開發一個類 PaaS 平臺應該是比較容易的。less
然而現實卻每每不盡如人意。在大量的社區訪談當中，咱們發如今雲原生技術極大普及的今天，基於 Kubernetes 構建一個功能完善、用戶友好的上層應用平臺，依然是中大型公司們的「專利」。這裏的緣由在於：運維
Kubernetes 生態自己的能力池當然豐富，可是社區裏卻並無一個可擴展的、方便快捷的方式，可以幫助平臺團隊把這些能力快速「組裝」成面向最終用戶的功能（Feature）。
這種困境帶來的結果，就是儘管你們今天都在基於 Kubernetes 在構建上層應用平臺，但這些平臺本質上卻並不可以與 Kubernetes 生態徹底打通，而都變成一個又一個的垂直「煙囪」。ide
在開源社區中，這個問題會更加明顯。在今天的 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 裏使用你所設計的能力。
本文爲阿里雲原創內容，未經容許不得轉載。