KubeVela 1.0 ：开启可编程式应用平台的未来
作者 | KubeVela 項(xiàng)目維護(hù)者
來(lái)源 | 阿里巴巴云原生公眾號(hào)
作為 OAM（Open Application Model）在 Kubernetes 上的實(shí)現(xiàn)，KubeVela 項(xiàng)目從 oam-kubernetes-runtime 演進(jìn)至今不過(guò)半年多時(shí)間，但發(fā)展勢(shì)頭非常迅猛，不僅連續(xù)登上 GitHub Go 語(yǔ)言趨勢(shì)榜首和 HackerNews 首頁(yè)，更是迅速收獲了包括 MasterCard、Springer Nature、第四范式、SILOT、Upbound 等來(lái)自世界各地、不同行業(yè)的終端用戶，甚至還出現(xiàn)了像 Oracle Cloud、Napptive 等基于它構(gòu)建的商業(yè)化產(chǎn)品。就在 2021年3月底，KubeVela 社區(qū)宣布包含所有穩(wěn)定版 API 的 v1.0 版本發(fā)布，正式開始向企業(yè)級(jí)生產(chǎn)可用邁進(jìn)。
不過(guò)，如果你對(duì)云原生領(lǐng)域不太關(guān)注，可能對(duì) KubeVela 還沒(méi)有做過(guò)太深入的了解。別著急，本文就借著 v1.0 發(fā)布之際，為你詳細(xì)的梳理一次 KubeVela 項(xiàng)目的發(fā)展脈絡(luò)，解讀它的核心思想和愿景，領(lǐng)悟這個(gè)正冉冉升起的云原生應(yīng)用管理平臺(tái)之星背后的“道之所在”。
首先，什么是 KubeVela？
一言以蔽之，KubeVela 是一個(gè)“可編程式”的云原生應(yīng)用管理與交付平臺(tái)。
可是，什么是“可編程”呢？它跟 Kubernetes 又是什么關(guān)系？它能幫助我們解決什么問(wèn)題？
PaaS 系統(tǒng)的“能力困境”
PaaS 系統(tǒng)（比如 Cloud Foundry、Heroku 等）自誕生以來(lái)，就以其簡(jiǎn)單、高效的應(yīng)用部署體驗(yàn)而被所有人津津樂(lè)道。然而，大家也知道，我們今天的“云原生”，卻是一個(gè) Kubernetes 大行其道的世界，曾經(jīng)的 PaaS（包括 Docker）到底遇到了什么問(wèn)題呢？
其實(shí)任何一個(gè)嘗試使用過(guò) PaaS 的人，都會(huì)對(duì)這種系統(tǒng)的一個(gè)本質(zhì)缺陷感觸頗深，那就是 PaaS 系統(tǒng)的“能力困境”。
圖 1 - PaaS系統(tǒng)的能力困境
如圖 1 所示，PaaS 系統(tǒng)在最開始使用的時(shí)候，往往體驗(yàn)非常好，也總能恰如其分地解決問(wèn)題。但隨著使用時(shí)間的推移，一個(gè)非常討厭的情況就會(huì)出現(xiàn)：應(yīng)用的訴求，開始超過(guò) PaaS 系統(tǒng)能夠提供的能力。而更可怕的是，一旦這個(gè)問(wèn)題出現(xiàn)，用戶對(duì) PaaS 系統(tǒng)的滿意度就會(huì)斷崖式下跌，這是因?yàn)闊o(wú)論是重新開發(fā)平臺(tái)增加功能，還是修改應(yīng)用去適配平臺(tái)，都是一項(xiàng)投入巨大但收益很低的事情。更何況所有人這時(shí)候都會(huì)開始對(duì)平臺(tái)失去信心：誰(shuí)知道下一次系統(tǒng)或者應(yīng)用大改，是不是很快又要發(fā)生了？
這個(gè)“命門”，可以說(shuō)是 PaaS 雖然具備云原生所需的一切要素、卻最終未能成為主流的主要原因。
而相比之下，Kubernetes 的特點(diǎn)就比較突出了。盡管 Kubernetes 被人詬病“復(fù)雜”，但隨著應(yīng)用復(fù)雜度的提升，Kubernetes 的優(yōu)點(diǎn)就會(huì)慢慢體現(xiàn)出來(lái)，尤其是當(dāng)用戶的訴求開始需要你去通過(guò) CRD Controller 支持的時(shí)候，你一定會(huì)慶幸：幸虧當(dāng)初選了 K8s。
這里的原因在于，Kubernetes 的本質(zhì)其實(shí)是一個(gè)強(qiáng)大和健壯的基礎(chǔ)設(shè)施能力接入平臺(tái)，也就是所謂的 The Platform for Platform。它的這套 API 和工作方式，天然不適合直接跟人去進(jìn)行交互，但卻能夠以非常一致的方式接入任何基礎(chǔ)設(shè)施能力，為平臺(tái)工程師構(gòu)建 PaaS 等上層系統(tǒng)提供“無(wú)限彈藥”。這種“BUG 級(jí)”的基礎(chǔ)設(shè)施能力供給方式，讓再精密的 PaaS 系統(tǒng)相比之下都像是一個(gè)礙手礙腳的“玩具”，這一點(diǎn)對(duì)于很多正掙扎于構(gòu)建內(nèi)部應(yīng)用平臺(tái)的大型企業(yè)來(lái)說(shuō)（它們才是 PaaS 廠商真正想贏取的用戶）無(wú)異于是久旱逢甘霖。
云原生 PaaS ：新瓶裝舊酒
前面提到的一點(diǎn)其實(shí)很重要：假如一個(gè)大型企業(yè)要決定采納一個(gè) PaaS 系統(tǒng)還是選擇 Kubernetes，平臺(tái)團(tuán)隊(duì)往往才是能決定拍板的那一方。但另一方面，平臺(tái)團(tuán)隊(duì)的意見(jiàn)雖然重要，并不意味著最終用戶的想法就可以不管了。事實(shí)上，在任何一個(gè)組織中，直接創(chuàng)造價(jià)值的業(yè)務(wù)團(tuán)隊(duì)才持有最高的話語(yǔ)權(quán)，只不過(guò)起作用的時(shí)間稍晚而已。
所以在絕大多數(shù)情況下，任何一個(gè)平臺(tái)團(tuán)隊(duì)拿到 Kubernetes 之后，并不會(huì)直接去讓業(yè)務(wù)去學(xué)習(xí) Kubernetes，而是會(huì)基于 Kubernetes 構(gòu)建一個(gè)“云原生” PaaS，用它去服務(wù)業(yè)務(wù)方。
咦，于是乎大家兜兜繞繞，又回到了故事的原點(diǎn)。唯一的變化是，咱們今天這個(gè) PaaS 是基于 K8s 實(shí)現(xiàn)的，確實(shí)輕松了不少。
但實(shí)際情況呢？
這個(gè)基于 Kubernetes 構(gòu)建 PaaS 的故事，看似美好，其實(shí)整個(gè)過(guò)程卻難免有些“心酸”。說(shuō)的好聽點(diǎn)是開發(fā) PaaS，其實(shí) 80% 的工作是在設(shè)計(jì)和開發(fā) UI，剩下的工作則是安裝和運(yùn)維 K8s 插件。而更令人遺憾的是，我們這樣構(gòu)建出來(lái)的 PaaS，其實(shí)跟以前的 PaaS 沒(méi)有本質(zhì)不同，任何時(shí)候用戶訴求改變，我們都需要花大量時(shí)間重新設(shè)計(jì)、修改前端、排期上線。結(jié)果就是，K8s 日新月異的生態(tài)和無(wú)限可擴(kuò)展的特性，都被“封印”在我們親手構(gòu)建的 PaaS 之下“不見(jiàn)天日”。終于有一天，業(yè)務(wù)方也實(shí)在忍不住要問(wèn)了：你們平臺(tái)團(tuán)隊(duì)上了 K8s，到底有啥價(jià)值？
上面這個(gè)“為了解決 PaaS 的固有限制，結(jié)果又引入一個(gè)新的 PaaS 和限制”的困局，是現(xiàn)今很多公司在落地云原生技術(shù)的過(guò)程中遇到的一個(gè)核心問(wèn)題。我們似乎再一次把用戶鎖定在一層固定的抽象和能力集當(dāng)中。所謂云原生化的好處，僅僅體現(xiàn)在咱們自己開發(fā)這個(gè)平臺(tái)變得簡(jiǎn)單了 ——?而對(duì)業(yè)務(wù)用戶來(lái)說(shuō)，這似乎沒(méi)什么太大的意義。
更為麻煩的是，云原生和 K8s 的引入，也讓運(yùn)維人員這個(gè)角色變得非常微妙。本來(lái)，他們所掌握的業(yè)務(wù)運(yùn)維最佳實(shí)踐，是整個(gè)公司中最重要的經(jīng)驗(yàn)和資產(chǎn)。然而，在企業(yè)云原生化之后，這個(gè)工作的內(nèi)容都必須交給 K8s 去接管。所以，很多人都說(shuō)，K8s 要讓“運(yùn)維”失業(yè)了，這個(gè)說(shuō)法雖然有點(diǎn)夸張，但確實(shí)反映出了這個(gè)趨勢(shì)帶來(lái)的焦慮。而且我們不禁也在從另一個(gè)角度思考，云原生化的背景下，應(yīng)用運(yùn)維的經(jīng)驗(yàn)和最佳實(shí)踐，又該怎么落實(shí)？就拿一個(gè)簡(jiǎn)單的工作負(fù)載舉例子，一個(gè) K8s Deployment 對(duì)象，哪些字段暴露給用戶、哪些不能，雖然體現(xiàn)在 PaaS 的 UI 上，但肯定不能是靠前端開發(fā)說(shuō)了算的吧。
KubeVela：下一代可編程式應(yīng)用平臺(tái)
阿里巴巴是整個(gè)業(yè)界在云原生技術(shù)上的先行者之一。所以上述這個(gè)圍繞著應(yīng)用平臺(tái)的云原生技術(shù)難題，相對(duì)也比較早的暴露了出來(lái)。在 2019 年末，阿里基礎(chǔ)技術(shù)團(tuán)隊(duì)與研發(fā)效能團(tuán)隊(duì)合作針對(duì)這個(gè)問(wèn)題進(jìn)行了大量的探索與嘗試，最終提出了“可編程式”應(yīng)用平臺(tái)的思想，并以 OAM 和 KubeVela 開源項(xiàng)目的方式同大家見(jiàn)面。這套體系，目前已經(jīng)迅速成為了阿里構(gòu)建應(yīng)用平臺(tái)的主流方式。
簡(jiǎn)單地說(shuō)，所謂“可編程”，指的是我們?cè)跇?gòu)建上層平臺(tái)的過(guò)程中，不會(huì)直接在 Kubernetes 本身上疊加抽象（哪怕只是一個(gè) UI），而是通過(guò) CUE 模板語(yǔ)言這種代碼化（Code）的方式來(lái)抽象和管理、并透出基礎(chǔ)設(shè)施提供的能力。
舉個(gè)例子，比如阿里的某個(gè) PaaS 要對(duì)用戶提供一個(gè)能力叫做 Web Service，這個(gè)能力是指任何需要從外部訪問(wèn)的服務(wù)，都以 K8s Deployment + Service 的方式來(lái)部署，對(duì)用戶暴露鏡像、端口等配置項(xiàng)。
在傳統(tǒng)方法中，我們可能會(huì)實(shí)現(xiàn)一個(gè) CRD 叫做 WebService，然后在它的 Controller 里來(lái)封裝 Deployment 和 Service。但這必然會(huì)帶來(lái)前面 PaaS “能力困境”的問(wèn)題：
而在 KubeVela 中，像上面這樣面向用戶的功能，則可以通過(guò)一段簡(jiǎn)單的 CUE 模板來(lái)描述（這里有完整的例子）。而當(dāng)你編寫好這樣一個(gè) CUE 文件之后，直接通過(guò)一句 kubectl apply，用戶就可以立即使用到這個(gè)能力：
$ kubectl apply -f web-service.yaml更重要的是，只要執(zhí)行上面這條命令，KubeVela 就會(huì)自動(dòng)根據(jù) CUE 模板內(nèi)容生成這個(gè)能力的幫助文檔和前端表單結(jié)構(gòu)，所以用戶立刻就會(huì)在 PaaS 里面看到這個(gè) WebService 功能如何使用（比如有哪些參數(shù)、字段類型），并且直接使用它，如下 圖 2 所示：
圖 2 - KubeVela 自動(dòng)生成表單示意圖
在 KubeVela 中，平臺(tái)的所有能力比如金絲雀發(fā)布、Ingress，Autoscaler 等等，都是通過(guò)這種方式定義、維護(hù)和透出給用戶的。這種端到端打通用戶體驗(yàn)層與 Kubernetes 能力層的設(shè)計(jì)，使得平臺(tái)團(tuán)隊(duì)可以以極低的成本快速實(shí)現(xiàn) PaaS 以及任何上層平臺(tái)（比如 AI PaaS，大數(shù)據(jù) PaaS），同時(shí)高效地響應(yīng)用戶的持續(xù)演進(jìn)訴求。
1. 不只是 Kubernetes 原生，是 Platform-as-Code
尤為重要的是，在實(shí)現(xiàn)層，KubeVela 并不是簡(jiǎn)單的在客戶端去渲染 CUE 模板，而是使用 Kubernetes Controller 去渲染和維護(hù)生成的 API 對(duì)象。這里的原因有三點(diǎn)：
所以說(shuō)，KubeVela 的上述設(shè)計(jì)，從根本上解決了傳統(tǒng) IaC 系統(tǒng)用戶體驗(yàn)雖好，但是生產(chǎn)環(huán)境上“靠不住”的老大難問(wèn)題，又在絕大多數(shù)情況下讓整個(gè)平臺(tái)響應(yīng)用戶需求的時(shí)間從原先的數(shù)周，降低到幾小時(shí)，完全打通了云原生技術(shù)與最終用戶體驗(yàn)之間的壁壘。而它完全基于 Kubernetes 原生方式實(shí)現(xiàn)，確保了整個(gè)平臺(tái)嚴(yán)格的健壯性，并且無(wú)論任何 CI/CD 以及 GitOps 工具，只要它支持 Kubernetes，就一定支持 KubeVela，沒(méi)有任何集成成本。
這套體系，被大家形象的稱為：Platform-as-Code（平臺(tái)即代碼）。
2. 別急，KubeVela 當(dāng)然支持 Helm
提到 KubeVela 以及 CUE 模板這些概念，很多小伙伴就開始問(wèn)了：KubeVela 跟 Helm 又是什么關(guān)系啊？
實(shí)際上，Helm 和 CUE 一樣，都是一種封裝和抽象 Kubernetes API 資源的工具，而且 Helm 使用的是 Go 模板語(yǔ)言，天然適配 KubeVela Platform-as-Code 的設(shè)計(jì)思路。
所以在 KubeVela v1.0 中，任何 Helm 包都可以作為應(yīng)用組件被部署起來(lái)，并且更重要的是，無(wú)論是 Helm 組件還是 CUE 組件，KubeVela 里的所有能力對(duì)它們都適用。這就使得通過(guò) KubeVela 交付 Helm 包可以給你帶來(lái)一些非常重要但是現(xiàn)有工具很難提供的能力。
舉個(gè)例子，Helm 包其實(shí)很多是來(lái)自第三方的，比如 Kafka Chart，可能就是 Kafka 背后的公司制作的。所以一般情況下，你只能用，但不能改它里面的模板，否則修改后的 Chart 你就得自己維護(hù)了。
而在 KubeVela 中，這個(gè)問(wèn)題就很容易解決。具體來(lái)說(shuō)，KubeVela 提供一個(gè)運(yùn)維側(cè)的能力叫做 Patch，它允許你以聲明式的方式給待交付組件（比如 Helm 包）里封裝的資源打 Patch，而不用去關(guān)心這個(gè)字段有沒(méi)有通過(guò) Chart 模板透出來(lái)，而且 Patch 操作的時(shí)機(jī)，是在資源對(duì)象被 Helm 渲染出來(lái)之后、提交到 Kubernetes 集群處理之前的這個(gè)時(shí)間，不會(huì)讓組件實(shí)例重啟。
再比如，通過(guò) KubeVela 內(nèi)置的灰度發(fā)布系統(tǒng)（即：AppRollout 對(duì)象），你還可以將 Helm 包作為一個(gè)整體進(jìn)行漸進(jìn)式發(fā)布且無(wú)需關(guān)心工作負(fù)載類型（即：哪怕 Chart 里是 Operator，KubeVela 也可以進(jìn)行灰度發(fā)布），而不是像 Flagger 等控制器那樣只能針對(duì)單一的 Deployment 工作負(fù)載進(jìn)行發(fā)布。此外，如果將 KubeVela 同 Argo Workflow 集成，你還可以輕松的指定 Helm 包的發(fā)布順序和拓?fù)涞雀鼜?fù)雜的行為。
所以說(shuō)，KubeVela v1.0 不僅支持 Helm，它的目標(biāo)是成為交付、發(fā)布和運(yùn)維 Helm Chart 最強(qiáng)大的平臺(tái)。一些社區(qū)同學(xué)已經(jīng)在本文發(fā)布之前就迫不及待的試用了這部分功能，大家可以移步到這篇文章來(lái)閱讀。
3. 全自助式用戶體驗(yàn)和云原生時(shí)代的運(yùn)維
得益于 Platform-as-Code 的設(shè)計(jì)，基于 KubeVela 的應(yīng)用平臺(tái)天然對(duì)用戶是自助式的使用方式，如圖 3 所示。
圖 3 - KubeVela 自助式能力交付流程圖
具體來(lái)說(shuō)，平臺(tái)團(tuán)隊(duì)只需要極小的人力成本就可以在系統(tǒng)中維護(hù)大量的、代碼化的“能力模板”。而作為平臺(tái)的終端用戶，業(yè)務(wù)團(tuán)隊(duì)只需要根據(jù)自己的應(yīng)用部署需求在 PaaS UI 上選擇幾個(gè)能力模板，填入?yún)?shù)，就可以自助式的完成一次交付，無(wú)論這個(gè)應(yīng)用多么復(fù)雜，業(yè)務(wù)用戶的學(xué)習(xí)成本都非常低，并且默認(rèn)就會(huì)遵循模板中所定義的規(guī)范；而這個(gè)應(yīng)用的部署和運(yùn)維過(guò)程，則由 Kubernetes 以自動(dòng)化的方式去管理，從而減輕了業(yè)務(wù)用戶大量的心智負(fù)擔(dān)。
而更為重要的是，這種機(jī)制的存在，讓運(yùn)維人員再次成為了平臺(tái)團(tuán)隊(duì)中的核心角色。具體的說(shuō)，他們通過(guò) CUE 或者 Helm 設(shè)計(jì)和編寫能力模板，然后把這些模版安裝到 KubeVela 系統(tǒng)中給業(yè)務(wù)團(tuán)隊(duì)使用。大家試想一下，這個(gè)過(guò)程，其實(shí)就是運(yùn)維人員把業(yè)務(wù)對(duì)平臺(tái)的訴求，結(jié)合整個(gè)平臺(tái)的最佳實(shí)踐，以代碼化的方式固化成可被復(fù)用和定制的能力模塊的過(guò)程。而且這個(gè)過(guò)程中，運(yùn)維并不需要去進(jìn)行復(fù)雜的 K8s 定制和開發(fā)，只需要理解 k8s 的核心概念即可。另一方面，這些代碼化的能力模塊，復(fù)用性極高，變更和上線非常容易，并且大多數(shù)情況下不需要額外的研發(fā)成本，可以說(shuō)是最敏捷的“云原生”運(yùn)維實(shí)踐，能夠真正讓業(yè)務(wù)感受到云原生“研發(fā)、交付、運(yùn)維高效一體化”的核心價(jià)值。
4. 多環(huán)境多集群、多版本應(yīng)用交付
KubeVela v1.0 的另一個(gè)重大更新，就是改進(jìn)了系統(tǒng)的部署結(jié)構(gòu)，提供了 Control Plane （控制平面）模式，從而具備了面向多環(huán)境、多集群進(jìn)行版本化應(yīng)用交付的能力。所以現(xiàn)在，一個(gè)典型的生產(chǎn)環(huán)境 KubeVela 部署形態(tài)如下圖 4 所示：
圖 4 - KubeVela 控制平面部署形態(tài)示意圖
在這個(gè)場(chǎng)景下，KubeVela 支持為多環(huán)境應(yīng)用進(jìn)行描述，支持為應(yīng)用配置 Placement 策略以及應(yīng)用多版本同時(shí)部署在線、并通過(guò) Istio 進(jìn)行灰度的發(fā)布模型。大家可以通過(guò)這個(gè)文檔進(jìn)行深入了解。
在 v1.0 發(fā)布之后，KubeVela 會(huì)圍繞上述架構(gòu)進(jìn)行持續(xù)的演進(jìn)，其中的一個(gè)主要的工作項(xiàng)就是將 KubeVela Dashboard、CLI 和 Appfile 全部遷移和升級(jí)到同 KubeVela 控制平面通過(guò) gRPC 進(jìn)行交互，而不是像之前的版本那樣需要直接跟目標(biāo)集群打交道。這部分工作目前尚在進(jìn)行中，歡迎對(duì)構(gòu)建下一代“可編程式”開發(fā)者體驗(yàn)有心得的同學(xué)一起來(lái)參與。與此同時(shí)，歐洲知名科技出版商 Springer Nature 也正在一起參與這部分工作以便從 CloudFoundry 上平滑遷移到 KubeVela。
結(jié)語(yǔ)
如果我們總結(jié)一下 KubeVela 今天的設(shè)計(jì)與能力，其實(shí)不難發(fā)現(xiàn)它是今天云原生應(yīng)用平臺(tái)發(fā)展的一條必然路徑：
更重要的是，KubeVela 以 Platform-as-Code 的設(shè)計(jì)思想，給未來(lái)基于云原生的應(yīng)用平臺(tái)團(tuán)隊(duì)提出了更加合理的組織方式：
而基于這套體系，KubeVela 應(yīng)用平臺(tái)還可以用來(lái)實(shí)現(xiàn)強(qiáng)大的“無(wú)差別”應(yīng)用交付場(chǎng)景，達(dá)成完全與環(huán)境無(wú)關(guān)的云端應(yīng)用交付體驗(yàn)：
KubeVela v1.0 的發(fā)布是我們基于 OAM 模型以及云原生應(yīng)用交付使用場(chǎng)景最大化驗(yàn)證的結(jié)果，它不僅代表了穩(wěn)定的API，還代表了成熟的使用范式。然而這不代表結(jié)束，而是一個(gè)全新的開始，它開啟了一個(gè)“可編程式”應(yīng)用平臺(tái)的未來(lái)，這是一個(gè)能夠充分釋放云原生潛力、讓最終用戶和軟件交付方從第一天開始就充分享受云原生技術(shù)魅力的有效路徑。我們期待這個(gè)項(xiàng)目能達(dá)成它最樸素的愿景：Make shipping applications more enjoyable!
了解更多
您可以通過(guò)如下材料了解更多關(guān)于 KubeVela 以及 OAM 項(xiàng)目的細(xì)節(jié)：
總結(jié)
以上是生活随笔為你收集整理的KubeVela 1.0 ：开启可编程式应用平台的未来的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： SpringBoot Admin2.0
- 下一篇： 阿里巴巴云原生 etcd 服务集群管控优