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

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

點擊查看視頻

KubeVela 的背景

KubeVela 是一個基于 Go 語言開發的云原生平臺級開源項目，這個項目是去年 11 月中旬正式發布的。雖然發布到現在不足兩個月時間，但是 KubeVela 作為"阿里巴巴統一云原生應用平臺內核”背后的核心依賴，其實已經在阿里多個產品背后運行了比較長的一段時間，我本人目前也在大量參與這些產品和項目的內核建設工作。

KubeVela：https://github.com/oam-dev/kubevela

這套內核系統誕生自 2019 年年底阿里云聯合微軟共同推出的 Open Application Model（簡稱OAM）模型基于 Kubernetes 的實現，在不斷演進和迭代中融合了大量來自開源社區（尤其是微軟、字節跳動、第四范式、騰訊和滿幫集團的社區參與者們）的反饋與貢獻，最終在 2020 年 KubeCon 北美峰會上以 “KubeVela” 的名字正式與開源社區見面。KubeVela 項目在官宣后得到了整個云原生生態的持續關注，在發布后的第四天就登上了 Go 語言的開源趨勢榜榜首。

圖 1? KubeVela 的 GitHub Star 快速增長

KubeVela 的 github 地址：https://github.com/oam-dev/kubevela/

KubeVela 是什么？

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

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

圖 2? KubeVela “關注點分離”的工作流

在設計上，KubeVela 對平臺團隊暴露了兩大核心 API，包括：

能力模板：“能力”在 KubeVela 中，指能夠組成一個完整應用的原子化功能，比如 StatefulSet 和 Ingress 就屬于兩種不同的“能力”。KubeVela 允許平臺團隊通過定義各種能力“模板”的方式，在 Kubernetes 中預置各種各樣的能力。

部署環境模板：與“能力”類似，應用的部署環境在 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? 某開源 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? 常見抽象模式

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

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

作為阿里巴巴的平臺團隊，我們在進行大規模云原生應用基礎設施的實踐中，同樣也遇到了如何設計“抽象”的難題與挑戰。經過大量的嘗試與總結，我們最終和研發效能團隊一起選擇了 GitOps + IaC（Infrastructure as Code）的技術組合來解決這個問題（具體大家可以看這篇文章：《云原生時代，應用架構將如何演進？》）。

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

圖 5? 用戶、抽象、模板和原始 K8s API 之間的關系

在具體的實現上，阿里巴巴是通過CUELang?這個 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? KubeVela 對 Kubernetes ?API 進行“拆分”的例子

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

2. 快速構建用戶使用界面

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

在具體執行上，KubeVela 會給上述抽象自動生成 ?JSON schema，這個 JSON schema 的內容，就是該抽象允許用戶填寫的參數列表和類型。所以無論是圖形界面，還是其他用戶界面，就可以直接使用這個 JSON schema 渲染出用戶表單，甚至生成使用文檔。

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

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

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

圖 7? 在 Appfile 使用 KubeVela 中的抽象

圖 8? 使用 vela traits 查看已經注冊的能力

圖 9? 使用 vela show 查看能力的使用文檔（自動生成）

目前，Appfile 是 KubeVela 內置的使用“抽象”的主要用戶界面。與此同時，相同機制的 Dashboard 和Restful API 則計劃在 ?2021 Q2 在 KubeVela 中發布出來，從而讓用戶通過圖形界面和 API 的方式來定義和使用這套抽象機制。
?
值得一提的是，作為 Kubernetes 原生的平臺構建引擎，KubeVela 的上述抽象機制和 Appfile 本身，全部都以聲明式 API 的方式實現在 Kubernetes 當中，其中 Appfile 對應的 CRD 就叫做 Application 對象。

所以作為平臺團隊，他們通過 Definition CRD 來注冊抽象模板，作為平臺的用戶，他們實際上則是通過這個 Application CRD 來使用抽象模板，整套機制完全以 Kubernetes 插件的方式運行，提供了最原生的被集成和可擴展能力。

3. 借助 Terraform? 統一定義和管理云資源

而有了 Definition + Application 這套體系（這也正是 OAM 規范的核心內容）之后，KubeVela 就可以在一套統一的使用體驗和 API 下，集成更多的能力提供方，比如：Terraform。

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

圖 10? KubeVela 使用 Terraform 拉起云資源

1）平臺團隊：注冊云資源模板和抽象

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

當然，另一方面我們也在計劃支持 Terraform 的 HCL 語法來作為 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 重點打造的的核心能力。限于篇幅就不再一一展開，非常歡迎大家到社區中使用和反饋，了解更多的細節。

歡迎加入 KubeVela 社區

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

如果你想要更好的了解 KubeVela 項目，歡迎前往其官方網站上學習具體的示例和手冊。更高階的，可以嘗試為 KubeVela 添加來自開源社區的插件能力。此外，如果你有任何關于擴展 KubeVela 的奇妙想法，比如，基于 KubeVela 開發一個自己的云原生數據庫場景 PaaS 或者 AI 場景 PaaS，歡迎前往 OAM 社區通過 Issue 來進行討論。

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

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

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

總結

以上是生活随笔為你收集整理的KubeVela：标准化的云原生平台构建引擎的全部內容，希望文章能夠幫你解決所遇到的問題。

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