本文由“GO開源說”第三期 KubeVela 直播內(nèi)容修改整理而成，視頻內(nèi)容較長(zhǎng)，本文內(nèi)容有所刪減和重構(gòu)。

大家好，很高興來到“GO開源說” 跟大家分享開源項(xiàng)目背后的一些故事、設(shè)計(jì)思想以及使用方法，今天分享的項(xiàng)目是 KubeVela，一個(gè)標(biāo)準(zhǔn)化的云原生平臺(tái)構(gòu)建引擎。我是來自阿里云--云原生應(yīng)用平臺(tái)團(tuán)隊(duì)的孫健波（花名：天元），也是 KubeVela 這個(gè)項(xiàng)目的核心作者之一。

KubeVela 的背景

KubeVela 是一個(gè)基于 Go 語言開發(fā)的云原生平臺(tái)級(jí)開源項(xiàng)目，這個(gè)項(xiàng)目是去年 11月中旬正式發(fā)布的。雖然發(fā)布到現(xiàn)在不足兩個(gè)月時(shí)間，但是 KubeVela 作為"阿里巴巴統(tǒng)一云原生應(yīng)用平臺(tái)內(nèi)核”背后的核心依賴，其實(shí)已經(jīng)在阿里多個(gè)產(chǎn)品背后運(yùn)行了比較長(zhǎng)的一段時(shí)間，我本人目前也在大量參與這些產(chǎn)品和項(xiàng)目的內(nèi)核建設(shè)工作。這套內(nèi)核系統(tǒng)，誕生自 2019 年底阿里云聯(lián)合微軟共同推出的 Open Application Model（簡(jiǎn)稱 OAM）模型基于 Kubernetes 的實(shí)現(xiàn)，在不斷的演進(jìn)和迭代中融合了大量來自開源社區(qū)（尤其是微軟、字節(jié)跳動(dòng)、第四范式、騰訊和滿幫集團(tuán)的社區(qū)參與者們）的反饋與貢獻(xiàn)，最終在 2020 年 KubeCon 北美峰會(huì)上以“KubeVela”的名字正式與開源社區(qū)見面。KubeVela 項(xiàng)目在官宣后得到了整個(gè)云原生生態(tài)的持續(xù)關(guān)注，在發(fā)布后的第四天就登上了 Go 語言的開源趨勢(shì)榜榜首。

圖1 KubeVela 的 GitHub Star 快速增長(zhǎng)

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

KubeVela 是什么？

一言以蔽之，KubeVela 是一個(gè)面向平臺(tái)構(gòu)建者的、簡(jiǎn)單易用但又高度可擴(kuò)展的云原生平臺(tái)構(gòu)建引擎。

具體來說，KubeVela 的目標(biāo)是讓任何平臺(tái)團(tuán)隊(duì)都能夠以 Kubernetes 原生的方式，快速、高效的打造出適合不同業(yè)務(wù)場(chǎng)景的、能夠直面用戶的云原生平臺(tái)出來。比如：構(gòu)建應(yīng)用 PaaS，數(shù)據(jù)庫(kù) PaaS，AI PaaS 或者持續(xù)交付系統(tǒng)等等。

圖2 KubeVela “關(guān)注點(diǎn)分離”的工作流

在設(shè)計(jì)上，KubeVela 的對(duì)平臺(tái)團(tuán)隊(duì)暴露了兩大核心 API，包括：

1. 能力模板：“能力”在 KubeVela 中，指能夠組成一個(gè)完整應(yīng)用的原子化功能，比如 StatefulSet 和 Ingress 就屬于兩種不同的“能力”。KubeVela 允許平臺(tái)團(tuán)隊(duì)通過定義各種能力“模板”的方式，在 Kubernetes 中預(yù)置各種各樣的能力。

