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

作者 | 孫健波（天元）
來源|[阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/68G4zlNgDSbUdZEVl-vkww)

> 本文由“GO 開源說”第三期 KubeVela 直播內容修改整理而成，影片內容較長，本文內容有所刪減和重構。

[**點選檢視影片**](https://www.bilibili.com/video/BV1Tf4y1k7Ny)

# **KubeVela 的背景**

KubeVela 是一個基於 Go 語言開發的雲原生平臺級開源專案，這個專案是[去年 11 月中旬正式釋出](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247496420&idx=1&sn=3c7f079c40fde0ea915c3960b8939062&chksm=fae6f92bcd91703d8cc7f8584a050efd6cfe9c62d5801d89ce7799bcc595dadf54b7ad2544ea&scene=21#wechat_redirect)的。雖然釋出到現在不足兩個月時間，但是 KubeVela 作為"阿里巴巴統一雲原生應用平臺核心”背後的核心依賴，其實已經在阿里多個產品背後執行了比較長的一段時間，我本人目前也在大量參與這些產品和專案的核心建設工作。

KubeVela：[https://github.com/oam-dev/kubevela](https://github.com/oam-dev/kubevela)

這套核心系統誕生自 2019 年年底阿里雲聯合微軟共同推出的 Open Application Model（簡稱[OAM](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247500183&idx=1&sn=cd03d31c9ecd0ecfe3d197a9595f3c59&chksm=fae6ca58cd91434e5967d9f7533791aa2a3ce6fa3d8d9d4826beed47912be3e2a3e69d69db43&token=1157582569&lang=zh_CN)）模型基於 Kubernetes 的實現，在不斷演進和迭代中融合了大量來自開源社群（尤其是微軟、位元組跳動、第四正規化、騰訊和滿幫集團的社群參與者們）的反饋與貢獻，最終在 2020 年[ KubeCon 北美峰會](https://medium.com/@alibaba-cloud/kubevela-the-extensible-app-platform-based-on-open-application-model-and-kubernetes-581b7f419e5e)上以 “KubeVela” 的名字正式與開源社群見面。KubeVela 專案在官宣後得到了整個雲原生生態的持續關注，在釋出後的第四天就登上了 Go 語言的開源趨勢榜榜首。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/9e6cd03f75ae4a58b5829f7567b14962.png)
圖 1  KubeVela 的 GitHub Star 快速增長

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

# **KubeVela 是什麼？**

一言以蔽之，**KubeVela 是一個面向平臺構建者的、簡單易用但又高度可擴充套件的雲原生平臺構建引擎**。

具體來說，KubeVela 的目標是讓任何平臺團隊都能夠以 Kubernetes 原生的方式，快速、高效的打造出適合不同業務場景的、能夠直面使用者的雲原生平臺出來。比如：構建應用 PaaS、資料庫 PaaS、AI PaaS 或者持續交付系統等等。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/f3ae8e317c1641009b399bfc16964142.png)
圖 2  KubeVela “關注點分離”的工作流

在設計上，KubeVela 對平臺團隊暴露了兩大核心 API，包括：
 
1. **能力模板**：“能力”在 KubeVela 中，指能夠組成一個完整應用的原子化功能，比如 StatefulSet 和 Ingress 就屬於兩種不同的“能力”。KubeVela 允許平臺團隊透過定義各種能力“模板”的方式，在 Kubernetes 中預置各種各樣的能力。

1. **部署環境模板**：與“能力”類似，應用的部署環境在 KubeVela 中透過“環境”模板來進行預定義和初始化，比如“測試叢集”和“生產叢集”，就屬於兩種“環境”。

而作為平臺的使用者，比如業務團隊，他們只需要透過平臺團隊提供的環境模板來“一鍵”初始化自己預期的部署叢集，然後把自己需要的能力模板“組裝”成一個完整的應用，就可以直接向任何 Kubernetes 叢集進行應用交付和運維了。

由於上述這些能力和環境，都透過“模板”的方式進行了抽象，所以對於業務團隊來說，它們並不需要學習完整的 Kubernetes 概念與細節，只需要瞭解上述模板暴露出來的引數，就可以無縫的使用 Kubernetes 來完成自己要做的事情。而具體透過模板暴露出哪些可配置項、背後的模板怎麼渲染、渲染成什麼樣 Kubernetes 物件，則完全全在平臺團隊的掌控之中，並且可以隨時調節和修改。

上述“平臺團隊提供能力模板”結合“業務團隊組裝模板宣告應用”的工作流，也正是阿里和微軟共同釋出的 OAM 專案提倡的“關注點分離”思想的集中體現。在具體的模板支援上，KubeVela 第一期支援的是 Google 開源的 CUELang 模板語言，第二期則會支援 Helm Chart 包直接作為能力模板。

# **KubeVela 能為你做什麼？**

在瞭解了 KubeVela 是個什麼專案以後，我們再來回答第二個大家一直都很關心的問題：**作為一個平臺構建者，KubeVela 能夠幫助你做什麼?**

## 1. 快速構建抽象

構建“抽象”，是任何一個雲原生平臺的最基礎、也必然會提供的功能。

**我們知道，Kubernetes 暴露出來的是一套宣告式 API，而所謂抽象，其實就是一個平臺在這些宣告式 API 的基礎上，為使用者暴露出來的可操作項和可配置項**。作為平臺團隊，我們之所以要提供“抽象”，其最終目的都是為了簡化使用者的使用心智，讓業務團隊只關注他們關心的事情，避免引入大量與業務無關的平臺層細節讓使用者“望而卻步”。可以說，提供“抽象”，是任何一個平臺團隊落地 Kubernetes 等系統級開源專案的第一步。

業界最常見的抽象方式，是給使用者提供一個圖形介面來進行操作（比如 Console 或者 Dashboard），這些圖形介面的共同點，就是僅允許使用者填寫某些特定的欄位引數，從而實現簡化使用者心智的目的，比如下圖所示的某開源 K8s PaaS 專案的 Console：

![3.png](https://ucc.alicdn.com/pic/developer-ecology/d8f1686175784d9a83984e96aacea13a.png)
圖 3  某開源 K8s PaaS 專案的 Console

還有一些專案（比如 Racher Rio）選擇給使用者提供一個命令列工具，其實它的作用跟圖形介面完全類似，只不過允許填寫的引數變成了 CLI 的引數而已。

當然，對於一些技術水位更高的團隊，他們會基於 Kubernetes 再開發上層的 CRD + Operator 來作為“抽象”。比如 Knative 其實就是一種面向 Serverless 場景的抽象，Pinterest 公司則有自己的 Application CRD 抽象等。

那麼，作為平臺團隊，我們又是怎麼來決定給使用者暴露哪些可配置引數呢？這就涉及到了“抽象”的三種基礎模式（更復雜的情況都是對這三種模式的進一步組合）：

- **組合抽象**，這種模式常見於我們把2個原子能力組合成為一個能力提供，比如我們在實際開發 Console 時，經常會把 K8s Deployment 和 Service 進行“組合”，暴露出一個 Web Service 的概念來讓使用者可以在一個表單裡同時定義容器映象和暴露埠。

- **拆分抽象**，這種模式常見於我們希望在使用流程上把一個物件上的欄位分開成幾個表單來進行分步驟填寫，從而解耦部署時與運維時的配置。比如一個 Pod 裡面的多個容器， 我希望在第一個表單裡讓使用者填寫業務容器，在另一個表單讓運維填寫 Sidecar 容器。再比如 ArgoRollout 這個物件，我會希望一個表單讓使用者填寫容器映象，另一個表單讓運維填寫灰度策略。

- **轉換抽象**，這種模式通常用於改個名字，或者說去掉一些無關的概念，比如 Knative Revision 跟 Deployment 本質上是一一對應的，但是裡面類似 LabelSelector 這種使用者不需要關心的欄位在 Knative 就會直接去掉了。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/61f8abf2f8044074a1dc5956f76683fc.png)
圖 4  常見抽象模式

上述幾種抽象的模式，在業界的很多平臺級專案和產品中都有體現。但另一方面，如何正確的設計抽象，以及如何確保抽象能夠滿足業務方使用者的使用需求和習慣，其實是一個非常具備挑戰性的問題。這裡的關鍵點在於，無論是圖形化介面，還是 CRD Operator，這些“抽象”一旦上線，對它的修改就非常困難。可是另一方面，業務方使用者的需求，又幾乎不可能是一成不變的（實際情況甚至是“一天一個樣”）。

### KubeVela 對於“抽象”的設計與實現

作為阿里巴巴的平臺團隊，我們在進行大規模雲原生應用基礎設施的實踐中，同樣也遇到了如何設計“抽象”的難題與挑戰。經過大量的嘗試與總結，我們最終和研發效能團隊一起選擇了 GitOps + IaC（Infrastructure as Code）的技術組合來解決這個問題（具體大家可以看這篇文章：[《雲原生時代，應用架構將如何演進？》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247495335&idx=1&sn=de4f3a345c2b31122a4bcdad7d538eb4&chksm=fae6e568cd916c7ecdbd1c0efd1b0a277bea83f0d62a973c2710674106b8df38b80d7dd484e5&scene=21#wechat_redirect)）。

其中，GitOps 更多是對交付流水線的創新，而 IaC 的存在，就是為了解決“抽象”這個問題。具體來說，IaC 的強大之處在於，它對“抽象”的定義是透過“模板”來表達的。這意味著一個“抽象”背後，並不需要 CRD Operator 這樣複雜的伺服器端程式設計工作，作為平臺團隊我們只需要提交一個模板，使用者就“自動”有了抽象後的欄位；而如果要修改這些抽象欄位，我們只需要將對應模板更新，使用者那邊的抽象也就“自動”改變了。這種抽象機制的調整和更新，不需要任何重新編譯和上線的環節，所以我們把它也稱為“客戶端抽象”。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/4fd2f476283c44e18bd738f0c4c63be7.png)
圖 5  使用者、抽象、模板和原始 K8s API 之間的關係

在具體的實現上，阿里巴巴是透過[CUELang](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247500183&idx=1&sn=cd03d31c9ecd0ecfe3d197a9595f3c59&chksm=fae6ca58cd91434e5967d9f7533791aa2a3ce6fa3d8d9d4826beed47912be3e2a3e69d69db43&token=1157582569&lang=zh_CN) 這個 Google 開發的模板語言來定義抽象模板的，這也是為何 KubeVela 第一期先開源了基於 CUE 的抽象機制。在具體使用上，平臺團隊只需要將 CUE 模板按照 OAM 規範（即：WorkloadDefinition  和 TraitDefinition 物件）註冊（kubectl apply）到 Kubernetes 叢集當中，業務使用者就可以立刻使用這個抽象（具體的使用方式我們後面會詳細說明）。

另一方面，CUE 之所以受到 Google 和阿里的青睞，還在於它比較完善的抽象層實現能力。比如前面我們總結了抽象的三種模式，其中 “轉換抽象”和“組合抽象”在模板渲染的時候很容易做，無非就是模板渲染的時候換個欄位名稱，生成的內容變成多個物件而已。但是拆分抽象其實是有很大難度的，這涉及到拆分後能力的獨立執行以及最終兩個能力又重新組合到一起（patch-merge）的過程。

而藉助 KubeVela，這個拆分就比較簡單了。以前面提到解耦業務容器與 Sidecar 容器的定義流程為例，我們希望把“定義業務容器”和“定義 Sidecar 容器”在使用者側拆到兩個不同的表單上去。在具體執行上，平臺團隊只需要註冊一個 WorkloadDefinition 物件（名叫 worker），裡面攜帶業務容器的 Deployment 模板，然後再註冊一個 TraitDefinition 物件（名叫 sidecar），裡面只攜帶 Sidecar 容器的模板，那麼 KubeVela 就會對使用者側暴露出 worker 和 sidecar 兩套完全獨立的可配置項，使得使用者可以在部署時只需要填寫 worker 中的業務容器引數，運維則可以在後續的運維時獨立填寫 sidecar 的配置引數，而完全不需要對使用者的 worker 部分進行任何修改。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/a45e0b5d332a4e7290374de20b37e57a.png)
圖 6  KubeVela 對 Kubernetes  API 進行“拆分”的例子

當然，除了 CUE 之外，上述抽象機制也可以透過 Helm 來實現，並且同 GitOps 流水線無縫整合。這個功能會作為 KubeVela 下一個重要特性發布，屆時我們會分享基於 KubeVela 構建持續交付系統的案例與最佳實踐。

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

在有了上述“抽象”之後，作為平臺的終端使用者，業務團隊就可以透過某種方式使用這些抽象來交付和管理應用了。在這一層，KubeVela 不會做任何約束，相反，它的目標是讓抽象能夠被直接透出在使用者的使用介面上，這樣，當平臺團隊對這些抽象進行了調整之後，業務使用者就可以立即使用到最新的抽象，不需要對系統做任何更新或者升級。

在具體執行上，KubeVela 會給上述抽象自動生成  JSON schema，這個 JSON schema 的內容，就是該抽象允許使用者填寫的引數列表和型別。所以無論是圖形介面，還是其他使用者介面，就可以直接使用這個 JSON schema 渲染出使用者表單，甚至生成[使用文件](https://kubevela.io/#/en/developers/references/workload-types/webservice)。

比如前面解耦 Sidecar 容器定義的例子，KubeVela 就會為使用者暴露出兩份 JSON schema：一個用來定義業務容器的引數列表，一個用來 Sidecar 容器的引數列表，前端就可以渲染成兩個獨立的表單來供使用者填寫。

正是上述 IaC 抽象 + 自動生成 Schema 的機制，讓基於 KubeVela 構建面向使用者的使用介面不僅變得非常簡單，而且還高度可擴充套件：這些抽象背後的模板只要被平臺管理員修改，就會立刻體現在使用者的圖形介面表單上，根本不需要進行系統升級和重新上線。

在 KubeVela 中，它內建了一個簡化版的圖形介面，叫做 Appfile，它其實就是把上述抽象的 schema 以 YAML 的方式展示了出來，從而允許使用者進行修改和配置，在下面的例子中，我們可以形象的看到每一個“能力抽象”（route，autoscaler 等等）在 Appfile 如何體現為一個個可配置項的。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/a415e9791fa14d2aab4267bf8405dc14.png)
圖 7  在 Appfile 使用 KubeVela 中的抽象

![8.png](https://ucc.alicdn.com/pic/developer-ecology/90db3ff2ff134586a4dcd2842fcc457f.png)
圖 8  使用 vela traits 檢視已經註冊的能力

![9.png](https://ucc.alicdn.com/pic/developer-ecology/1cfd6c13b9024e19a1189256e15c2a32.png)
圖 9  使用 vela show 檢視能力的使用文件（自動生成）

目前，Appfile 是 KubeVela 內建的使用“抽象”的主要使用者介面。與此同時，相同機制的 Dashboard 和[Restful API](https://github.com/oam-dev/kubevela/blob/master/design/vela-core/APIServer-Catalog.md) 則計劃在  2021 Q2 在 KubeVela 中釋出出來，從而讓使用者透過圖形介面和 API 的方式來定義和使用這套抽象機制。
 
值得一提的是，作為 Kubernetes 原生的平臺構建引擎，KubeVela 的上述抽象機制和 Appfile 本身，全部都以宣告式 API 的方式實現在 Kubernetes 當中，其中 Appfile 對應的 CRD 就叫做 [Application 物件](https://github.com/oam-dev/kubevela/blob/master/config/samples/application/application-sample.yaml)。

所以作為平臺團隊，他們透過 Definition CRD 來註冊抽象模板，作為平臺的使用者，他們實際上則是透過這個 Application CRD 來使用抽象模板，整套機制完全以 Kubernetes 外掛的方式執行，提供了最原生的被整合和可擴充套件能力。

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

而有了 Definition + Application 這套體系（這也正是 OAM 規範的核心內容）之後，KubeVela 就可以在一套統一的使用體驗和 API 下，整合更多的能力提供方，比如：[Terraform](https://www.terraform.io/)。

Terraform 是業內知名的建立雲資源的工具，它豐富的生態幾乎包含了所有主流雲廠商的大部分雲資源，是對 Kubernetes 雲資源管理能力不足最好的補充。 在 KubeVela 中使用 Terraform 定義和拉起雲資源非常簡單，如下圖所示：

![10.png](https://ucc.alicdn.com/pic/developer-ecology/e74647bdd0eb430c9f792a8204ac2b98.png)
圖 10  KubeVela 使用 Terraform 拉起雲資源

### 1）平臺團隊：註冊雲資源模板和抽象

平臺團隊的工作是定義一個名為"aliyun-rds"的 WorkloadDefinition 物件，並且在裡面定義好 Terraform 阿里雲 RDS 雲資源的模板。在上述例子中我們同樣是透過 CUE 來編寫的 Terraform 配置， 這是因為 Terraform 雲資源本身支援使用 JSON 格式描述，而 CUE 又是 JSON 的超集，所以可以自然的使用 Terraform 所有的能力。

當然，另一方面我們也在計劃支援 [Terraform 的 HCL](https://www.terraform.io/docs/configuration/syntax.html) 語法來作為 KubeVela 的另一種模板語言。在 CUE 模板中我們引用了阿里雲的 RDS 定義，並抽象成 user、password等少量使用者欄位（parameter）。

### 2）使用者：定義和使用雲資源

這樣，使用者只需要在 Appfile 中，填寫一個新的 Service，命名為  sample-db 而其型別就是我們上面定義的  aliyun-rds，就可以在這個部分定義模板中提供的 user，password 等引數。

除此之外，使用者還可以在上面的  express-server 這個業務應用中定義資料繫結，填寫名為 sample-db 的配置及其對映的環境變數名稱。

最後，使用者只需要一句  vela up 命令，KubeVela 就會拉起業務容器，然後自動把 Terraform 建立的阿里雲RDS返回的連結資訊傳遞到業務的容器中，我們可以在最後一部分看到這個應用已經成功啟動，並獲得了資料庫的連線資訊。當然，這個流程中的資料傳遞和編排功能，也是 KubeVela 內建的核心能力。

# 總結

作為 Kubernetes 上第一個雲原生平臺構建引擎以及 OAM 模型的完整實現，KubeVela 為平臺構建者提供的能力遠不止這些，比如後續即將開源的統一應用灰度框架、多叢集多環境的交付元件、CRD Controller 的生命週期管理等等，都是 KubeVela 重點打造的的核心能力。限於篇幅就不再一一展開，非常歡迎大家到[社群](https://kubevela.io/)中使用和反饋，瞭解更多的細節。

# **歡迎加入 KubeVela 社群**

正如最開始所言，KubeVela 是一個由社群發起社群構建的專案，所以在專案的早期，我們就已經收穫了 38 名貢獻者，來自數十家不同的公司，這是一個非常開放的社群，也有大量的新功能在規劃和實現中，歡迎大家的貢獻、使用和反饋。

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

如果你想要更好的瞭解 KubeVela 專案，歡迎前往其官方網站上學習具體的示例和手冊。更高階的，可以嘗試為 KubeVela 新增來自開源社群的[外掛能力](https://kubevela.io/#/blog/zh/extend-kubevela-by-cuelang-in-20-mins)。此外，如果你有任何關於擴充套件 KubeVela 的奇妙想法，比如，基於 KubeVela 開發一個自己的雲原生資料庫場景 PaaS 或者 AI 場景 PaaS，歡迎前往 OAM 社群透過 Issue 來進行討論。

如果你想要進一步交流，歡迎釘釘掃碼進群，這裡有一個近兩千人的社群：釘釘搜尋群號 23310022 即可進群。

最後，阿里云云原生應用管理平臺團隊也在持續招聘中，如果你對我們的工作感興趣，也歡迎你投遞簡歷至 jianbo.sjb@alibaba-inc.com 。

2021 校招已經開啟，如果是你是 2021 年 11 月 - 2022 年 10 月畢業的同學，歡迎加小助手 weixin：**AlibabaCloud888**，回覆關鍵字 **“校招”** 進群直接和雲原生技術大佬交流！

KubeVela：標準化的雲原生平臺構建引擎

相關文章