*作者：曾慶國（悅達）*

> KubeVela 1.5 於近日正式釋出。在該版本中為社群帶來了更多的開箱即用的應用交付能力，包括新增系統可觀測；新增 Cloud Shell 終端，將 Vela CLI 搬到了瀏覽器；增強的金絲雀釋出；最佳化多環境應用交付工作流等。進一步提升和打磨了 KubeVela 作為應用交付平臺的高擴充套件性體驗。另外，社群也正式開始推動專案提級到 CNCF Incubation 階段，同時在多次社群會議中聽取了多個社群標杆使用者的實踐分享，這也證明了社群的良性發展。專案的成熟度，採納度皆取得了階段性成績。這非常感謝社群 200 多位開發者的貢獻。

KubeVela 近一年來發布了五個大版本，每一次迭代都是一個飛躍。1.1 的釋出帶來了銜接多叢集的能力，1.2/1.3 帶來了擴充套件體系和更友好的開發者體驗，1.4 引入了全鏈路安全機制。如今 1.5 的釋出讓我們離 KubeVela “讓應用交付和管理更輕鬆”的願景更近了一步。一路走來，我們始終遵循同樣的設計理念，在不失可擴充套件性的基礎上構建自動化處理底層差異化基礎設施複雜性的平臺，幫助應用開發者低成本從業務開發升級為雲原生研發。技術上則圍繞從程式碼到雲、從應用交付到管理的完整鏈路，基於開放應用模型（OAM）提煉銜接基礎設施的框架能力。如圖 1 所示，如今的 KubeVela 已經覆蓋了從應用定義、交付、運維、管理全鏈路的能力，而這一切能力都基於 OAM 的可擴充套件性（即 OAM Definition）外掛式地銜接生態專案實現。**本質上，每一個 Definition 都是將一項具體能力的使用經驗，轉化為一個可複用的最佳實踐模組，透過外掛打包實現企業共享或者社群共享。**

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c6f6561c53de43c5be51d6c72c44f569~tplv-k3u1fbpfcp-zoom-1.image "1.png")

圖 1 KubeVela 擴充套件性的核心結構

雲原生領域的原子能力百花齊放既是寶貴的財富，同時也提升了從業門檻。平臺構建者需要學習大量的開源專案，聚合多個領域的經驗。這往往會花費幾個月甚至更長的時間才能構建起企業雲原生支撐平臺。然而往往搭建的平臺將複雜性直接傳遞給了應用開發者，使其也得學習大量的額外知識。KubeVela 的設計理念和已有技術成果或許可以幫助到你快速進入雲原生世界。**KubeVela 在 1.5 版本以及之前數個版本中重點打磨的外掛整合規範和統一應用交付體驗，有效的解決了雲原生領域的原子能力離散問題。**

## 外掛規範升級，更靈活的定義方式

KubeVela 外掛機制從 1.2 版本釋出以來，廣受社群使用者喜愛，社群外掛倉庫中已存在近 50 款外掛。有近 50 位開發者參與了外掛的貢獻。

> 詳見：
>
> <https:>

從 1.5 版本開始，外掛開發者可以獲得更優的體驗。從外掛定義，分發到視覺化管理都全面提升。開發者除了可以使用 YAML 方式來定義外掛以外，如果希望更靈活的組合外掛包括的資源和更高階的引數化控制，開發者可以完全使用 CUE 來完成外掛的定義。目前外掛定義的規範包括以下幾部分：

-   template.cue 或者 template.yaml 結合 resources 目錄來定義外掛的執行時，例如擴充套件一個工作負載需要在背後執行的 Operator 等。這一部分不是必須的，例如一些輕量級外掛可以沒有背後的執行時或者複用其他執行時。透過 YAML 和 CUE 結合的配置方式可以覆蓋大多數需求場景。

-   definitions 目錄，存放 Definition 定義，這是外掛的核心部分，定義了該外掛擴充套件的能力如何被使用者使用。

-   schema 目錄，用來輔助 Definition，定義相關 Definition 在 UI 側的自定義渲染規則。

-   views 目錄，儲存 VelaQL 的語法定義，用來擴充套件 VelaQL 的查詢能力。

