KubeVela 1.0 ：開啓可編程式應用平臺的將來

做者 | KubeVela 項目維護者 來源 | 阿里巴巴雲原生公衆號

做爲 OAM（Open Application Model）在 Kubernetes 上的實現，KubeVela 項目從 oam-kubernetes-runtime 演進至今不過半年多時間，但發展勢頭很是迅猛，不只連續登上 GitHub Go 語言趨勢榜首和 HackerNews 首頁，更是迅速收穫了包括 MasterCard、Springer Nature、第四範式、SILOT、Upbound 等來自世界各地、不一樣行業的終端用戶，甚至還出現了像 Oracle Cloud、Napptive 等基於它構建的商業化產品。就在 2021年3月底，KubeVela 社區宣佈包含全部穩定版 API 的 v1.0 版本發佈，正式開始向企業級生產可用邁進。

不過，若是你對雲原生領域不太關注，可能對 KubeVela 尚未作過太深刻的瞭解。彆着急，本文就藉着 v1.0 發佈之際，爲你詳細的梳理一次 KubeVela 項目的發展脈絡，解讀它的核心思想和願景，領悟這個正冉冉升起的雲原生應用管理平臺之星背後的「道之所在」。

首先，什麼是 KubeVela？

一言以蔽之，KubeVela 是一個「可編程式」的雲原生應用管理與交付平臺。

但是，什麼是「可編程」呢？它跟 Kubernetes 又是什麼關係？它能幫助咱們解決什麼問題？

PaaS 系統的「能力困境」

PaaS 系統（好比 Cloud Foundry、Heroku 等）自誕生以來，就以其簡單、高效的應用部署體驗而被全部人津津樂道。然而，你們也知道，咱們今天的「雲原生」，倒是一個 Kubernetes 大行其道的世界，曾經的 PaaS（包括 Docker）到底遇到了什麼問題呢？

其實任何一個嘗試使用過 PaaS 的人，都會對這種系統的一個本質缺陷感觸頗深，那就是 PaaS 系統的「能力困境」。

圖 1 - PaaS系統的能力困境

如圖 1 所示，PaaS 系統在最開始使用的時候，每每體驗很是好，也總能恰如其分地解決問題。但隨着使用時間的推移，一個很是討厭的狀況就會出現：應用的訴求，開始超過 PaaS 系統可以提供的能力。而更可怕的是，一旦這個問題出現，用戶對 PaaS 系統的滿意度就會斷崖式下跌，這是由於不管是從新開發平臺增長功能，仍是修改應用去適配平臺，都是一項投入巨大但收益很低的事情。更況且全部人這時候都會開始對平臺失去信心：誰知道下一次系統或者應用大改，是否是很快又要發生了？

這個「命門」，能夠說是 PaaS 雖然具有云原生所需的一切要素、卻最終未能成爲主流的主要緣由。

而相比之下，Kubernetes 的特色就比較突出了。儘管 Kubernetes 被人詬病「複雜」，但隨着應用複雜度的提高，Kubernetes 的優勢就會慢慢體現出來，尤爲是當用戶的訴求開始須要你去經過 CRD Controller 支持的時候，你必定會慶幸：幸好當初選了 K8s。

這裏的緣由在於，Kubernetes 的本質實際上是一個強大和健壯的基礎設施能力接入平臺，也就是所謂的 The Platform for Platform。它的這套 API 和工做方式，自然不適合直接跟人去進行交互，但卻可以以很是一致的方式接入任何基礎設施能力，爲平臺工程師構建 PaaS 等上層系統提供「無限彈藥」。這種「BUG 級」的基礎設施能力供給方式，讓再精密的 PaaS 系統相比之下都像是一個礙手礙腳的「玩具」，這一點對於不少正掙扎於構建內部應用平臺的大型企業來講（它們纔是 PaaS 廠商真正想贏取的用戶）無異因而久旱逢甘霖。

雲原生 PaaS ：新瓶裝舊酒

