KubeVela v1.2 釋出：你要的圖形化操作控制檯 VelaUX 終於來了！

作者：KubeVela 社群

隨著雲原生的不斷髮展和成熟，越來越多的基礎設施能力逐漸標準化成為 PaaS 平臺或者 SaaS 化產品。一個產品的誕生不再像過去那樣需要建立一個團隊，從開發、測試一直到運維、基礎設施全部分多種角色系統完成。如今，敏捷組織文化和雲原生技術驅動，使得這些職責更多的是「左移」到了開發者身上，測試左移、監控左移、安全左移，以及 DevOps 等一系列理念都是在強調，通過開源專案或者雲的產品和服務將測試、監控、安全、運維等一系列事務提前到開發階段完成。這看似美好的願景卻給開發者帶來了巨大的挑戰，開發者對底層五花八門的產品和複雜 API 缺乏掌控力，他們不僅僅是在做選擇，更多的需要去理解和協調底層複雜異構的基礎設施能力，以便滿足上層業務的快速發展和迭代需求。

這種複雜性和不確定性無疑大大降低了開發者的體驗，降低了業務系統的交付效率，增加了運維風險。開發者體驗的核心是「簡單」和「高效率」，不管是開發者還是企業都需要更好用的開發者工具或者平臺來達成。在現代雲原生技術之上打造一款幫助開發者從開發、交付以及後續持續運維的一體化平臺，一直是 KubeVela 演進的核心目標。如圖 1 所示，在 v1.2 版本中，我們圍繞開發者體驗新增了 UI 控制檯元件（VelaUX），簡化了編排 YAML 的複雜性，完善了外掛體系建設，豐富了雲資源的擴充套件能力，增加了大量 CI/CD 等生態對接的能力，進一步完善了開發者端到端的使用體驗。

圖 1：KubeVela 架構設計

發展歷程回顧

讓我們再來簡單回顧一下 OAM 和 KubeVela 的發展階段和歷程：

OAM（Open Application Model）誕生和成長

在複雜的世界中要創造簡單，首先我們需要解決的問題就是抽象和標準化。阿里雲和微軟聯合推出 OAM 模型，創新性地提出「關注點分離」的理念，開發者關注業務本身、運維關注模組化能力。OAM 模型圍繞「一切皆服務，全面模組化」的思想，為各大廠商和雲原生的平臺構建者們實現自己的應用管理平臺提供了簡單易用與高度可延伸相結合的標準實踐方式。該模型提出後的短短一年內便得到了包括 AWS、Oracle、騰訊、華為在內的國內外各大廠商響應，被國家信通院立項作為行業標準。因為大家有共同的目標，降低雲原生的使用門檻，讓應用交付和管理更簡單。

KubeVela 開源專案 v1.0 釋出，為社群帶來了 OAM 的標準實現

有了 OAM 模型作為實踐指導，社群高階玩家也開始創造自己的工具來實踐，包括阿里、微軟、Oracle、Upbond、騰訊在內的一系列公司都基於 OAM 的指導構建了自己的業務平臺。但對於更廣大的開發者和中小型企業群體來說，他們卻無法直接享受模型帶來的紅利，於是，KubeVela 作為 OAM 社群的官方實現引擎誕生了。它從一開始就由 7 家來自不同組織的 OAM 社群成員從零到一構建。KubeVela 的實現吸收了多家公司針對 OAM 的實踐經驗，同時結合 Kubernetes 社群生態優勢，實現了自動化、可收斂、冪等且穩定的應用釋出控制器，圍繞 IaC（基礎設施即設定）構造了使用者友好的抽象層，幫助開發者實現了開箱基於的 OAM 實現引擎。

KubeVela v1.1 釋出，實現應用交付工作流，原生支援混合環境多叢集應用交付

隨著企業上雲程序的推進，混合雲、分散式雲等多元化基礎設施逐漸成為常態。KubeVela 作為現代應用管理系統也順應潮流，整體架構升級為面向混合環境做應用交付和管理的控制平面，將所有的功能天然構築在多叢集技術之上。我們相信，出於高可用、成本效能、資料安全等多方面因素，未來大多數企業應用的形態都將是異構多元的。KubeVela v1.1 版本的釋出，同時也實現了高度可延伸的應用釋出工作流，它天然以混合環境架構呈現，創新性的實現了交付工作流與應用抽象相結合的工作模式，實現了面向終態的應用交付工作流，大大簡化了流程編排的複雜性。

