https://www.oschina.net/news/121015/kubevela-open-source

目錄

• • 什么是 KubeVela ？
  • KubeVela 解決了什么問題？
  • • 1. 應用開發者眼中的 KubeVela
    • • 一個 Appfile 示例
    • 2. 平臺工程師眼中的 KubeVela
    • 3. KubeVela vs 經典 PaaS
  • 快速入門
  • • 安裝KubeVela
    • • 1. 安裝Kubernetes 集群
      • 2. 獲取Kubevela

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

什么是 KubeVela ？

基于 Kubernetes 與 OAM 技術構建的，簡單易用且高度可擴展的應用管理平臺與核心引擎。核心思想是：
讓開發人員方便快捷地在 Kubernetes 上定義與交付現代微服務應用，無需了解任何 Kubernetes 本身相關的細節。在這一點上，KubeVela 可以被認為是云原生社區的 Heroku。

Heroku是支持多種編程語言的云平臺，在2010年被Salesforce.com收購幫助開發人員構建和發布Web應用程序，而無需擔心管理服務器、擴展操作或處理部署過程，支持Ruby、Java、Node.js、Python、PHP、GO等8種編程語言。

KubeVela 解決了什么問題？

讓平臺團隊在不造輪子、完全打通 Kubernetes 生態的前提下，輕松的構建面向用戶的上層平臺。

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

這也是為什么在云原生生態中，幾乎每一個平臺團隊都會基于 Kubernetes 構建一個上層平臺給用戶使用。最簡單的也會給 Kubernetes 做一個圖形界面，稍微正式一些的則往往會基于 Kubernetes 開發一個類 PaaS 平臺來滿足自己的需求。

KubeVela 對最終用戶和平臺團隊這兩種群體進行了單獨的畫像，以滿足他們不同的訴求。KubeVela 里的每一個功能，都是一個插件，平臺團隊可以輕松地“卸載”它的所有內置能力、然后“安裝”自己需要的任何社區能力，讓 KubeVela 變成一個完全不一樣的系統。

1. 應用開發者眼中的 KubeVela

讓開發者以極低的心智負擔和上手成本在 Kubernetes 上定義與部署應用。而關于整個系統的使用，開發者只需要編寫一個 docker-compose 風格應用描述文件 Appfile 即可，不需要接觸和學習任何 Kubernetes 層的相關細節。

一個 Appfile 示例

vela.yaml 的 Appfile 放在你的應用代碼目錄中（比如應用的 GitHub Repo）。這個 Appfile 定義了：

• 如何將這個應用編譯成 Docker 鏡像
• 如何將鏡像部署到 Kubernetes
• 如何配置外界訪問應用的路由和域名
• 如何讓 Kubernetes 自動根據 CPU 使用量來水平擴展這個應用
  
  只要有了這個 20 行的配置文件，接下來唯一需要的事情就是:
  $ vela up
  這個應用就會被部署到 Kubernetes 中然后被外界以 https://example.com/testapp 的方式訪問到。

這個 Appfile 是沒有固定的 Schema 的，意思是基于這種模塊化的設計，Appfile 本身是高度可擴展的。里面能夠填寫的每一個字段，直接取決于當前平臺中有哪些工作負載類型（Workload Types）和可用的應用特征（Traits）。這是核心概念，其中：

• 工作負載類型（Workload Type），定義的是底層基礎設施如何運行這個應用。
• 應用特征（Traits），則為工作負載實例加上了運維時配置。

在上面的例子中：

• 名叫 testapp 的應用會啟動一個類型為“在線 Web 服務（Web Service）” 的工作負載，其實例的名字是 express-server。
• 定義了一個 Route Trait 來描述應用如何被從外界訪問，以及一個 Autoscale Trait 來描述應用如何根據 CPU 使用量進行自動的水平擴容。

當任何新的 Workload Type 或者 Trait 被安裝到平臺后，用戶可以立刻在 Appfile 里聲明使用這個新增的能力。

舉個例子，比如后面平臺團隊新開發了一個用來配置應用監控屬性的運維側能力，叫做 Metrics。那么應用開發者就可以立刻使用：
$ vela show metrics
命令查看這個新增能力的詳情，并且在 Appfile 中使用它，如下所示：

這種簡單友好、又高度敏捷的使用體驗，正是 KubeVela 在最終用戶側提供的主要體感。
通過 KubeVela 部署的應用會被自動設置好訪問 URL（以及不同版本對應的不同 URL），并且會由 cert-manager 生成好證書。與此同時，KubeVela 還提供了一系列輔助命令（比如：vela logs 和 vela exec）來幫助你在無需成為 Kubernetes 專家的情況下更好地管理和調試你的應用。

2. 平臺工程師眼中的 KubeVela

KubeVela 不是一個簡單的 PaaS 或者 Serverless，而是一個可以由平臺工程師擴展成任意垂直系統的云原生平臺內核，提供了三大核心能力：

第一：以應用為中心，讓“應用”這個概念成為了整個平臺對用戶暴露的核心 API。因此，基于 KubeVela 擴展和構建出來的平臺，天然是用戶友好的：對于一個開發者來說，他只關心“應用”，而不是容器或者 Kubernetes；而 KubeVela 會確保構建整個平臺的過程，也只與應用層的需求有關。

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

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

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

3. KubeVela vs 經典 PaaS

KubeVela 跟經典 PaaS 的設計目標是非常一致的，其優勢體現在擴展性上。經典 PaaS 往往是不可擴展的，或者會引入屬于自己的插件生態（哪怕這個 PaaS 是完全基于 Kubernetes 構建的），以此來確保平臺本身的用戶體驗和能力的可控制性（比如 Cloud Foundry 或者 Heroku 的插件中心）。

這種高度可擴展的模型背后有著精密的設計與實現。比如：

• KubeVela 如何確保某個完全獨立的 Trait 一定能夠綁定于某種 Workload Type？
• 如何檢查這些相互獨立的 Trait 是否沖突？

這些挑戰，正是 Open Application Model（OAM）作為 KubeVela 模型層的起到的關鍵作用，一言以蔽之：OAM 是一個高度可擴展的應用定義與能力管理模型。

快速入門

https://kubevela.io/#/en/install

安裝KubeVela

1. 安裝Kubernetes 集群

要求：

• Kubernetes cluster >= v1.15.0
• kubectl 安裝并配置

對于沒有K8s集群或本地實驗的情況，需要安裝Minikube 或 安裝KinD。

2. 獲取Kubevela

獲取最新版vela。
解壓縮，路徑加到$PATH,

總結

以上是生活随笔為你收集整理的KubeVela 高可扩展的云原生应用平台与核心引擎的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。