前面提到的一點其實很重要：假如一個大型企業要決定採納一個 PaaS 系統仍是選擇 Kubernetes，平臺團隊每每纔是能決定拍板的那一方。但另外一方面，平臺團隊的意見雖然重要，並不意味着最終用戶的想法就能夠無論了。事實上，在任何一個組織中，直接創造價值的業務團隊才持有最高的話語權，只不過起做用的時間稍晚而已。

因此在絕大多數狀況下，任何一個平臺團隊拿到 Kubernetes 以後，並不會直接去讓業務去學習 Kubernetes，而是會基於 Kubernetes 構建一個「雲原生」 PaaS，用它去服務業務方。

咦，因而乎你們兜兜繞繞，又回到了故事的原點。惟一的變化是，我們今天這個 PaaS 是基於 K8s 實現的，確實輕鬆了很多。

但實際狀況呢？

這個基於 Kubernetes 構建 PaaS 的故事，看似美好，其實整個過程卻不免有些「心酸」。說的好聽點是開發 PaaS，其實 80% 的工做是在設計和開發 UI，剩下的工做則是安裝和運維 K8s 插件。而更使人遺憾的是，咱們這樣構建出來的 PaaS，其實跟之前的 PaaS 沒有本質不一樣，任什麼時候候用戶訴求改變，咱們都須要花大量時間從新設計、修改前端、排期上線。結果就是，K8s 突飛猛進的生態和無限可擴展的特性，都被「封印」在咱們親手構建的 PaaS 之下「不見天日」。終於有一天，業務方也實在忍不住要問了：大家平臺團隊上了 K8s，到底有啥價值？

上面這個「爲了解決 PaaS 的固有限制，結果又引入一個新的 PaaS 和限制」的困局，是現今不少公司在落地雲原生技術的過程當中遇到的一個核心問題。咱們彷佛再一次把用戶鎖定在一層固定的抽象和能力集當中。所謂雲原生化的好處，僅僅體如今我們本身開發這個平臺變得簡單了 —— 而對業務用戶來講，這彷佛沒什麼太大的意義。

更爲麻煩的是，雲原生和 K8s 的引入，也讓運維人員這個角色變得很是微妙。原本，他們所掌握的業務運維最佳實踐，是整個公司中最重要的經驗和資產。然而，在企業雲原生化以後，這個工做的內容都必須交給 K8s 去接管。因此，不少人都說，K8s 要讓「運維」失業了，這個說法雖然有點誇張，但確實反映出了這個趨勢帶來的焦慮。並且咱們不由也在從另外一個角度思考，雲原生化的背景下，應用運維的經驗和最佳實踐，又該怎麼落實？就拿一個簡單的工做負載舉例子，一個 K8s Deployment 對象，哪些字段暴露給用戶、哪些不能，雖然體如今 PaaS 的 UI 上，但確定不能是靠前端開發說了算的吧。

KubeVela：下一代可編程式應用平臺

阿里巴巴是整個業界在雲原生技術上的先行者之一。因此上述這個圍繞着應用平臺的雲原生技術難題，相對也比較早的暴露了出來。在 2019 年底，阿里基礎技術團隊與研發效能團隊合做針對這個問題進行了大量的探索與嘗試，最終提出了「可編程式」應用平臺的思想，並以 OAM 和 KubeVela 開源項目的方式同你們見面。這套體系，目前已經迅速成爲了阿里構建應用平臺的主流方式。

簡單地說，所謂「可編程」，指的是咱們在構建上層平臺的過程當中，不會直接在 Kubernetes 自己上疊加抽象（哪怕只是一個 UI），而是經過 CUE 模板語言這種代碼化（Code）的方式來抽象和管理、並透出基礎設施提供的能力。

舉個例子，好比阿里的某個 PaaS 要對用戶提供一個能力叫作 Web Service，這個能力是指任何須要從外部訪問的服務，都以 K8s Deployment + Service 的方式來部署，對用戶暴露鏡像、端口等配置項。

在傳統方法中，咱們可能會實現一個 CRD 叫作 WebService，而後在它的 Controller 裏來封裝 Deployment 和 Service。但這必然會帶來前面 PaaS 「能力困境」的問題：