時間來到 2022 年，KubeVela 也正式進入了第四個階段，在原先核心控制器 API 基本穩定的基礎上，我們以外掛的形式增加了一系列開箱即用的功能。讓開發者可以通過 UI 控制檯的方式，連線 CI/CD 完整流程，端到端釋出多叢集應用，進一步提升開發者體驗。

v1.2 版本的核心能力

圖形化操作控制檯（VelaUX）

提供好用的圖形化操作介面是降低開發者使用門檻的首選途徑，從 KubeVela 誕生以來，社群對 UI 控制檯的呼聲一直很高。從 v1.2 版本開始，它正式到來了。打造 UI 控制檯的目的是幫助開發者以更標準化的方式組裝和管理異構業務應用，幫助他們分析和更快的發現業務故障和阻礙。

VelaUX [1] 是 KubeVela 的前端專案，設計實現時它充分考慮了 KubeVela 的可延伸性這一核心要點。引入了低程式碼平臺的理念來打造前端，我們的目標是打造一個可以通過拖拉拽方式就能做到自定義應用交付輸入引數，並且實現執行資料可觀測的平臺。為此我們設計了前端描述規範（UISchema [2] ），配合 KubeVela 的模組化定義（X-Definition [3] ），通過設定就可以渲染出豐富的前端互動元素。同時為了讓前端的資料查詢也設定化，我們設計了多維資料自定義查詢語言（VelaQL [4] ），這樣的設計形成了 KubeVela 交付和管理異構應用的基礎。

目前通過 VelaUX ，使用者可以管理擴充套件，連線 Kubernetes 叢集，分配交付目標，規劃環境和交付各型別應用，並觀測應用執行狀態，實現應用交付的完整閉環。

圖 2：VelaUX 預覽

如圖 2 所示，VelaUX 中出現了一些新名詞，請參考核心概念 [5] 檔案進行學習和了解。

多環境統一化管理

KubeVela 將 N 個Kubernetes 叢集，N 個雲廠商服務或其他私有云服務統一為大的基礎設施資源池。在此基礎上，我們的開發者可以按照業務需求、流程需求、團隊需求等多種業務維度劃分環境。在大資源池的基礎上形成環境空間。同一個應用可釋出到不同的環境，環境之間從管理到執行態完全隔離。

圖 3：多環境/多叢集應用管理頁面

如圖 3 所示，應用可被髮布到生產、測試、預設三個環境中，每一個環境可以包括多個交付目標，每一個交付目標背後可以是獨立的 Kubernetes 叢集。

異構應用標準化交付

在雲原生體系中，我們交付應用的形式選擇非常多。基於 Kubernetes 基礎設施，我們既可以通過成熟的 Helm Chart 包交付中介軟體和第三方開源應用，也可以通過映象交付企業業務應用，還可以通過 OpenYurt 交付管理邊緣應用。基於雲服務商的開放能力，我們可以交付資料庫、訊息、快取等中介軟體，也有紀錄檔、應用監控等運維能力。

對於這麼多的可選項，KubeVela 採用標準的 OAM 規範實現對異構應用的統一交付和管理。KubeVela 實現了高度可延伸的交付系統，通過內建、社群共用等形態幫助使用者擴充套件平臺，以一致化的交付和管理體驗處理異構的應用。在 KubeVela 之上，開發者看到的都是模組化、一切皆服務的管理形態。

圖 4：雲服務應用管理頁面

如圖 4 所示，我們可以看到，相同的應用管理頁面，使用者可以非常便捷得獲取到雲服務應用。開發者可以通過閱讀下面幾篇檔案檢視異構應用的交付過程：

交付 Docker 映象 [6]
交付 Helm Chart 包 [7]
交付 Kubernetes 資源 [8]
交付雲服務 [9]

擴充套件體系（Addon）