2. 部署環(huán)境模板：與“能力”類似，應(yīng)用的部署環(huán)境在 KubeVela 中通過“環(huán)境”模板來進(jìn)行預(yù)定義和初始化，比如“測(cè)試集群”和“生產(chǎn)集群”，就屬于兩種“環(huán)境”。

而作為平臺(tái)的用戶，比如業(yè)務(wù)團(tuán)隊(duì)，他們只需要通過平臺(tái)團(tuán)隊(duì)提供的環(huán)境模板來“一鍵”初始化自己預(yù)期的部署集群，然后把自己需要的能力模板“組裝”成一個(gè)完整的應(yīng)用，就可以直接向任何 Kubernetes 集群進(jìn)行應(yīng)用交付和運(yùn)維了。

由于上述這些能力和環(huán)境，都通過“模板”的方式進(jìn)行了抽象，所以對(duì)于業(yè)務(wù)團(tuán)隊(duì)來說，它們并不需要學(xué)習(xí)完整的 Kubernetes 概念與細(xì)節(jié)，只需要了解上述模板暴露出來的參數(shù)，就可以無縫的使用 Kubernetes 來完成自己要做的事情。而具體通過模板暴露出哪些可配置項(xiàng)、背后的模板怎么渲染、渲染成什么樣的 Kubernetes 對(duì)象，則完全全在平臺(tái)團(tuán)隊(duì)的掌控之中，并且可以隨時(shí)調(diào)節(jié)和修改。

上述“平臺(tái)團(tuán)隊(duì)提供能力模板”結(jié)合“業(yè)務(wù)團(tuán)隊(duì)組裝模板聲明應(yīng)用”的工作流，也正是阿里和微軟共同發(fā)布的 OAM 項(xiàng)目提倡的“關(guān)注點(diǎn)分離”思想的集中體現(xiàn)。在具體的模板支持上，KubeVela 第一期支持的是 Google 開源的 CUELang 模板語言，第二期則會(huì)支持 Helm Chart 包直接作為能力模板。

KubeVela 能為你做什么？

在了解了 KubeVela 是個(gè)什么項(xiàng)目以后，我們?cè)賮砘卮鸬诙€(gè)大家一直都很關(guān)心的問題：作為一個(gè)平臺(tái)構(gòu)建者，KubeVela 能夠幫助你做什么?

第一、快速構(gòu)建抽象

構(gòu)建“抽象”，是任何一個(gè)云原生平臺(tái)的最基礎(chǔ)、也必然會(huì)提供的功能。

我們知道，Kubernetes 暴露出來的是一套聲明式 API，而所謂抽象，其實(shí)就是一個(gè)平臺(tái)在這些聲明式 API 的基礎(chǔ)上，為用戶暴露出來的可操作項(xiàng)和可配置項(xiàng)。作為平臺(tái)團(tuán)隊(duì)，我們之所以要提供“抽象”，其最終目的都是為了簡(jiǎn)化用戶的使用心智，讓業(yè)務(wù)團(tuán)隊(duì)只關(guān)注他們關(guān)心的事情，避免引入大量與業(yè)務(wù)無關(guān)的平臺(tái)層細(xì)節(jié)讓用戶“望而卻步”。可以說，提供“抽象”，是任何一個(gè)平臺(tái)團(tuán)隊(duì)落地 Kubernetes 等系統(tǒng)級(jí)開源項(xiàng)目的第一步。

業(yè)界最常見的抽象方式，是給用戶提供一個(gè)圖形界面來進(jìn)行操作（比如 Console 或者 Dashboard），這些圖形界面的共同點(diǎn)，就是僅允許用戶填寫某些特定的字段參數(shù)，從而實(shí)現(xiàn)簡(jiǎn)化用戶心智的目的，比如下圖所示的某開源 K8s PaaS 項(xiàng)目的 Console：

圖3 某開源 K8s PaaS 項(xiàng)目的 Console

還有一些項(xiàng)目（比如 Racher Rio）選擇的是給用戶提供一個(gè)命令行工具，其實(shí)它的作用跟圖形界面完全類似，只不過允許填寫的參數(shù)變成了 CLI 的參數(shù)而已。

