![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/53035c23a1104a77ba1fd66c781451d5.png)

作者 | 孫健波（天元）
來源 | 阿里巴巴雲原生公眾號

如今，圍繞 Kubernetes 構建應用交付平臺已經逐漸成為共識。

Kubernetes 生態本身的能力池固然是豐富的，但社群裡並沒有一個可擴充套件的、方便快捷的方式，能夠幫助平臺團隊把這些能力快速“組裝”成面向終端使用者的功能（Feature）。因此，儘管大家都在基於 Kubernetes 構建上層應用平臺，但這些平臺本質上並不能與 Kubernetes 生態完全打通，而是變成一個個的垂直“煙囪”。

有沒有方法讓平臺團隊能夠在不造輪子、完全打通 Kubernetes 生態的前提下構建上層平臺，從而同時保證平臺的易用性和可擴充套件性呢？本文整理自阿里雲容器技術專家、OAM 規範主要制定者之一、KubeVela 作者和負責人孫健波（天元）在阿里雲開發者社群“週二開源日”的直播分享，將剖析當前 Kubernetes  應用交付體系存在的問題詳細介紹如何基於 OAM 和 KubeVela 體系賦能 PaaS，構建開放可擴充套件又易用的能力。

**點選回看完整影片：**[https://developer.aliyun.com/live/246067](https://developer.aliyun.com/live/246067)

# 什麼是 KubeVela

## 1. KubeVela 的起源

KubeVela是一個簡單易用又高度可擴充套件的雲原生應用管理引擎，是基於 Kubernetes 及阿里雲與微軟雲共同釋出的雲原生應用開發模型 OAM 構建。

KubeVela 基於 OAM 模型構建了一套具體的實現，透過 Golang 編寫，可以端到端地為使用者構建雲原生應用的平臺，提供一個相對完整的解決方案。

KubeVela 專案自 2020 年 7 月份在社群裡面發起，受到包括阿里、微軟、Crossplane 等公司工程師在內的廣大社群志願者的歡迎，並一起投入到專案開發工作中。他們把在 OAM 實踐裡面的各種經驗與教訓，都總結沉澱到 KubeVela 專案中。

![1.jpg](https://ucc.alicdn.com/pic/developer-ecology/fde27585999a4b77aad584d9f0171a59.jpg)

KubeVela 在 2020 年 11 月中旬正式釋出，並於釋出的第 4 天登頂 Github Go 趨勢榜榜首。這個專案的魅力在於，一方面專案本身比較容易理解，因為大家剛看到 OAM 釋出時，並不知道這個模型能夠做什麼，但是 KubeVela 提供許多開箱即用的功能以及可以實際操作的 Demo，使得大家更容易理解 OAM 模型以及 KubeVela 應用管理的能力。另一方面是由於許多使用者在應用管理方面的訴求越來越強烈，尤其是雲原生應用管理。

## 2. KubeVela 的使用者

![2.jpg](https://ucc.alicdn.com/pic/developer-ecology/449523b6405c4751ad2608c8dc403384.jpg)

KubeVela 的使用者主要面向的是平臺團隊，它為平臺團隊提供了一套模型，使得平臺團隊的業務使用者可以透過簡單易用的方式管理其應用。

在 KubeVela 出現之前，傳統的 K8s 平臺團隊的主要職責可以理解為基於 Kubernetes 為使用者構建應用管理平臺。在實際操作中，有一些平臺團隊是直接向外暴露了裸 Kubernetes 的概念，但這種做法通常會帶來一些問題，最突出的就是使用者使用門檻高，不易理解。

針對這類問題，KubeVela 提供了一層統一的方式。主要包含兩類别範本，一類是基於能力的模板，包含工作負載型別，例如將一些概念封裝成 Web Service，一些概念封裝成 Database。還包含運維特徵，是基於這些工作負載的擴充套件，特徵包括金絲雀釋出、自動擴縮容、路由訪問等能力。

另外一類是部署環境模板。例如使用者在釋出應用前要先進行測試，測試完成後進行小流量的叢集灰度釋出，最後再慢慢灰度到生產叢集，這些不同的叢集對應的能力不一樣。基於這兩個方面的模板，我們將它註冊到 CRD 註冊中心裡面，構成 KubeVela的完整能力池。

對於平臺團隊的業務使用者，即平臺團隊服務的一些應用開發者，這類開發者聚焦業務實現，對 Kubernetes 的細節並不關心。在這樣的前提下，開發者可以首先基於我們提供的環境模板，根據自己的實際需求選擇並初始化部署環境。然後再選擇能力模板，根據應用的工作負載，填寫運維特徵等引數。

最後由 KubeVela 進行組裝渲染，變成 Kubernetes 的實際資源。

可以看到，KubeVela 為這兩類使用者各自提供了一些能力，平臺團隊可以直接使用 Kubernetes 的概念組裝出來一些能力的抽象，應用開發者們可以基於這些抽象構建出應用。

# KubeVela 的能力

KubeVela主要有三個能力：

- 快速構建抽象

- 快速構建使用者使用介面

- 以“應用為中心”的方式統一定義和管理雲資源

下面對這三個能力的實現原理進行分析。

## 1. 快速構建抽象

### 1）抽象的型別

在之前我們提到，使用者在使用 K8s 時有一個很大的 Gap，這個 Gap 實際上是可以透過抽象來解決的。

抽象是構建雲原生應用平臺的基礎，抽象本質上分為這三種型別：轉換抽象（一變一）、組合抽象（一變多）和拆分抽象（多變一），以及抽象後的狀態迴流。

![3.jpg](https://ucc.alicdn.com/pic/developer-ecology/81475cfe66e14bd6b55b2e8ffdb857d4.jpg)

- 組合抽象

以一個網路訪問的服務為例，底下由 Deployment 與 Service 組合構建而成，使用者希望拿到工作負載 WebService，這樣一個組合的抽象可以給使用者提供服務。

- 拆分抽象

當我們在灰度釋出時，K8s 生態經常會出現一些像 ArgoRollout 的釋出能力，這些釋出能力可能有個問題，就是把所有的概念全都糅雜在一起，有時使用者在一開始使用時不關心的釋出策略（如 Rollout）也在其中。“拆分抽像”的能力可以使使用者在使用時把這些概念拆開來使用，在單獨使用 Workload 部分時，應用也能正常執行，而不是說一定要填完 ArgoRollout。同時未來灰度釋出時，使用者如果希望有金絲雀的釋出策略，KubeVela 也能將 Workload 與 Rollout 組裝成 ArgoRollout。

- 轉換抽象

在K8s原來的概念中，有的部分使用者並不關心，如 Deployment 裡的 labelSelectors。KubeVela 可以做一層轉換，就像 Knative Revision，去掉多餘的引數，封裝出乾淨的模型。

透過以上三種方式，KubeVela 可以為使用者提供一個簡潔易用的應用管理介面。

講到這裡，可能會有人拿 KubeVela 與 Helm 做比較了，那麼它們的區別是什麼？Helm 大家比較熟悉，它可以把不同的 YAML 檔案寫成模板，模板裡面能摳出來一些 Values，然後填寫一些 Values 的資訊。但是這裡 Helm 有一個問題，就是組裝完後 Helm 整體會成為一個黑盒，使用者無法獲得 Helm 裡整體的狀態。

舉一個例子，Helm 安裝完後，它把這些抽象的能力變成K8s原始的資源，但這些資源是否安裝成功，Helm 很難獲得感知。

同時使用者如果想做統一的能力，如要把 Rollout 抽出來的概念變成公共的功能給 WebService 與 Knative Revision 使用，這種情況在 Helm 中無法實現，包括後期做統一的監控、統一的釋出管理、統一的日誌管理、統一的擴縮容等，Helm 均無法實現。但是在 KubeVela 中，基於 OAM 模型提供的公共標準，就可以實現一些公共的能力。

所以說，像狀態迴流和公共能力抽象是HELM無法做到的兩點，但用KubeVela可以很容易做到。

### 2）KubeVela 對於抽象的實現：DCL(Data Configuration Language)

大家知道，Helm 的抽象能力是基於 Go 的 template，而 KubeVela 對於抽象的實現是則基於 DCL（DataConfiguration Language）。Kubernetes 的前身是 Borg，它在谷歌大規模使用時，有一個類似於指令碼的配置語言 BorgConfig，然後它對外開源的版本可以理解成一個 CUE，即 DCL。

CUE 的功能如下圖所示：

![4.jpg](https://ucc.alicdn.com/pic/developer-ecology/8fd8cd1b03d84cb3a795cbeaf5b79408.jpg)

首先使用者填抽象資料，接著透過 CUE 的模板註冊在 KubeVela 的服務端，然後使用者填的資料和模板直接合並，最後生成一個完整的 K8sYAML。這種過程看起來和 Helm 的 Go template 以及 Helm 的 Values 很像，但是 CUE 有很多強大的功能，比如：

- 專注於操縱資料，而不是寫程式碼
- 完全相容 JSON
- 簡單直觀：Schema 和 Value 語法一致

之前大家在 K8s 上做一些擴充套件時，通常情況下要寫一個 CRD，現在有了 KubeVela 這個引擎，在多數場景下構建抽象就不需再編寫程式碼了，只要註冊 CUE 配置即可使用。

![5.jpg](https://ucc.alicdn.com/pic/developer-ecology/ff5fa0b9d88640e5a414218f8f680f20.jpg)

以上方為例，首先定義 Workload， WorkloadDefinition 實際上就是一個模板，這個模板講的是工作負載裡一個 Deployment 模板，Deployment 下面是我們構建出來的引數 Parameter，它包含兩個引數 Image 和 CMD；之後相當於把這個引數填到了 ③ 上面的工作負載中，它的型別叫 Worker，也就是 ① 裡面的 Worker。

同時還有一些抽離出來的引數，就是底下的 Deployment 裡面，比如 Sidecar，把它抽出來單獨使用變成一個 Trait，Trait 裡面可以寫一些內容如 NAME 或 Image。如果不加 Trait，單獨使用 Worker 也是完全可以的。同時這個 Trait 也可以給到其他基於 Development 或帶有 “spec：template:spec:containers” 這種陣列模式的工作負載使用。

在 KubeVela 中，使用者只要簡單填寫引數就會拿到這兩個模板，然後在 KubeVela 中做 Merge，即 Patch 的合併，最後生成 Development。

## 2. 快速構建使用者使用介面

### 1）Appfile

除了構建抽象，如何讓使用者使用也是一個非常關鍵的問題。在這裡 KubeVela 給大家提供一個使用者層的視角，對於不關心 K8s 細細的業務應用研發者， KubeVela 提供了 AppFile 的概念。

![6.jpg](https://ucc.alicdn.com/pic/developer-ecology/1ccaf0aee40d4cbe8edf3feef88b82f7.jpg)

如上圖所示，Appfile 裡會包含映象的構建、映象如何啟動、埠是怎樣的、資源有多少等資訊。同時包含了一些 Trait 的引數，例如使用者希望能夠對外的訪問提供一個域名、自動擴縮容的引數等，大家可以看到它是圍繞應用展開的，沒有一些多餘的概念。同時它是一個檔案，當使用者在程式碼倉庫裡做統一變更時，體驗效果非常好；同時它和應用環境沒有關係，可以自動適配任意 K8s 叢集與部署環境，並且具有很好的擴充套件能力。

總結 Appfile 概念如下：

- 一個完整的應用描述檔案（以應用為中心）；

- 放置於應用程式碼庫中（Gitops 友好）；

- $ vela up（一鍵部署）；

- 無需學習 K8s 細節（完整的使用者側抽象）；

- 自動適配任意 K8s 叢集與部署環境（環境無關）。

### 2）示例：上線新功能 Metrics

具體流程如下所示。

- 平臺研發團隊：

- 開發了一個新 Operator 叫做 Metrics（監控）。
   - 編寫一個 K8s 能力描述檔案 metrics.yaml（如下方所示）。

![7.jpg](https://ucc.alicdn.com/pic/developer-ecology/9c546bb9cedf418d9cfab4f6187481d3.jpg)

- 平臺管理員：執行 $ kubectl apply -f metrics.yaml。

- 使用者：立刻就可以在 Appfile 中定義一個新的欄位 Metrics（如下方所示）；無需系統更新或重啟。

![8.jpg](https://ucc.alicdn.com/pic/developer-ecology/0c54c4d570424b5589c6533d2501130b.jpg)

對於業務使用者來說，不需要做任何系統的更新或重啟，就可以看到這個 metrics 的能力，同時在 Appfile 裡拿到擴充套件能力的填寫規範，輕鬆地用起來。

### 3）業務使用者使用 KubeVela 的工作流程

大致分為四個步驟：

- 首先執行 vela init 命令，回答問題生成基礎 Appfile。

![9.jpg](https://ucc.alicdn.com/pic/developer-ecology/ccc9e7e0caec4c2c949760a8c21a8858.jpg)

- 透過 vela traits 檢視平臺能力，vela show metrics 檢視能力細節。

![10.jpg](https://ucc.alicdn.com/pic/developer-ecology/5db91c433f1f41f5ad277e9554155374.jpg)

- 根據能力的引數編輯 Appfile。

![11.jpg](https://ucc.alicdn.com/pic/developer-ecology/1514089b08eb4dc185ff226a008b7680.jpg)

- 最後，透過 vela up 命令啟動應用。

![12.jpg](https://ucc.alicdn.com/pic/developer-ecology/ca18d686d4f748059dc66340c83fda47.jpg)

### 4）Dashboard/Restful API 支援類似機制

![13.jpg](https://ucc.alicdn.com/pic/developer-ecology/380bafc7427048b1adf0cd0c82e4ece8.jpg)

如上圖所示，透過註冊 Definition 檔案，Vela 會提供一個 jsonschema 的 API 包含的引數資訊，這樣就可以自動生成前端。同時 Vela 裡面也會有一個前端的功能，大家可以參照這個來做一些實現。

## 3. 統一定義和管理雲資源

### 1）實現原理

![14.jpg](https://ucc.alicdn.com/pic/developer-ecology/5088723b6bbb4e84b106518aca722535.jpg)

在管理雲資源方面，尤其是對對不同雲資源管理的統一，社群裡比較流行的一個專案叫 Terraform。Terraform 有很多 Package，這些 Package 對應不同雲廠商的雲資源的驅動，即不同的雲資源都可以透過 Input一個Terraform  Package，然後再填一些引數，就可以完成啟動。

KubeVela 和 Terraform 有非常好的聯動。當使用者用 workload defination 定義一個類似於 Terraform  Package 之後，把相應引數填入，最後定義使用者應該填的是什麼。上圖右方可以看到，根據 Terraform 定義出來的引數，業務研發人員其實還是填簡單的 Appfile，使用者體驗和剛剛基於直接 Kubernetes 抽象的體驗是一樣的。

在使用者正常使用資料庫時，可以在 configRef 裡填一些配置的引用，這些引用來自 sample-db，填入後 KubeVela 會把 Terraform 的資源拉起，然後同時把獲得的資源輸出，加入 configRef 中，最後生成一個應用，如下圖所示。

![15.jpg](https://ucc.alicdn.com/pic/developer-ecology/ec013a1fa5cc4336966b605c697a4166.jpg)

### 2）KubeVela 架構

![16.jpg](https://ucc.alicdn.com/pic/developer-ecology/e5750f149d094dd5ba841c37e40337e6.jpg)

從整體的架構來看，最上層 KubeVela 從使用者側進來，然後是 Appfile / CLI / Dashboard 等使用介面，同時 KubeVela 給服務端的整合提供了許多能力，如使用者可以將 KubeVela 當成核心使用，然後再基於 Kubernetes 來整合。有一個 CRD 叫 Application，透過這個 CRD 可以直接對接 KubeVela 的能力，同時還會有像 RestfulAPI 這種對接方式，直接有一個 HTTP 的介面來給使用者對接。

然後到了 KubeVela 裡面，分為兩種概念，一個概念就是 Workload Types，另外一個概念是 Traits，這裡面其實就是 OAM 傳統應用模型的概念。

Workload 裡面定義的是應用執行的一些主體，Traits 裡是運維的特徵及其它擴充套件。這些透過 CUE 配置語言，然後構建模板，對於使用者來說，在上層可以拿到使用這些使用能力的方法，包括一些文件等。

下方是透過 CUE 把這些實際的資源翻譯出來，翻譯成 K8s 的 CRD 或原生的一些能力，然後 YourOwn 能力也是這樣註冊進去。註冊進去以後，包括一些 CRD Controller 或 CUE 的模板，最上面提供一些發現的能力，再向下就是生成實際的資源。同時 KubeVela 還會提供一些 CRD 的註冊管理、能力的管理、能力中心等功能。

# Roadmap

KubeVela 1.0 即將在 2021 年 3 月中旬釋出，它包含以下主體能力：

1. KubeVela 的統一服務端介面Application CRD 正式釋出。
1. 能力註冊中心與擴充套件能力的包管理（包格式/安裝/版本更新/依賴/衝突發現）。
1. 基於 OAM 模型的統一發布能力（金絲雀、灰度、分批、滾動升級、無人值守鉤子）。
1. 使用者友好操作介面 KubeVelaDashboard，以及用於服務端對接的 Restful API。
1. 整合 Helm，構建 KubeVela 應用交付鏈路，為 Helm 增加部署後的生命週期管理能力。
1. 多叢集、多環境的應用部署能力以及 K8s 環境無關的 APIServer。
1. 更豐富的編排能力--資料傳遞與資源繫結。

以上就是本次分享的全部內容。想要了解更多 OAM 和 KubeVela 資訊，請訪問 KubeVela 官網或 Github 專案地址。也歡迎大家加入 OAM 社群交流釘釘群，與更多開發和運維人員深入瞭解專案及其實際使用場景。

- OAM 官網：
[https://oam.dev](https://oam.dev)

- KubeVela GitHub 專案地址：
[https://github.com/oam-dev/kubevela](https://github.com/oam-dev/kubevela)

- 社群交流釘群：釘釘搜尋群號 23310022 即可加入交流群

### “Kubernetes 與雲原生應用開源實踐大講堂”

4 場雲原生與 Kubernetes 技術前沿話題直播、70 節經典課程、3 本雲原生電子書，來“Kubernetes 與雲原生應用開源實踐大講堂”，和阿里雲容器技術專家一起，將熱門的容器開源專案和前沿的雲原生應用落地實踐一網打盡！[點選直達“Kubernetes 與雲原生應用開源實踐大講堂”！](https://developer.aliyun.com/topic/k8s/practices)

基於 KubeVela 與 Kubernetes 打造“無限能力”的開放 PaaS

相關文章