KubeVela 從一開始就是設計為一款微核心高可延伸的系統，上文我們說到異構應用，KubeVela 可以通過擴充套件體系，以標準化的形態，擴充無限的應用交付能力。既匹配企業差異性訴求，也不帶來過多的認知負擔。KubeVela 中可延伸的點包括了元件型別、運維能力、工作流型別、應用交付策略等。在當前版本中，我們釋出了 Addon 擴充套件體系。Addon 是組織各種擴充套件能力的承載體，它便於分發和管理。

圖 5：KubeVela 外掛管理頁面

目前在官方倉庫中已經存在如圖 5 所示的可用 Addon。同時在實驗性倉庫中我們正在聯合社群使用者積極創造更多的擴充套件能力。當然，這裡需要每一個社群開發者的積极參與。

截止到現在，KubeVela 已經成長為一款可直接服務於廣大開發者的應用交付平臺，那麼企業哪些場景可以直接利用 KubeVela 呢？我們整理了以下幾個常見場景：

企業開發場景解決方案

多叢集應用 DevOps

在過往社群的交流中，我們發現企業主流的研發體系都類似如圖 6 所示的結構，他們使用雲服務廠商提供的計算資源作為生產、演示環境。使用自己購買或歷史遺留的伺服器搭建開發、測試環境。如果業務有多區域或災備需求，生產環境可能需要部署到多個區域或多雲。

圖 6：多叢集應用實踐架構

對於基礎的 DevOps 流程，包括了程式碼託管和 CI/CD 的環節。KubeVela 目前為你提供 CD 環節的支援。對於企業實踐的步驟如下：

根據實際情況準備本地或雲服務資源。至少單項打通本地和雲資源的網路，便於資源集中管理。
將 KubeVela 系統搭建在生產環境中，保障持續的可用性。
通過 KubeVela 部署 Gitlab、Jenkins、Sonar 等 DevOps 工具，並打通工具鏈。通常情況下，程式碼託管和開發工具的可用性至關重要，我們需要將其部署在生產環境中（如果你本地機房具備生產可用性，且希望程式碼資料在本地環境流轉，可部署在本地機房）。
通過 KubeVela 規劃本地開發環境，部署本地測試用中介軟體，規劃生產環境和部署雲服務中介軟體。
通過 Jenkins 搭建業務程式碼 CI 流水線，產出 Docker 映象交由 KubeVela 進行多環境部署，形成完整應用交付工作流。

結合 KubeVela 的多叢集應用 DevOps 方案有如下優勢：

（1）開發者無需掌握過多的 Kubernetes 生態知識，可實現異構應用雲原生部署。

（2）多叢集，多環境統一管理，原生可部署跨叢集應用。

（3）統一的應用管理模式，無論是業務應用還是開發工具鏈。

（4）靈活的工作流，幫助企業打通各種開發規範流程。

混合環境一體化管理

不同的企業往往都存在不一樣的基礎設施和業務訴求。在基礎設施側：企業可能搭建了私有云，可能購買了公有云，可能還有邊緣計算資源。在業務側：不同的業務規模不同，資源需求不同，可能有多雲多活應用，也有企業遺留系統。在研發側：業務研發往往需要開發、測試、預發和生產環境。在管理側：不同的業務團隊需要相互隔離，又可能需要業務互通。

隨著時間的累積，企業由於職責邊界和不同分工的影響，會逐漸形成不同業務團隊相互獨立甚至割裂的狀態，這種割裂包括了：開發工具割裂，技術架構割裂，業務管理形態割裂。KubeVela 秉持著「尊重現實，積極創新」的原則，帶來的方案是追求統一的過程中用高擴充套件的能力去相容差異性。

面對基礎設施差異，我們支援以 Kubernetes API、雲服務 API 或其他自定義 API 的形態，去對基礎設施進行充分的模型化。最終通過統一的 OAM 模型向上暴露一致的概念。
面對業務架構差異，應用模型是開放的，對架構無要求的。KubeVela 做的是連線和賦能，連線已有系統，通過擴充套件機制加持新的生態技術。
面對開發工具鏈的差異，企業中可能已經存在不同的開發工具鏈，產出不同的業務製品。KubeVela 通過擴充套件和標準模型去支援各類製品，實現其標準化交付。當然，它的標準逐步衍生到前置環節，幫助企業逐步實現工具鏈一致化。因此，你不用擔心你是用的 Gitlab 還是 Jenkins，它都能對接。
面對運維能力差異，企業中不同團隊的運維能力、工具方案可以在 KubeVela 的規範下逐步積累，能力互通。更多運維能力也同樣在社群的維度進行共用和複用。