1. 咱們應該給用戶暴露幾種 Service 類型？將來用戶想要其餘類型怎麼辦？
2. 用戶 A 和用戶 B 須要暴露的字段不統一該怎麼辦？好比咱們容許用戶 B 修改 Label，但 用戶 A  不能夠，那這個 PaaS 該怎麼設計？
3. ……

而在 KubeVela 中，像上面這樣面向用戶的功能，則能夠經過一段簡單的 CUE 模板來描述（這裏有完整的例子）。而當你編寫好這樣一個 CUE 文件以後，直接經過一句 kubectl apply，用戶就能夠當即使用到這個能力：

$ kubectl apply -f web-service.yaml

更重要的是，只要執行上面這條命令，KubeVela 就會自動根據 CUE 模板內容生成這個能力的幫助文檔和前端表單結構，因此用戶馬上就會在 PaaS 裏面看到這個 WebService 功能如何使用（好比有哪些參數、字段類型），而且直接使用它，以下 圖 2 所示：

圖 2 - KubeVela 自動生成表單示意圖

在 KubeVela 中，平臺的全部能力好比金絲雀發佈、Ingress，Autoscaler 等等，都是經過這種方式定義、維護和透出給用戶的。這種端到端打通用戶體驗層與 Kubernetes 能力層的設計，使得平臺團隊能夠以極低的成本快速實現 PaaS 以及任何上層平臺（好比 AI PaaS，大數據 PaaS），同時高效地響應用戶的持續演進訴求。

1. 不僅是 Kubernetes 原生，是 Platform-as-Code

尤其重要的是，在實現層，KubeVela 並非簡單的在客戶端去渲染 CUE 模板，而是使用 Kubernetes Controller 去渲染和維護生成的 API 對象。這裏的緣由有三點：

1. Kubernetes Controller 自然適合維護用戶層抽象到底層資源之間的映射，而且經過控制循環（Reconcile）機制永遠確保二者的一致性，而不會發生 IaC（Infrastructure-as-Code） 系統裏常見的 Configuration Drift（配置漂移）問題（即：底層資源跟用戶層的輸入發生不一致）。
2. 平臺團隊編寫的 CUE 模板 kubectl apply 到集羣以後，就變成了一個 Kubernetes 中的一個自定義資源（Custom Resource），它表明了一個抽象化、模塊化的平臺能力。這個能力能夠被全公司的平臺團隊複用，也能夠繼續修改演進，並且它是 Namespace 化的資源，因此平臺的不一樣租戶能夠分配同名但不同的模板，互不影響。這樣完全解決了不一樣租戶對同一個能力的使用訴求不同的問題。
3. 若是隨着時間推移，用戶對平臺功能的設計提出了新的要求，那麼平臺維護團隊只須要安裝一個新的模板，新的設計就會馬上生效，平臺自己不須要作任何修改，也不用重啓或者從新部署。並且新模板也會馬上被渲染成表單出如今用戶 UI 上。

因此說，KubeVela 的上述設計，從根本上解決了傳統 IaC 系統用戶體驗雖好，可是生產環境上「靠不住」的老大難問題，又在絕大多數狀況下讓整個平臺響應用戶需求的時間從原先的數週，下降到幾小時，徹底打通了雲原生技術與最終用戶體驗之間的壁壘。而它徹底基於 Kubernetes 原生方式實現，確保了整個平臺嚴格的健壯性，而且不管任何 CI/CD 以及 GitOps 工具，只要它支持 Kubernetes，就必定支持 KubeVela，沒有任何集成成本。

這套體系，被你們形象的稱爲：Platform-as-Code（平臺即代碼）。

2. 別急，KubeVela 固然支持 Helm

提到 KubeVela 以及 CUE 模板這些概念，不少小夥伴就開始問了：KubeVela 跟 Helm 又是什麼關係啊？

實際上，Helm 和 CUE 同樣，都是一種封裝和抽象 Kubernetes API 資源的工具，並且 Helm 使用的是 Go 模板語言，自然適配 KubeVela Platform-as-Code 的設計思路。

因此在 KubeVela v1.0 中，任何 Helm 包均可以做爲應用組件被部署起來，而且更重要的是，不管是 Helm 組件仍是 CUE 組件，KubeVela 裏的全部能力對它們都適用。這就使得經過 KubeVela 交付 Helm 包能夠給你帶來一些很是重要可是現有工具很難提供的能力。