當(dāng)然，對(duì)于一些技術(shù)水位更高的團(tuán)隊(duì)，他們會(huì)基于 Kubernetes 再開發(fā)上層的 CRD + Operator 來作為“抽象”。比如 Knative 其實(shí)就是一種面向 Serverless 場(chǎng)景的抽象，Pinterest 公司則有自己的 Application CRD 抽象，等等。

那么，作為平臺(tái)團(tuán)隊(duì)，我們又是怎么來決定給用戶暴露哪些可配置參數(shù)呢？這就涉及到了“抽象”的三種基礎(chǔ)模式（更復(fù)雜的情況都是對(duì)這三種模式的進(jìn)一步組合）：

• 組合抽象，這種模式常見于我們把2個(gè)原子能力組合成為一個(gè)能力提供，比如我們?cè)趯?shí)際開發(fā) Console 時(shí)，經(jīng)常會(huì)把 K8s Deployment 和 Service 進(jìn)行“組合”，暴露出一個(gè) Web Service 的概念來讓用戶可以在一個(gè)表單里同時(shí)定義容器鏡像和暴露端口。

• 拆分抽象，這種模式常見于我們希望在使用流程上把一個(gè)對(duì)象上的字段分開成幾個(gè)表單來進(jìn)行分步驟填寫，從而解耦部署時(shí)與運(yùn)維時(shí)的配置。比如一個(gè) Pod 里面的多個(gè)容器， 我希望在第一個(gè)表單里讓用戶填寫業(yè)務(wù)容器，在另一個(gè)表單讓運(yùn)維填寫 Sidecar 容器。再比如 ArgoRollout 這個(gè)對(duì)象，我會(huì)希望一個(gè)表單讓用戶填寫容器鏡像，另一個(gè)表單讓運(yùn)維填寫灰度策略。

• 轉(zhuǎn)換抽象，這種模式通常用于改個(gè)名字，或者說去掉一些無關(guān)的概念，比如 Knative Revision 跟 Deployment 本質(zhì)上是一一對(duì)應(yīng)的，但是里面類似 LabelSelector 這種用戶不需要關(guān)心的字段在 Knative 就會(huì)直接去掉了。

圖4 常見抽象模式

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

KubeVela 對(duì)于“抽象”的設(shè)計(jì)與實(shí)現(xiàn)

作為阿里巴巴的平臺(tái)團(tuán)隊(duì)，我們?cè)谶M(jìn)行大規(guī)模云原生應(yīng)用基礎(chǔ)設(shè)施的實(shí)踐中，同樣也遇到了如何設(shè)計(jì)“抽象”的難題與挑戰(zhàn)。經(jīng)過大量的嘗試與總結(jié)，我們最終和研發(fā)效能團(tuán)隊(duì)一起選擇了 GitOps + IaC（Infrastructure as Code）的技術(shù)組合來解決這個(gè)問題（具體大家可以看這篇文章）。其中，GitOps 更多是對(duì)交付流水線的創(chuàng)新，而 IaC 的存在，就是為了解決“抽象”這個(gè)問題。具體來說，IaC 的強(qiáng)大之處在于，它對(duì)“抽象”的定義是通過“模板”來表達(dá)的。這意味著一個(gè)“抽象”背后，并不需要 CRD Operator 這樣復(fù)雜的服務(wù)器端編程工作，作為平臺(tái)團(tuán)隊(duì)我們只需要提交一個(gè)模板，用戶就“自動(dòng)”有了抽象后的字段；而如果要修改這些抽象字段，我們只需要將對(duì)應(yīng)模板更新，用戶那邊的抽象也就“自動(dòng)”改變了。這種抽象機(jī)制的調(diào)整和更新，不需要任何重新編譯和上線的環(huán)節(jié)，所以我們把它也稱為“客戶端抽象”。