因此，使用 KubeVela 來作為企業打通業務，進行統一能力建設的基礎平臺，它是可落地、有未來的方案。

自定義企業釋出平臺

從 Heroku 、Cloud Foundry 時代開始，市場上一直在產生不同的 PaaS 平臺，我們都知道固定模式的釋出平臺往往不適合所有的企業。舉個例子，某些規範化程度較高的企業，他們基於業務的特性，釋出應用時僅需更新映象名稱，然而使用通用 PaaS 就不得不去理解大量的概念和引數。再比如某個企業生產的是 AI 應用，對於 AI 應用的釋出與普通應用有比較大的區別，這時就需要客製化 AI 場景的 PaaS，企業不得不付更多的費用和學習更多的概念。

通用產品不符合企業需求時，自研是真實存在的訴求。但是對於從零開始自研平臺，必然又需要投入大量的人力物力，甚至超過了企業核心業務的投入，這顯得得不償失。KubeVela 也考慮到了具備自研能力企業的獨特訴求，他們可以基於 KubeVela 微核心、高可延伸的設計，針對自己的業務場景和領域知識，打造屬於自己的、更為簡單易用的業務平臺。

對於需要自研發布平臺的企業來說，KubeVela 的微核心是一個 PaaS 平臺研發框架。一方面，企業可以根據自己的需求自研或者安裝社群的各種功能外掛；另一方面，企業也可以基於 OAM 模型修改模組化設定，新增或裁剪使用者使用的引數。這種模組化的設計可以大大降低企業的投入成本，同時可以跟上社群的發展潮流，隨時將社群更多的先進技術轉化為自身的生產力。

參與社群

做了這麼多的介紹，你是否對 KubeVela 的發展有了一些新的認識，沒有哪個產品是絕對的銀彈，也沒有一個方案可以解決所有的問題。但是我們的理想是可以創造一個標準化模式，讓更多的企業和開發者使用者參與到這場為了「簡單」和「高效」的開發者體驗戰役中來。KubeVela 還很年輕，我們希望你可以參與進來共同打造。這裡非常感謝在過去參與 KubeVela 貢獻的 100 多位開發者 [10] ，正是因為你們的攜手努力，才讓我們的社群生態變得更加繁榮。

共建 OAM 應用規範

對於 OAM 應用規範，模型的更新和升級基於 KubeVela 實踐驅動，但是它並不繫結 KubeVela 實現。它是 KubeVela 在雲原生應用交付和管理層面實踐經驗的總結和抽象，是創造規範化應用管理體系的最佳實踐和核心理念。我們非常歡迎雲廠商、平臺廠商、終端使用者可以參與進來，同時我們也欣喜的看到國內包括騰訊在內的多家廠商對 OAM 應用規範的關注和支援。任何人、組織都可以發表你的想法、建議和思考。

參與 OAM 模型討論：

共建 Addon 擴充套件生態

如上文介紹的一樣，我們已經開啟了 Addon 的擴充套件體系，非常歡迎社群的創造者、開發者可以來貢獻更多的擴充套件能力。

如何擴充套件和貢獻 Addon 參考檔案：

貢獻雲服務能力

KubeVela 通過整合 Terraform Module 來擴充套件雲服務整合能力，我們已經支援了常用的雲資源 [11] ，歡迎社群朋友參考並貢獻更多的雲服務廠商和產品。

如何擴充套件和貢獻雲資源參考檔案：

反饋你的需求或痛點

或許你是普通開發者，也或許你是雲原生領域的從業者，如果你認可我們的方向，認可我們正在做的事情，我們非常歡迎你可以參與到 KubeVela 社群討論中來。

社群討論：

KubeVela 網站加速存取

KubeVela 的官方檔案託管在GitHub （）上，如果你發現有任何錯漏或者想要參與翻譯，歡迎直接到專案中貢獻。同時為了國內使用者可以加速存取，我們增加了這個域名，可以方便國內使用者更快的存取，內容與的域名完全一致、實時同步。

KubeVela 是 CNCF 沙箱專案，瞭解更多資訊，請點選查閱官方檔案。