-   metadata.yaml 與 readme.md，外掛後設資料定義檔案，描述該外掛的基礎資訊和環境需求。

> 具體規範詳見文件：
> 
> <http:>

這裡以整合 Helm Chart 包交付能力為例。目前社群中像 FluxCD 或 ArgoCD 專案都提供了部署 Chart 包的原子能力，他們的實現方式不同，各有優勢。那麼對於 KubeVela 的使用者來說可以透過外掛引入這個兩個專案。如圖 2 所示我們需要為終端使用者定義一個標準的 API，根據企業實際情況向終端使用者暴露必要的引數。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9beb3e3308a74449950edcd1326989b9~tplv-k3u1fbpfcp-zoom-1.image "2.png")

圖 2 KubeVela 擴充套件 Helm Chart 包的流程

如圖 3 所示，根據標準的 API，前端 UI 即可自動生成對應的互動頁面幫助終端使用者便捷簡單的完成 Helm Chart 包部署。平臺側根據使用者的輸入引數和外掛定義自動生成底層能力的驅動配置，並智慧獲取相關狀態反饋給使用者。這些都是基於外掛規範來描述，例如整合 FluxCD，該專案包括了多個控制器提供不同的原子能力，首先我們透過 template.cue 來定義FluxCD 的部署方式，基於不同的引數輸入選擇部署不同的元件。再透過 definitions 和 schema 目錄來定義使用者體驗。

> 詳細參考：
> 
> <https:>

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/82ce3b9ce9974108baaa9d8a8bce3f0e~tplv-k3u1fbpfcp-zoom-1.image "3.png")

圖 3 KubeVela 交付 Helm Chart 包的互動

## 基於外掛擴充套件的功能解讀

### Telemetry 整合 Prometheus + Grafana + Exporters 支撐系統可觀測

應用可觀測體系與應用釋出關係緊密，一個好的應用可觀測體系可以使得應用可靠性管理變得容易。**KubeVela 社群將應用可觀測列入核心 Feature**。社群在 1.5 版本中首先選取了 KubeVela 系統本身的可觀測作為案例進行體系能力的研發。目前實現了以下幾個要點：

1. 多叢集可觀測基礎設施透過外掛一鍵安裝，我們首先圍繞著 Prometheus + Grafana + Exporters 的方案形成了可觀測外掛集。面向不同的基礎環境便捷安裝基礎能力。

2. 支援一鍵開啟多叢集 Metrics 資料匯聚，採用 Thanos Query 方案實現多叢集指標聚合查詢和視覺化。類似的方案將逐步覆蓋 Logger 和 Tracing 維度。

3. Grafana IaC 化。將 Grafana 的資料來源，大盤等配置透過應用模型進行描述，創新性得使用擴充套件 API 輕量的將 Grafana API  變成了 KubeVela 可以操作的執行時。

4. Grafana 大盤自動生成，使用者可以透過啟用 Grafana 外掛即可自動生成 KubeVela 的系統可觀測大盤。

如圖 4 所示為 KubeVela 系統執行指標的大盤。該大盤即透過 IaC 體系自動生成，使用者只需要啟用對應的外掛即可。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cb7be46f6aef495eadfecc1269c0ce42~tplv-k3u1fbpfcp-zoom-1.image "4.png")

圖 4 KubeVela 系統可觀測大盤

如圖 5 所示為接入 KubeVela 的 Kubernetes API Sserver 服務的監控大盤。透過外掛向所有子叢集下發 Exporter，將資料向各叢集的 Prometheus 服務暴露，然後匯聚到管控叢集進行集中視覺化。花一份時間完成 N 個叢集的監控資料和大盤接入。

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fcc09866e6b94d918766a609e945a11c~tplv-k3u1fbpfcp-zoom-1.image "5.png")

圖 5 KubeVela 多叢集 API 觀測大盤

在接下來的版本中，社群將逐步將應用可觀測的統一描述和交付融入應用交付過程。覆蓋 Metric，Logger 和 Tracing 的資料獲取，中間處理和傳輸，儲存和分析，報警和視覺化以及應用於應用釋出流水線全鏈路。

> 參考文件：
> 
> <http:>

