KubeVela 的背景
KubeVela 是一個基於 Go 語言開發的雲原生平臺級開源項目，這個項目是去年 11 月中旬正式發佈的。雖然發佈到現在不足兩個月時間，但是 KubeVela 作爲"阿里巴巴統一雲原生應用平臺內核”背後的核心依賴，其實已經在阿里多個產品背後運行了比較長的一段時間，我本人目前也在大量參與這些產品和項目的內核建設工作。
這套內核系統誕生自 2019 年年底阿里雲聯合微軟共同推出的 Open Application Model（簡稱OAM）模型基於 Kubernetes 的實現，在不斷演進和迭代中融合了大量來自開源社區（尤其是微軟、字節跳動、第四範式、騰訊和滿幫集團的社區參與者們）的反饋與貢獻，最終在 2020 年 KubeCon 北美峯會上以 “KubeVela” 的名字正式與開源社區見面。KubeVela 項目在官宣後得到了整個雲原生生態的持續關注，在發佈後的第四天就登上了 Go 語言的開源趨勢榜榜首。
KubeVela 是什麼？
一言以蔽之，KubeVela 是一個面向平臺構建者的、簡單易用但又高度可擴展的雲原生平臺構建引擎。
具體來說，KubeVela 的目標是讓任何平臺團隊都能夠以 Kubernetes 原生的方式，快速、高效的打造出適合不同業務場景的、能夠直面用戶的雲原生平臺出來。比如：構建應用 PaaS、數據庫 PaaS、AI PaaS 或者持續交付系統等等。
在設計上，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：
還有一些項目（比如 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 就會直接去掉了。
上述幾種抽象的模式，在業界的很多平臺級項目和產品中都有體現。但另一方面，如何正確的設計抽象，以及如何確保抽象能夠滿足業務方用戶的使用需求和習慣，其實是一個非常具備挑戰性的問題。這裏的關鍵點在於，無論是圖形化界面，還是 CRD Operator，這些“抽象”一旦上線，對它的修改就非常困難。可是另一方面，業務方用戶的需求，又幾乎不可能是一成不變的（實際情況甚至是“一天一個樣”）。
KubeVela 對於“抽象”的設計與實現
作爲阿里巴巴的平臺團隊，我們在進行大規模雲原生應用基礎設施的實踐中，同樣也遇到了如何設計“抽象”的難題與挑戰。經過大量的嘗試與總結，我們最終和研發效能團隊一起選擇了 GitOps + IaC（Infrastructure as Code）的技術組合來解決這個問題（具體大家可以看這篇文章：《雲原生時代，應用架構將如何演進？》）。
其中，GitOps 更多是對交付流水線的創新，而 IaC 的存在，就是爲了解決“抽象”這個問題。具體來說，IaC 的強大之處在於，它對“抽象”的定義是通過“模板”來表達的。這意味着一個“抽象”背後，並不需要 CRD Operator 這樣複雜的服務器端編程工作，作爲平臺團隊我們只需要提交一個模板，用戶就“自動”有了抽象後的字段；而如果要修改這些抽象字段，我們只需要將對應模板更新，用戶那邊的抽象也就“自動”改變了。這種抽象機制的調整和更新，不需要任何重新編譯和上線的環節，所以我們把它也稱爲“客戶端抽象”。
在具體的實現上，阿里巴巴是通過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 部分進行任何修改。
當然，除了 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 如何體現爲一個個可配置項的。
目前，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 定義和拉起雲資源非常簡單，如下圖所示：
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 重點打造的的核心能力。限於篇幅就不再一一展開，非常歡迎大家到社區中使用和反饋，瞭解更多的細節。
作者 | 孫健波（天元）
本文爲阿里雲原創內容，未經允許不得轉載。