圖5 用戶、抽象、模板和原始 K8s API 之間的關(guān)系

在具體的實(shí)現(xiàn)上，阿里巴巴是通過 CUELang 這個(gè) Google 開發(fā)的模板語言來定義抽象模板的，這也是為何 KubeVela 第一期先開源了基于 CUE 的抽象機(jī)制。在具體使用上，平臺(tái)團(tuán)隊(duì)只需要將 CUE 模板按照 OAM 規(guī)范（即：WorkloadDefinition  和 TraitDefinition 對(duì)象）注冊(cè)（kubectl apply）到 Kubernetes 集群當(dāng)中，業(yè)務(wù)用戶就可以立刻使用這個(gè)抽象（具體的使用方式我們后面會(huì)詳細(xì)說明）。

另一方面，CUE 之所以受到 Google 和阿里的青睞，還在于它比較完善的抽象層實(shí)現(xiàn)能力。比如前面我們總結(jié)了抽象的三種模式，其中 “轉(zhuǎn)換抽象”和“組合抽象”在模板渲染的時(shí)候很容易做，無非就是模板渲染的時(shí)候換個(gè)字段名稱，生成的內(nèi)容變成多個(gè)對(duì)象而已。但是拆分抽象其實(shí)是有很大難度的，這涉及到拆分后能力的獨(dú)立運(yùn)行以及最終兩個(gè)能力又重新組合到一起（patch-merge）的過程。

而借助 KubeVela，這個(gè)拆分就比較簡(jiǎn)單了。以前面提到解耦業(yè)務(wù)容器與 Sidecar 容器的定義流程為例，我們希望把“定義業(yè)務(wù)容器”和“定義 Sidecar 容器”在用戶側(cè)拆到兩個(gè)不同的表單上去。在具體執(zhí)行上，平臺(tái)團(tuán)隊(duì)只需要注冊(cè)一個(gè) WorkloadDefinition 對(duì)象（名叫 worker），里面攜帶業(yè)務(wù)容器的 Deployment 模板，然后再注冊(cè)一個(gè) TraitDefinition 對(duì)象（名叫 sidecar），里面只攜帶 Sidecar 容器的模板，那么 KubeVela 就會(huì)對(duì)用戶側(cè)暴露出 worker 和 sidecar 兩套完全獨(dú)立的可配置項(xiàng)，使得用戶可以在部署時(shí)只需要填寫 worker 中的業(yè)務(wù)容器參數(shù)，運(yùn)維則可以在后續(xù)的運(yùn)維時(shí)獨(dú)立填寫 sidecar 的配置參數(shù)，而完全不需要對(duì)用戶的 worker 部分進(jìn)行任何修改。 

圖 6 KubeVela 對(duì) Kubernetes  API 進(jìn)行“拆分”的例子

當(dāng)然，除了 CUE 之外，上述抽象機(jī)制也可以通過 Helm 來實(shí)現(xiàn)，并且同 GitOps 流水線無縫集成。這個(gè)功能會(huì)作為 KubeVela 下一個(gè)重要特性發(fā)布，屆時(shí)我們會(huì)分享基于 KubeVela 構(gòu)建持續(xù)交付系統(tǒng)的案例與最佳實(shí)踐。

第二、快速構(gòu)建用戶使用界面

在有了上述“抽象”之后，作為平臺(tái)的最終用戶，業(yè)務(wù)團(tuán)隊(duì)就可以通過某種方式使用這些抽象來交付和管理應(yīng)用了。在這一層，KubeVela 不會(huì)做任何約束，相反，它的目標(biāo)是讓抽象能夠被直接透出在用戶的使用界面上，這樣，當(dāng)平臺(tái)團(tuán)隊(duì)對(duì)這些抽象進(jìn)行了調(diào)整之后，業(yè)務(wù)用戶就可以立即使用到最新的抽象，不需要對(duì)系統(tǒng)做任何更新或者升級(jí)。

