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。