### 整合 Cloud Shell 實現 CLI & UI 協同應用交付

透過 CLI 黑屏的方式操控應用交付的優勢在於便捷、批次化和易複製，開發者尤其喜歡。透過 UI 的方式交付應用互動更加優雅，流程性的操作有利於降低學習成本，實現更嚴格的企業安全控制。視覺化程度高可以更好的掌握應用，隨時隨地進行相關操作。過去的版本中 KubeVela 在 CLI 和 UI 兩個維度上存在差異化大，資料不互通的問題。如果兩種終端方式可以有效結合可以使應用交付和管理更加順暢。在 1.5 版本中，KubeVela 引入了 CloudShell 外掛，該外掛為 UI 使用者提供了 Web Shell 終端，統一的入口很好的解決了 CLI 和 UI 割裂的問題，同時帶來了更多的能力。針對該流程主要變更如下：

1. **開箱即用的工具集**；不同於其他平臺主要提供進入應用執行空間的 Web Shell 能力。CloudShell 為每一個使用者生成一個終端環境，包括了 Vela，Kubectl 等 CLI 工具，在同一個環境中即可管理多個應用。

2. **自動完成授權**；使用者無需關心如何分配 KubeConfig，系統自動根據 UI 使用者所擁有的許可權完成黑屏環境授權，實現了基本的白屏和黑屏的許可權一致化。

3. **環境自動回收**；每一個使用者的終端環境最長存活時間為 1 小時，過期後自動回收防止過多的資源消耗。

4. **增強 Vela CLI 能力**；重新實現了 log，status，exec，port-forward 等用於 Debug 應用的操作命令，針對應用下差異化工作負載實現了無縫相容，讓使用者無感知的可以完成相關操作。無論是基礎的 Deployment 資源還是 Helm 打包的負載資源集，亦或者是自定義的 Operator 驅動的工作負載。Vela 都可以自動發現命令相關的底層操作物件。

5. **資料自動同步**；CLI 可以建立更新應用，變更會同步的 UI 上進行視覺化，直到使用者選擇透過 UI 來接管應用和後續的釋出。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5e92f6ceb2a34debb77bf6f29154f164~tplv-k3u1fbpfcp-zoom-1.image "6.png")

圖 6 KubeVela ClouShell 操作終端

### 整合 OpenKruise Rollout 提供金絲雀釋出能力

KubeVela 社群在早期孵化了 Rollout 專案，與 Argo Rollout 的實現模式類似，以一種新的工作負載的形式工作，主要實現了分批發布的能力。隨著社群發展，KubeVela 更聚焦於應用全域性管控層和外掛化擴充套件能力。因此工作負載層面的 Rollout 實現轉移到了 OpenKruise 社群，在雙方的共同努力下實現了可以針對原生 Deployment，StatefulSet 以及 OpenKruise 擴充套件的工作負載 CloneSet 多種工作負載的金絲雀釋出能力。同時與 KubeVela 中的 Helm 交付模式共存時，可以實現針對 Helm Chart 包應用無需做任何變更即可進行金絲雀釋出，這在業內具有創新性，對於使用者非常便捷。Kruise Rollout 作為一個外掛整合到了 KubeVela 生態。KubeVela 使用者僅需要啟用 外掛，即可在應用元件中配置 Rollout Trait。同時可以與元件的 Gateway，HTTPRoute 等閘道器規則 Trait 實現協同。整理下來，該實現有以下幾項優勢：

1. **無侵入，無繫結**；透過旁路的方式引入 Rollout 能力，使用者無需對已有應用配置進行其他變更，引入成本低且隨時可以移除；

2. **易於使用**；僅需要簡單的配置流量切換規則，結合 KubeVela 的 UI 視覺化，可以有效觀測 Rollout 過程中的副本數量變化以及引入的額外資源關係；

3. **相容性好**；不管使用者使用了什麼工作負載進行包裝（Helm 或 自定義 Operator），Rollout 可以發現現底層的負載資源後以旁路形式工作。

> 參考文件：
> 
> <http:>

### VelaUX 增加多環境差異化視覺化配置