在具體執(zhí)行上，KubeVela 會(huì)給上述抽象自動(dòng)生成  JSON schema，這個(gè) JSON schema 的內(nèi)容，就是該抽象允許用戶填寫的參數(shù)列表和類型。所以無論是圖形界面，還是其他用戶界面，就可以直接使用這個(gè) JSON schema 渲染出用戶表單，甚至生成使用文檔（KubeVela 自己內(nèi)置的能力使用文檔就是這么來的）。比如前面解耦 Sidecar 容器定義的例子，KubeVela 就會(huì)為用戶暴露出兩份 JSON schema：一個(gè)用來定義業(yè)務(wù)容器的參數(shù)列表，一個(gè)用來 sidecar 容器的參數(shù)列表，前端就可以渲染成兩個(gè)獨(dú)立的表單來供用戶填寫。

正是上述 IaC 抽象 + 自動(dòng)生成 Schema 的機(jī)制，讓基于 KubeVela 構(gòu)建面向用戶的使用界面不僅變得非常簡(jiǎn)單，而且還高度可擴(kuò)展：這些抽象背后的模板只要被平臺(tái)管理員修改，就會(huì)立刻體現(xiàn)在用戶的圖形界面表單上，根本不需要進(jìn)行系統(tǒng)升級(jí)和重新上線。

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

圖 7 在 Appfile 使用 KubeVela 中的抽象

圖 8 使用 vela traits 查看已經(jīng)注冊(cè)的能力

圖 9 使用 vela show 查看能力的使用文檔（自動(dòng)生成）  

目前，Appfile 是 KubeVela 內(nèi)置的使用“抽象”的主要用戶界面。與此同時(shí)，相同機(jī)制的 Dashboard 和 Restful API 則計(jì)劃在  2021 Q2 在 KubeVela 中發(fā)布出來，從而讓用戶通過圖形界面和 API 的方式來定義和使用這套抽象機(jī)制。

值得一提的是，作為 Kubernetes 原生的平臺(tái)構(gòu)建引擎，KubeVela 的上述抽象機(jī)制和 Appfile 本身，全部都以聲明式 API 的方式實(shí)現(xiàn)在 Kubernetes 當(dāng)中，其中 Appfile 對(duì)應(yīng)的 CRD 就叫做 Application 對(duì)象。所以作為平臺(tái)團(tuán)隊(duì)，他們通過 Definition CRD 來注冊(cè)抽象模板，作為平臺(tái)的用戶，他們實(shí)際上則是通過這個(gè) Application CRD 來使用抽象模板，整套機(jī)制完全以 Kubernetes 插件的方式運(yùn)行，提供了最原生的被集成和可擴(kuò)展能力。

第三、借助 Terraform  統(tǒng)一定義和管理云資源

而有了 Definition + Application 這套體系（這也正是 OAM 規(guī)范的核心內(nèi)容）之后，KubeVela 就可以在一套統(tǒng)一的使用體驗(yàn)和 API 下，集成更多的能力提供方，比如 Terraform。Terraform 是業(yè)內(nèi)知名的創(chuàng)建云資源的工具，它豐富的生態(tài)幾乎包含了所有主流云廠商的大部分云資源，是對(duì) Kubernetes 云資源管理能力不足最好的補(bǔ)充。

在 KubeVela 中使用 Terraform 定義和拉起云資源非常簡(jiǎn)單，如下圖所示：

圖 10 KubeVela 使用 Terraform 拉起云資源

平臺(tái)團(tuán)隊(duì)：注冊(cè)云資源模板和抽象

