本文被收錄于專區(qū)
美國西部時間 2020 年 11 月 18 日蒋纬，在云原生技術(shù)“最高盛宴”的 KubeCon 北美峰會 2020 上尿扯，CNCF 應(yīng)用交付領(lǐng)域小組（CNCF SIG App Delivery) 與 Open Application Model (OAM) 社區(qū)，以及來自阿里云己儒、微軟云的 OAM 項目維護(hù)者們在演講中共同宣布了?KubeVela 開源項目的正式發(fā)布淑玫。
從 11 月 18 號到 20 號巾腕，在為期三天的KubeCon 北美峰會上有連續(xù) 3 場技術(shù)演講，會從不同維度介紹關(guān)于 KubeVela 項目的具體細(xì)節(jié)絮蒿，其中還包括一個長達(dá) 1 個半小時的 KubeVela 互動教學(xué)環(huán)節(jié)尊搬。多個重量級組織以如此規(guī)模和密度在 KubeCon 北美峰會演講中介紹一個首次發(fā)布的社區(qū)開源項目，在 KubeCon 誕生以來并不多見土涝。
什么是 KubeVela 佛寿？
一言以蔽之，KubeVela 是一個簡單易用且高度可擴(kuò)展的應(yīng)用管理平臺與核心引擎但壮。KubeVela 是基于 Kubernetes 與 OAM 技術(shù)構(gòu)建的冀泻。
詳細(xì)的說常侣，對于應(yīng)用開發(fā)人員來講，KubeVela 是一個非常低心智負(fù)擔(dān)的云原生應(yīng)用管理平臺腔长，核心功能是讓開發(fā)人員方便快捷地在 Kubernetes 上定義與交付現(xiàn)代微服務(wù)應(yīng)用袭祟，無需了解任何 Kubernetes 本身相關(guān)的細(xì)節(jié)验残。在這一點(diǎn)上捞附，KubeVela 可以被認(rèn)為是云原生社區(qū)的 Heroku。
另一方面您没，對于平臺團(tuán)隊來講鸟召，KubeVela 是一個強(qiáng)大并且高可擴(kuò)展的云原生應(yīng)用平臺核心引擎“迸簦基于這樣一個引擎欧募，平臺團(tuán)隊可以快速、高效地以 Kubernetes 原生的方式在 KubeVela 中植入任何來自云原生社區(qū)的應(yīng)用管理能力仆抵，從而基于 KubeVela 打造出自己需要的云原生平臺跟继，比如：云原生數(shù)據(jù)庫 PaaS、云原生 AI 平臺镣丑、甚至 Serverless 服務(wù)舔糖。在這一點(diǎn)上，KubeVela 可以被認(rèn)為是一個“以應(yīng)用為中心”的 Kubernetes 發(fā)行版莺匠，以 OAM 為核心金吗，讓平臺團(tuán)隊可以基于 KubeVela 快速打造出屬于自己的 PaaS、Serverless 乃至任何面向用戶的云原生平臺項目趣竣。
KubeVela 解決了什么問題摇庙？
現(xiàn)如今，云原生技術(shù)的迅猛發(fā)展可能讓很多人都感覺到眼花繚亂遥缕，但實際上卫袒，這個生態(tài)的總體發(fā)展趨勢和主旋律，是通過 Kubernetes 搭建了一個統(tǒng)一的基礎(chǔ)設(shè)施抽象層单匣，為平臺團(tuán)隊屏蔽掉了“計算”玛臂、“網(wǎng)絡(luò)”、“存儲”等過去我們不得不關(guān)注的基礎(chǔ)設(shè)施概念封孙，使得我們能夠基于 Kubernetes 方便地構(gòu)建出任何我們想要的垂直業(yè)務(wù)系統(tǒng)而無需關(guān)心任何基礎(chǔ)設(shè)施層的細(xì)節(jié)迹冤。這正是 Kubernetes 被稱為云計算界的 Linux 以及 “Platform for Platforms” 的根本原因。
但是虎忌，當(dāng)我們把視角從平臺團(tuán)隊提升到垂直業(yè)務(wù)系統(tǒng)的最終用戶（如：應(yīng)用開發(fā)人員）的時候泡徙，我們會發(fā)現(xiàn) Kubernetes 這樣的定位和設(shè)計在解決了平臺團(tuán)隊的大問題之后，卻也為應(yīng)用開發(fā)者們帶來了挑戰(zhàn)和困擾膜蠢。比如堪藐，太多的用戶都在抱怨 Kubernetes “太復(fù)雜了”莉兰。究其原因，其實在于 Kubernetes 中的核心概念與體系礁竞，如：Pod糖荒、sidecar、Service模捂、資源管理捶朵、調(diào)度算法和 CRD 等等，主要是面向平臺團(tuán)隊而非最終用戶設(shè)計的狂男。缺乏面向用戶的設(shè)計不僅帶來了陡峭的學(xué)習(xí)曲線综看，影響了用戶的使用體驗，拖慢了研發(fā)效能岖食，甚至在很多情況下還會引發(fā)錯誤操作乃至生產(chǎn)故障（畢竟不可能每個業(yè)務(wù)開發(fā)人員都是 Kubernetes 專家）红碑。
這也是為什么在云原生生態(tài)中，幾乎每一個平臺團(tuán)隊都會基于 Kubernetes 構(gòu)建一個上層平臺給用戶使用泡垃。最簡單的也會給 Kubernetes 做一個圖形界面析珊，稍微正式一些的則往往會基于 Kubernetes 開發(fā)一個類 PaaS 平臺來滿足自己的需求。理論上講蔑穴，在 Kubernetes 生態(tài)中各種能力已經(jīng)非常豐富的今天忠寻，開發(fā)一個類 PaaS 平臺應(yīng)該是比較容易的。
然而現(xiàn)實卻往往不盡如人意澎剥。在大量的社區(qū)訪談當(dāng)中锡溯，我們發(fā)現(xiàn)在云原生技術(shù)極大普及的今天，基于 Kubernetes 構(gòu)建一個功能完善哑姚、用戶友好的上層應(yīng)用平臺祭饭，依然是中大型公司們的“專利”。這里的原因在于：
Kubernetes 生態(tài)本身的能力池固然豐富叙量，但是社區(qū)里卻并沒有一個可擴(kuò)展的倡蝙、方便快捷的方式，能夠幫助平臺團(tuán)隊把這些能力快速“組裝”成面向最終用戶的功能（Feature）绞佩。
這種困境帶來的結(jié)果寺鸥，就是盡管大家今天都在基于 Kubernetes 在構(gòu)建上層應(yīng)用平臺，但這些平臺本質(zhì)上卻并不能夠與 Kubernetes 生態(tài)完全打通品山，而都變成一個又一個的垂直“煙囪”胆建。
在開源社區(qū)中，這個問題會更加明顯肘交。在今天的 Kubernetes 社區(qū)中笆载，不乏各種“面向用戶”、“面向應(yīng)用”的 Kubernetes 上層系統(tǒng)。但正如前文所述凉驻，這些平臺都無一例外的引入了自己的專屬上層抽象腻要、用戶界面和插件機(jī)制。這里最典型的例子包括經(jīng)典 PaaS 項目比如 Cloud Foundry涝登，也包括各種 Serverless 平臺雄家。作為一個公司的平臺團(tuán)隊，我們實際上只有兩個選擇：要么把自己局限在某種垂直的場景中來適配和采納某個開源上層平臺項目胀滚；要么就只能自研一個符合自己訴求的上層平臺并且造無數(shù)個社區(qū)中已經(jīng)存在的“輪子”趟济。
那么，有沒有”第三種選擇”能夠讓平臺團(tuán)隊在不造輪子蛛淋、完全打通 Kubernetes 生態(tài)的前提下咙好，輕松的構(gòu)建面向用戶的上層平臺呢篡腌？
KubeVela 如何解決上述問題褐荷？
KubeVela 項目的創(chuàng)立初衷，就是以一個統(tǒng)一的方式同時解決上述最終用戶與平臺團(tuán)隊所面臨的困境嘹悼。這也是為何在設(shè)計中叛甫，KubeVela 對最終用戶和平臺團(tuán)隊這兩種群體進(jìn)行了單獨(dú)的畫像，以滿足他們不同的訴求杨伙。
由于 KubeVela 默認(rèn)的功能集與“Heroku”類似（即：主要面向應(yīng)用開發(fā)人員）其监，所以在下文中，我們會以應(yīng)用開發(fā)人員或者開發(fā)者來代替最終用戶限匣。但我們很快也會講到抖苦，KubeVela 里的每一個功能，都是一個插件米死，作為平臺團(tuán)隊锌历，你可以輕松地“卸載”它的所有內(nèi)置能力、然后“安裝”自己需要的任何社區(qū)能力峦筒，讓 KubeVela 變成一個完全不一樣的系統(tǒng)究西。
1. 應(yīng)用開發(fā)者眼中的 KubeVela
前面已經(jīng)提到，對于開發(fā)者來說物喷，KubeVela 是一個簡單卤材、易用、又高可擴(kuò)展的云原生應(yīng)用管理工具峦失，它可以讓開發(fā)者以極低的心智負(fù)擔(dān)和上手成本在 Kubernetes 上定義與部署應(yīng)用扇丛。而關(guān)于整個系統(tǒng)的使用，開發(fā)者只需要編寫一個 docker-compose 風(fēng)格應(yīng)用描述文件 Appfile 即可尉辑，不需要接觸和學(xué)習(xí)任何 Kubernetes 層的相關(guān)細(xì)節(jié)帆精。
1）一個 Appfile 示例
在下述例子中，我們會將一個叫做 vela.yaml 的 Appfile 放在你的應(yīng)用代碼目錄中（比如應(yīng)用的 GitHub Repo）。這個 Appfile 定義了如何將這個應(yīng)用編譯成 Docker 鏡像实幕，如何將鏡像部署到 Kubernetes吝镣，如何配置外界訪問應(yīng)用的路由和域名，又如何讓 Kubernetes 自動根據(jù) CPU 使用量來水平擴(kuò)展這個應(yīng)用昆庇。
只要有了這個 20 行的配置文件末贾，你接下來唯一需要的事情就是 $ vela up，這個應(yīng)用就會被部署到 Kubernetes 中然后被外界以https://example.com/testapp的方式訪問到整吆。
2）Appfile 是如何工作的拱撵？
在 KubeVela 的 Appfile 背后，有著非常精妙的設(shè)計表蝙。首先需要指出的就是拴测，這個 Appfile 是沒有固定的 Schema 的。
什么意思呢府蛇？這個 Appfile 里面你能夠填寫的每一個字段集索，都是直接取決于當(dāng)前平臺中有哪些工作負(fù)載類型（Workload Types）和應(yīng)用特征（Traits）是可用的。而熟悉 OAM 的同學(xué)都知道汇跨，這兩個概念务荆，正是 OAM 規(guī)范的核心內(nèi)容，其中：
工作負(fù)載類型（Workload Type）穷遂，定義的是底層基礎(chǔ)設(shè)施如何運(yùn)行這個應(yīng)用函匕。在上面的例子中，我們聲明：名叫 testapp 的應(yīng)用會啟動一個類型為“在線 Web 服務(wù)（Web Service）” 的工作負(fù)載蚪黑，其實例的名字是 express-server盅惜。
應(yīng)用特征（Traits），則為工作負(fù)載實例加上了運(yùn)維時配置忌穿。在上面的例子中抒寂，我們定義了一個 Route Trait 來描述應(yīng)用如何被從外界訪問，以及一個 Autoscale Trait 來描述應(yīng)用如何根據(jù) CPU 使用量進(jìn)行自動的水平擴(kuò)容伴网。
而正是基于這種模塊化的設(shè)計蓬推，這個 Appfile 本身是高度可擴(kuò)展的。當(dāng)任何一個新的 Workload Type 或者 Trait 被安裝到平臺后澡腾，用戶就可以立刻在 Appfile 里聲明使用這個新增的能力沸伏。舉個例子，比如后面平臺團(tuán)隊新開發(fā)了一個用來配置應(yīng)用監(jiān)控屬性的運(yùn)維側(cè)能力动分，叫做 Metrics毅糟。那么只需要舉手之撈，應(yīng)用開發(fā)者就可以立刻使用 $ vela show metrics 命令查看這個新增能力的詳情澜公，并且在 Appfile 中使用它姆另，如下所示：
這種簡單友好喇肋、又高度敏捷的使用體驗，正是 KubeVela 在最終用戶側(cè)提供的主要體感迹辐。
3）Vela Up 命令
前面提到蝶防，一旦 Appfile 準(zhǔn)備好，開發(fā)者只需要一句 vela up 命令就可以把整個應(yīng)用連同它的運(yùn)維特征部署到 Kubernetes 中明吩。部署成功后间学，你可以使用 vela status 來查看整個應(yīng)用的詳情，包括如何訪問這個應(yīng)用印荔。
通過 KubeVela 部署的應(yīng)用會被自動設(shè)置好訪問 URL（以及不同版本對應(yīng)的不同 URL）低葫，并且會由cert-manager生成好證書。與此同時仍律，KubeVela 還提供了一系列輔助命令（比如：vela logs 和 vela exec）來幫助你在無需成為 Kubernetes 專家的情況下更好地管理和調(diào)試你的應(yīng)用嘿悬。如果你對上述由 KubeVela 帶來的開發(fā)者體驗感興趣的話，歡迎前往 KubeVela 項目的用戶使用文檔來了解更多水泉。
而接下來善涨，我們要切換一下視角，感受一下平臺團(tuán)隊眼中的 KubeVela 又是什么樣子的茶行。
2. 平臺工程師眼中的 KubeVela
實際上躯概，前面介紹到的所有開發(fā)者側(cè)體驗登钥，都離不開 KubeVela 在平臺側(cè)進(jìn)行的各種創(chuàng)新性設(shè)計與實現(xiàn)畔师。也正是這些設(shè)計的存在，才使得 KubeVela 不是一個簡單的 PaaS 或者 Serverless牧牢，而是一個可以由平臺工程師擴(kuò)展成任意垂直系統(tǒng)的云原生平臺內(nèi)核看锉。
具體來說，KubeVela 為平臺工程師提供了三大核心能力塔鳍，使得基于 Kubernetes 構(gòu)建上述面向用戶的云原生平臺從“陽春白雪”變成了“小菜一碟”：
第一：以應(yīng)用為中心伯铣。在 Appfile 背后，其實就是“應(yīng)用”這個概念轮纫，它是基于 OAM 模型實現(xiàn)的腔寡。通過這樣的方式，KubeVela 讓“應(yīng)用”這個概念成為了整個平臺對用戶暴露的核心 API掌唾。KubeVela 中的所有能力放前，都是圍繞著“應(yīng)用”展開的。這正是為何基于 KubeVela 擴(kuò)展和構(gòu)建出來的平臺糯彬，天然是用戶友好的：對于一個開發(fā)者來說凭语，他只關(guān)心“應(yīng)用”，而不是容器或者 Kubernetes撩扒；而 KubeVela 會確保構(gòu)建整個平臺的過程似扔，也只與應(yīng)用層的需求有關(guān)。
第二：Kubernetes 原生的高可擴(kuò)展性。在前面我們已經(jīng)提到過炒辉，Appfile 是一個由 Workload Type 和 Trait 組成的豪墅、完全模塊化的對象。而 OAM 模型的一個特點(diǎn)黔寇，就是任意一個 Kubernetes API 資源但校，都可以直接基于 Kubernetes 的 CRD 發(fā)現(xiàn)機(jī)制注冊為一個 Workload Type 或者 Trait。這種可擴(kuò)展性啡氢，使得 KubeVela 并不需要設(shè)計任何“插件系統(tǒng)”：KubeVela 里的每一個能力状囱，都是插件，而整個 Kubernetes 社區(qū)倘是，就是 KubeVela 原生的插件中心亭枷。
第三：簡單友好但高度可擴(kuò)展的用戶側(cè)抽象體系。在了解了 Appfile 之后搀崭，你可能已經(jīng)對這個對象的實現(xiàn)方式產(chǎn)生了好奇叨粘。實際上，KubeVela 中并不是簡單的實現(xiàn)了一個 Appfile瘤睹。在平臺層忆矛，KubeVela 在 OAM 模型層實現(xiàn)中集成了CUELang這種簡潔強(qiáng)大的模板語言，從而為平臺工程師基于 Kubernetes API 對象定義用戶側(cè)抽象（即：“最后一公里”抽象）提供了一個標(biāo)準(zhǔn)焕数、通用的配置工具辆它。更重要的是，平臺工程師或者系統(tǒng)管理員获茬，可以隨時隨地的每個能力對應(yīng)的 CUE 模板進(jìn)行修改港庄，這些修改一旦提交到 Kubernetes，用戶在 Appfile 里就可以立刻使用到新的抽象恕曲，不需要重新部署或者安裝 KubeVela鹏氧。
在具體實現(xiàn)層，KubeVela 是基于 OAM Kubernetes Runtime 構(gòu)建的佩谣，同時采用 KEDA 把还，F(xiàn)lagger，Prometheus 等生態(tài)項目作為 Trait 的背后的依賴茸俭。當(dāng)然吊履，這些依賴只是 KubeVela 的選型，你可以隨時為 KubeVela 定制和安裝你喜歡的任何能力作為 Workload Type 或者 Trait瓣履。綜合以上講解率翅，KubeVela 項目的整體架構(gòu)由用戶界面層，模型層袖迎，和能力管理層三部分組成冕臭，如下所示：
有了 KubeVela腺晾，平臺工程師終于擁有了一個可以方便快捷地將任何一個 Kubernetes 社區(qū)能力封裝抽象成一個面向用戶的上層平臺特性的強(qiáng)大工具。而作為這個平臺的最終用戶辜贵，應(yīng)用開發(fā)者們只需要學(xué)習(xí)這些上層抽象悯蝉，在一個配置文件中描述應(yīng)用，就可以一鍵交付出去托慨。
3. KubeVela VS 經(jīng)典 PaaS?
很多人可能會問鼻由，KubeVela 跟經(jīng)典 PaaS 的主要區(qū)別和聯(lián)系是什么呢？
事實上厚棵，大多數(shù)經(jīng)典 PaaS 都能提供完整的應(yīng)用生命周期管理功能蕉世，同時也非常關(guān)注提供簡單友好的用戶體驗，提升研發(fā)效能婆硬。在這些點(diǎn)上狠轻，KubeVela 跟經(jīng)典 PaaS 的目標(biāo)，是非常一致的彬犯。
但另一方面向楼，經(jīng)典 PaaS 往往是不可擴(kuò)展的（比如 Rancher 的 Rio 項目），或者會引入屬于自己的插件生態(tài)（哪怕這個 PaaS 是完全基于 Kubernetes 構(gòu)建的）谐区，以此來確保平臺本身的用戶體驗和能力的可控制性（比如 Cloud Foundry 或者 Heroku 的插件中心）湖蜕。
相比之下，KubeVela 的設(shè)計是完全不同的宋列。KubeVela 的目標(biāo)昭抒，從一開始就是利用整個 Kubernetes 社區(qū)作為自己的“插件中心”，并且“故意”把它的每一個內(nèi)置能力都設(shè)計成是獨(dú)立的虚茶、可插拔的插件戈鲁。這種高度可擴(kuò)展的模型，背后其實有著精密的設(shè)計與實現(xiàn)嘹叫。比如，KubeVela 如何確保某個完全獨(dú)立的 Trait 一定能夠綁定于某種 Workload Type诈乒？如何檢查這些相互獨(dú)立的 Trait 是否沖突罩扇？這些挑戰(zhàn)，正是 Open Application Model（OAM）作為 KubeVela 模型層的起到的關(guān)鍵作用怕磨，一言以蔽之：OAM 是一個高度可擴(kuò)展的應(yīng)用定義與能力管理模型喂饥。
KubeVela 和 OAM 社區(qū)歡迎大家設(shè)計和制作任何 Workload Type 和 Trait 的定義文件。只要把它們存放在 GitHub 上肠鲫，全世界任何一個 KubeVela 用戶就都可以在自己的 Appfile 里使用你所設(shè)計的能力员帮。具體的方式，請參考 $ vela cap （即：插件能力管理命令）的使用文檔导饲。
了解更多
KubeVela 項目是 OAM 社區(qū)的官方項目捞高，旨在取代原先的Rudr項目氯材。不過，與 Rudr 主要作為“參考實現(xiàn)”的定位不同硝岗，KubeVela 既是一個端到端氢哮、面向全量場景的 OAM Kubernetes 完整實現(xiàn)，同時也是阿里云 EDAS 服務(wù)和內(nèi)部多個核心 PaaS/Serverless 生產(chǎn)系統(tǒng)底層的核心組件型檀。此外冗尤，KubeVela 中 Apppfile 的設(shè)計，也是 OAM 社區(qū)在 OAM 規(guī)范中即將引入的“面向用戶側(cè)對象”的核心部分胀溺。