VelaUX 至推出開始就具有了多環境部署能力，直到 1.5 版本，支援了使用者視覺化編輯多環境的差異化，從而真正匹配了使用者多環境應用釋出的需要。使用者可以新增 Override Policy 配置，可以做到環境，叢集或 Namespace 多個維度的差異化。應用的基準配置和差異化的配置統一管理。

如圖 7 所示，應用策略 Policy 已內建了多種可選項，包括差異化配置；應用多叢集策略；應用維持策略和 GC 策略等等。透過 UI 的引導可以方便使用者根據需要配置對應的策略。

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/389a7dfcc1204c8881c839a72a450c4e~tplv-k3u1fbpfcp-zoom-1.image "7.png")

圖 7 KubeVela Policy 新增/編輯視窗

在1.5 版本中，針對不同的環境部署前後新增了以下便捷功能：

-   **DryRun(試執行)能力**；使用者可以在部署一個環境之前選擇先進行 DryRun，透過 UI 反饋的結果評估應用配置是否符合預期，防止部署後才發現錯誤配置影響線上服務穩定性。

-   **環境差異洞察**；切換到不同環境檢視時自動進行本地配置與部署配置的比對，如果出現差異將提示使用者並展示出差異的配置項。防止出現配置漂移或計劃進行上線的配置忘記上線等。

-   **版本詳情查詢和差異比對**；透過版本管理頁面，可以檢視每一個版本的應用配置渲染結果，也可以將版本配置與當前執行配置或最新的本地配置進行比對。方便使用者追蹤配置變更過程。

> 參考文件：
> 
> <http:>

## 應用引擎能力提升

除了上述的外掛能力提升以外，在應用引擎方面也進行了大量的更新。其中效能最佳化提升明顯，工作流執行時 CPU 消耗降低 75%。並行執行的數量顯著提升。下面列舉了以下重要的變更：

1. Workflow 新增超時控制，在 Workflow 步驟中配置超時時間，當執行時間大於超時時間後 Workflow 將結束變為終止狀態。

2. Workflow 新增條件判斷，在 Workflow 步驟中配置 If 欄位，支援從 status 或 input 中讀取資料進行判斷以確定當前步驟是否需要執行。同時支援 If Always 機制，支援有些步驟需要在任何情況下執行的場景。

3. Workflow 支援顯示切換模式，支援 DAG 或者預設的 StepByStep。

4. 新增共享資源策略，不同應用可以描述相同的資源，例如名稱空間或者 ConfigMap，設定為共享資源即不會衝突。

5. 最佳化應用資源樹構建演算法，提升了在不同場景下的查詢效率，更易於擴充套件自定義規則，同時增加了部分預設規則。

> 更多變更內容請參考：
> 
> <https:>

## 結語

整體來說，隨著 1.5 版本的釋出，KubeVela 在產品能力，社群生態，標杆使用者等多個維度都取得了顯著進步。使用者案例囊括了金融，智慧製造，網際網路等多個行業。我們也期待更多的使用者可以分享你的實踐經驗，幫助 KubeVela 社群找到更準確的前進道路。在 1.6 的版本計劃中，將帶來更完善的應用可觀測能力；獨立於應用的工作流能力，銜接多個應用的持續釋出控制和與可觀測系統的協同。有相關需求和想法的開發者可以隨時參與到社群討論之中。

您可以透過如下材料瞭解更多關於 KubeVela 以及 OAM 專案的細節：

-   專案程式碼庫：
    github.com/oam-dev/kubevela
    歡迎 Star/Watch/Fork！

-   專案官方主頁與文件：kubevela.io
    從 1.1 版本開始，已提供中文、英文文件，更多語言文件歡迎開發者進行翻譯。

-   專案釘釘群：23310022；Slack：CNCF #kubevela Channel

-   加入微信群：請先新增以下 maintainer 微訊號，表明進入KubeVela使用者群：

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/39e23d5153c243aab06be5a095babc05~tplv-k3u1fbpfcp-zoom-1.image "8.png")

戳[此處](https://kubevela.io/)：檢視 KubeVela 專案官網！</https:></http:></http:></http:></https:></http:></https:>

KubeVela 1.5：靈活框選 CNCF 原子能力打造獨特的企業應用釋出平臺

相關文章