平臺(tái)團(tuán)隊(duì)的工作是定義一個(gè)名為 "aliyun-rds" 的 WorkloadDefinition 對(duì)象，并且在里面定義好 Terraform 阿里云 RDS 云資源的模板。在上述例子中我們同樣是通過 CUE 來編寫的 Terraform 配置， 這是因?yàn)?Terraform 云資源本身支持使用 JSON 格式 描述，而 CUE 又是 JSON 的超集，所以可以自然的使用 Terraform 所有的能力。當(dāng)然，另一方面我們也在計(jì)劃支持 Terraform 的 HCL 語法來作為 KubeVela 的另一種模板語言。在 CUE 模板中我們引用了阿里云的 RDS 定義，并抽象成 user、password等少量用戶字段（parameter）。

用戶：定義和使用云資源

這樣，用戶只需要在 Appfile 中，填寫一個(gè)新的Service，命名為  sample-db 而其類型就是我們上面定義的  aliyun-rds ，就可以在這個(gè)部分定義模板中提供的 user，password 等參數(shù)。

除此之外，用戶還可以在上面的  express-server 這個(gè)業(yè)務(wù)應(yīng)用中定義數(shù)據(jù)綁定，填寫名為 sample-db 的配置及其映射的環(huán)境變量名稱。

最后，用戶只需要一句  vela up 命令，KubeVela 就會(huì)拉起業(yè)務(wù)容器，然后自動(dòng)把 Terraform 創(chuàng)建的阿里云RDS返回的鏈接信息傳遞到業(yè)務(wù)的容器中，我們可以在最后一部分看到這個(gè)應(yīng)用已經(jīng)成功啟動(dòng)，并獲得了數(shù)據(jù)庫(kù)的連接信息。當(dāng)然，這個(gè)流程中的數(shù)據(jù)傳遞和編排功能，也是 KubeVela 內(nèi)置的核心能力。

總結(jié)

作為 Kubernetes 上第一個(gè)云原生平臺(tái)構(gòu)建引擎以及 OAM 模型的完整實(shí)現(xiàn)，KubeVela 為平臺(tái)構(gòu)建者提供的能力遠(yuǎn)不止這些，比如后續(xù)即將開源的統(tǒng)一應(yīng)用灰度框架、多集群多環(huán)境的交付組件、CRD Controller 的生命周期管理等等，都是 KubeVela 重點(diǎn)打造的的核心能力。限于篇幅就不再一一展開，非常歡迎大家到社區(qū)（https://kubevela.io/）中使用和反饋，了解更多的細(xì)節(jié)。

歡迎加入 KubeVela 社區(qū)

正如最開始所言，KubeVela 是一個(gè)由社區(qū)發(fā)起社區(qū)構(gòu)建的項(xiàng)目，所以在項(xiàng)目的早期，我們就已經(jīng)收獲了 38 名貢獻(xiàn)者，來自數(shù)十家不同的公司，這是一個(gè)非常開放的社區(qū)，也有大量的新功能在規(guī)劃和實(shí)現(xiàn)中，歡迎大家的貢獻(xiàn)、使用和反饋。

如果你想要更好的了解 KubeVela 項(xiàng)目，歡迎前往其官方網(wǎng)站上學(xué)習(xí)具體的示例和手冊(cè)。更高階的，可以嘗試為KubeVela 添加來自開源社區(qū)的插件能力。此外，如果你有任何關(guān)于擴(kuò)展 KubeVela 的奇妙想法，比如，基于 KubeVela 開發(fā)一個(gè)自己的云原生數(shù)據(jù)庫(kù)場(chǎng)景 PaaS 或者 AI 場(chǎng)景 PaaS，歡迎前往 OAM 社區(qū)通過 Issue 來進(jìn)行討論。

如果你想要進(jìn)一步交流，歡迎釘釘掃碼進(jìn)群，這里有一個(gè)近兩千人的社區(qū)：

最后阿里云云原生應(yīng)用管理平臺(tái)團(tuán)隊(duì)也在持續(xù)招聘中，如果你對(duì)我們的工作感興趣，也歡迎你投遞簡(jiǎn)歷至 jianbo.sjb@alibaba-inc.com 。

閱讀原文查看直播視頻