舉個例子，Helm 包其實不少是來自第三方的，好比 Kafka Chart，可能就是 Kafka 背後的公司製做的。因此通常狀況下，你只能用，但不能改它裏面的模板，不然修改後的 Chart 你就得本身維護了。

而在 KubeVela 中，這個問題就很容易解決。具體來講，KubeVela 提供一個運維側的能力叫作 Patch，它容許你以聲明式的方式給待交付組件（好比 Helm 包）裏封裝的資源打 Patch，而不用去關心這個字段有沒有經過 Chart 模板透出來，並且 Patch 操做的時機，是在資源對象被 Helm 渲染出來以後、提交到 Kubernetes 集羣處理以前的這個時間，不會讓組件實例重啓。

再好比，經過 KubeVela 內置的灰度發佈系統（即：AppRollout 對象），你還能夠將 Helm 包做爲一個總體進行漸進式發佈且無需關心工做負載類型（即：哪怕 Chart 裏是 Operator，KubeVela 也能夠進行灰度發佈），而不是像 Flagger 等控制器那樣只能針對單一的 Deployment 工做負載進行發佈。此外，若是將 KubeVela 同 Argo Workflow 集成，你還能夠輕鬆的指定 Helm 包的發佈順序和拓撲等更復雜的行爲。

因此說，KubeVela v1.0 不只支持 Helm，它的目標是成爲交付、發佈和運維 Helm Chart 最強大的平臺。一些社區同窗已經在本文發佈以前就火燒眉毛的試用了這部分功能，你們能夠移步到這篇文章來閱讀。

3. 全自助式用戶體驗和雲原生時代的運維

得益於 Platform-as-Code 的設計，基於 KubeVela 的應用平臺自然對用戶是自助式的使用方式，如圖 3 所示。

圖 3 - KubeVela 自助式能力交付流程圖

具體來講，平臺團隊只須要極小的人力成本就能夠在系統中維護大量的、代碼化的「能力模板」。而做爲平臺的終端用戶，業務團隊只須要根據本身的應用部署需求在 PaaS UI 上選擇幾個能力模板，填入參數，就能夠自助式的完成一次交付，不管這個應用多麼複雜，業務用戶的學習成本都很是低，而且默認就會遵循模板中所定義的規範；而這個應用的部署和運維過程，則由 Kubernetes 以自動化的方式去管理，從而減輕了業務用戶大量的心智負擔。

而更爲重要的是，這種機制的存在，讓運維人員再次成爲了平臺團隊中的核心角色。具體的說，他們經過 CUE 或者 Helm 設計和編寫能力模板，而後把這些模版安裝到 KubeVela 系統中給業務團隊使用。你們試想一下，這個過程，其實就是運維人員把業務對平臺的訴求，結合整個平臺的最佳實踐，以代碼化的方式固化成可被複用和定製的能力模塊的過程。並且這個過程當中，運維並不須要去進行復雜的 K8s 定製和開發，只須要理解 k8s 的核心概念便可。另外一方面，這些代碼化的能力模塊，複用性極高，變動和上線很是容易，而且大多數狀況下不須要額外的研發成本，能夠說是最敏捷的「雲原生」運維實踐，可以真正讓業務感覺到雲原生「研發、交付、運維高效一體化」的核心價值。

4. 多環境多集羣、多版本應用交付

KubeVela v1.0 的另外一個重大更新，就是改進了系統的部署結構，提供了 Control Plane （控制平面）模式，從而具有了面向多環境、多集羣進行版本化應用交付的能力。因此如今，一個典型的生產環境 KubeVela 部署形態以下圖 4 所示：

圖 4 - KubeVela 控制平面部署形態示意圖

在這個場景下，KubeVela 支持爲多環境應用進行描述，支持爲應用配置 Placement 策略以及應用多版本同時部署在線、並經過 Istio 進行灰度的發佈模型。你們能夠經過這個文檔進行深刻了解。

在 v1.0 發佈以後，KubeVela 會圍繞上述架構進行持續的演進，其中的一個主要的工做項就是將 KubeVela Dashboard、CLI 和 Appfile 所有遷移和升級到同 KubeVela 控制平面經過 gRPC 進行交互，而不是像以前的版本那樣須要直接跟目標集羣打交道。這部分工做目前尚在進行中，歡迎對構建下一代「可編程式」開發者體驗有心得的同窗一塊兒來參與。與此同時，歐洲知名科技出版商 Springer Nature 也正在一塊兒參與這部分工做以便從 CloudFoundry 上平滑遷移到 KubeVela。

結語

若是咱們總結一下 KubeVela 今天的設計與能力，其實不難發現它是今天雲原生應用平臺發展的一條必然路徑：

1. 徹底基於 Kubernetes 構建，自然的被集成能力和普適性，自然透出 Kubernetes 及其生態的全部能力而不是疊加抽象；
2. 基於 X-as-Code 的平臺能力模塊化，配合 OAM 模型實現超低成本的能力封裝、抽象和組裝機制，快速敏捷的響應用戶需求，提供全自助、無鎖定的應用管理與交付體驗；
3. 基於 Kubernetes 控制器模式進行組件解封裝和應用部署，確保最終一致性、確保應用交付與運維流程的健壯性；
4. 內置以應用爲單位的發佈策略和麪向多環境、多集羣交付策略，極大地補充了社區目前以單一工做負載爲中心的發佈能力；
5. 不管應用部署多麼複雜，只須要 1-2 個 Kubernetes YAML 文件就能作完整的描述，自然適合而且大大簡化 GitOps 工做流，極大程度下降了終端用戶使用雲原生和 Kubernetes 的上手成本，而且不帶來任何能力或者抽象鎖定。

更重要的是，KubeVela 以 Platform-as-Code 的設計思想，給將來基於雲原生的應用平臺團隊提出了更加合理的組織方式：

1. 平臺 SRE 負責 Kubernetes 集羣和組件的健壯性；
2. 平臺研發工程師負責開發 CRD Controller，同 Kubernetes 內置能力一塊兒對應用層提供完整的應用管理、運維和基礎設施能力；
3. 業務運維結合業務訴求，負責將最佳實踐代碼化爲 CUE 或者 Helm 模板，將平臺的能力模塊化；
4. 業務用戶以徹底自助化的方式使用平臺的模塊化能力來進行應用管理與交付，心智負擔低，部署效率高。

而基於這套體系，KubeVela 應用平臺還能夠用來實現強大的「無差異」應用交付場景，達成徹底與環境無關的雲端應用交付體驗：

1. 組件提供方將應用交付所需的能力（工做負載、運維行爲、雲服務）定義爲 Helm 包或者 CUE 包，註冊到 KubeVela 系統當中；
2. 應用交付人員使用 KubeVela 組裝上述模塊化能力成爲一個徹底與基礎設施無關的應用部署描述，同時能夠藉助 KubeVela 的 Patch 等能力定製和覆蓋組件提供方的配置，或者定義複雜的部署拓撲；
3. 經過多環境、多集羣交付模型定義應用在不一樣環境中的部署形態和交付策略，配置不一樣版本應用實例的流量分配策略。

KubeVela v1.0 的發佈是咱們基於 OAM 模型以及雲原生應用交付使用場景最大化驗證的結果，它不只表明了穩定的API，還表明了成熟的使用範式。然而這不表明結束，而是一個全新的開始，它開啓了一個「可編程式」應用平臺的將來，這是一個可以充分釋放雲原生潛力、讓最終用戶和軟件交付方從第一天開始就充分享受雲原生技術魅力的有效路徑。咱們期待這個項目能達成它最樸素的願景：Make shipping applications more enjoyable!

瞭解更多

您能夠經過以下材料瞭解更多關於 KubeVela 以及 OAM 項目的細節：

1. 項目代碼庫：https://github.com/oam-dev/kubevela/，歡迎 Star/Watch/Fork！
2. 項目官方主頁與文檔：https://kubevela.io/，同時歡迎參加由「雲原生社區」組織的 KubeVela 文檔中文本地化翻譯工做！
3. 項目釘釘羣：23310022；Slack：CNCF #kubevela Channel。