KubeVela 1.4：讓應用交付更安全、上手更簡單、過程更透明_阿里云云原生

作者：孫健波，曾慶國

KubeVela 是一個現代化的軟體交付控制平面，目標是讓應用的部署和運維在如今的混合多雲環境下更簡單、敏捷、可靠。自 1.1 版本釋出以來，KubeVela 架構上天然打通了企業面向混合多雲環境的交付難題，且圍繞 OAM 模型提供了充分的可擴充套件性，贏得了大量企業開發者的喜愛，這也使得 KubeVela 的迭代速度不斷加快。

1.2 版本我們釋出了開箱即用的視覺化控制檯，終端使用者可以通過介面釋出和管理多樣化的工作負載；1.3 版本的釋出則完善了以 OAM 模型為核心的擴充套件體系，提供了豐富的外掛功能，並給使用者提供了包括 LDAP 許可權認證在內的大量企業級功能，同時為企業整合提供了巨大的便利。至今為止，你已經可以在 KubeVela 社群的外掛中心裡獲得 30 多種外掛，其中不僅包含了 argocd、istio、traefik 這樣的 CNCF 知名專案，更有 flink、mysql 等資料庫中介軟體，以及上百種不同雲廠商資源可供直接使用。

在這次釋出的 1.4 版本中，我們圍繞讓應用交付更安全、上手更簡單、過程更透明三個核心，加入了包括多叢集許可權認證和授權、複雜資源拓撲展示、一鍵安裝控制平面等核心功能，全面加固了多租戶場景下的交付安全性，提升了應用開發和交付的一致性體驗，也讓應用交付過程更加透明化。

核心功能解讀

開箱即用的認證和授權，對接 Kubernetes RBAC，天然支援多叢集

在全面解決了架構升級、擴充套件性等挑戰之後，我們觀察到應用交付的安全性是如今整個業界亟需解決的難題。從接觸到的使用者案例中，我們發現許多安全隱患：

大量使用者在使用傳統 CI/CD 的過程中，會直接將生產叢集的 admin 許可權嵌入到 CI 的環境變數裡，只對最基本的交付到哪些叢集有一定的許可權分離。而 CI 體系通常也會被密集的用於開發和測試，很容易引入不受控制的風險。中心化的管理加上粗粒度的許可權控制，一旦 CI 體系被黑客攻擊、或者出現一些人為誤操作，很容易產生巨大的破壞性，後果不堪設想。
大量 CRD 控制器依賴 admin 許可權對叢集資源進行操作，且沒有對 API 的訪問進行約束。雖然 Kubernetes 本身具備豐富的 RBAC 控制能力，但是由於學習許可權管理門檻較高、且與具體功能實現無關，大多數使用者並不真正關心其中細節，通常只是選擇預設的配置便投入生產使用。靈活性較高的控制器（如能夠分發 Helm Chart），很容易成為黑客攻擊的靶子，比如在 helm 中嵌入一個 YAML 指令碼竊取其他名稱空間中的祕鑰。

KubeVela 1.4 中加入了認證和授權能力，且天然支援多叢集混合環境，對於每一個 KubeVela 的平臺管理員而言，他們不僅可以細粒度的定製任意的 API 許可權組合、對接 Kubernetes RBAC 體系，將這些許可權模組授權給開發者使用者，嚴格限制其許可權；還可以簡便的使用 KubeVela 平臺預置的許可權模組，如直接授予使用者某個叢集的特定名稱空間許可權，授予某個使用者“只讀”許可權等，極大的簡化了使用者的學習成本和心智負擔，全面加固了應用交付的安全性。對於使用 UI 的使用者，系統針對專案可用的資源範圍和型別自動完成底層授權並嚴格校驗，從而使得業務層 RBAC 許可權與底層 Kubernetes RBAC 體系打通並協同工作，做到從外到內的安全，不在任何環節擴大許可權。

具體而言，平臺管理員對一個使用者授權完成以後，使用者的請求會經過如圖所示的幾個階段。

KubeVela 的 webhook 首先會攔截使用者的請求，將使用者的許可權資訊（ServiceAccount）打到 Application 物件上。
KubeVela Controller 在執行 Application 的部署計劃時，會基於 Kubernetes 的角色扮演機制(impersonate) 轉換為對應使用者的許可權去執行。
KubeVela 多叢集模組（ClusterGateway）會傳遞對應的許可權到子叢集，子叢集的 Kubernetes APIServer 會根據子叢集的許可權做認證。子叢集的許可權則是由 KubeVela 的授權流程建立的。

簡而言之，KubeVela 的多叢集認證和授權功能保證了每一個終端使用者的許可權都被嚴格約束，不會被交付系統放大，同時 KubeVela 自身的許可權也收斂至最小，而且整個使用體驗很簡單。

如果你想了解更多功能及其背後的實現原理，歡迎閱讀官方的許可權認證和授權文件深入瞭解背後的執行機制。

參考案例

分散式雲容器平臺ACK One（Alibaba Cloud Distributed Cloud Container Platform）是阿里雲面向混合雲、多叢集、分散式計算、容災等場景推出的企業級雲原生平臺。KubeVela 多叢集控制面是 ACK One 的核心實現，在 ACK One 中基於該 Feature 實現了基於角色扮演的應用多叢集分發。

參考文件：http://help.aliyun.com/document_detail/419336.html

輕量便捷的應用開發控制平面，本地開發和生產部署一致體驗

隨著生態的不斷繁榮，我們也看到越來越多的開發者開始關注雲原生技術，但經常苦於沒有好的入門方式，主要原因有如下兩點：

應用的開發環境與生產環境不一致，體驗差別非常大。雲原生是最近五六年逐漸出現的技術趨勢，雖然它發展迅猛，但是絕大多數公司依舊習慣了內部自研一套平臺遮蔽底層技術。這就導致普通的業務開發者即使學習了雲原生技術，也很難在實際工作中實踐，最好的情況可能也要重新對接一遍 API 和配置，更談不上一致體驗了。
以 Kubernetes 為核心的雲原生技術部署和使用很複雜，如果只是為了入門學習去購買雲廠商的託管服務成本又很高。即使花了很多精力學會了部署出一套可用的本地環境，也很難把眾多雲原生技術串聯起來走完一整個 CI/CD 的流程，這裡面涉及了大量運維領域的知識，而普通開發者平時不需要關心也很難接觸得到。

我們在社群中也觀察到，越來越多的公司開始意識到內部自建的平臺跟不上社群生態發展的速度，期望通過 KubeVela 和 OAM 模型提供一致體驗、又不丟失生態的可擴充套件性，但是苦於 KubeVela 的控制平面依賴 Kubernetes、上手門檻依舊不低。針對這個問題，社群一直在思考並尋找解決方案，最終我們的結論是需要一款工具來滿足，且具備這幾個特性：

只依賴容器環境（如 Docker）就能部署執行，讓每一個開發者都能輕易地獲取並使用；
本地開發與生產環境體驗完全一致，且配置可複用，能夠模擬混合多叢集環境；
單一二進位制包，支援離線部署，環境初始化的時間不超過喝一杯水的時間（3分鐘）；

經過幾個月的努力孵化，我們終於可以在 1.4 中正式釋出這個工具： VelaD ，D 既代表 Daemon 也代表 Developer，它可以幫助 KubeVela 在單機上執行，不依賴任何現有的 Kubernetes 叢集，同時與 KubeVela 整體作為一個輕量級的應用開發控制平面，幫助開發者獲得一體化的開發、測試、交付體驗，簡化雲原生應用部署和管理的複雜度。

你可以通過 Demo 文件安裝並試用這個工具，瞭解更多的實現細節，安裝初始化僅需 3 分鐘。

展示資源拓撲和狀態，讓交付過程變得透明化

在應用交付中另一個很大的訴求是對資源交付流程的透明化管理，比如社群裡很多使用者喜歡使用 Helm Chart ，把一大堆複雜的 YAML 打包在一起，但是一旦部署出現問題，如底層儲存未正常提供、關聯資源未正常建立、底層配置不正確等，即使是一個很小的問題也會因為整體黑盒化而難以排查。尤其是在現代混合的多叢集混合環境下，資源型別眾多、錯綜複雜，如何從中獲取到有效資訊並解決問題是一個非常大的難題。

在 1.4 版本中，我們加入了資源拓撲圖查詢功能，進一步完善了 KubeVela 以應用為中心的交付體驗。開發者在發起應用交付時只需要關心簡單一致的 API ，需要排查問題或者關注交付過程時，可以通過資源拓撲功能，快速獲取資源在不同叢集的編排關係，從應用一直追蹤到 Pod 例項執行狀態，自動化地獲取資源的關聯關係，包括複雜且黑盒化的 Helm Chart。

以上圖所示的應用為例，使用者通過 Helm Chart 包交付了一個 Redis 叢集，圖的第一層為應用名稱，第二層為叢集，第三層為應用直接渲染出來的資源，後續的三層，四層則根據不同的資源追蹤的下級關聯資源。

使用者在交付應用過程中，可以通過圖形來觀測其衍生出的資源以及狀態，不正常時節點會顯示為黃色或紅色狀態並顯示具體原因。比如下圖所示應用，是一個基礎的 Webservice 服務交付到了2個叢集，開發者可以發現該應用實際在兩個叢集分別建立了Deployment 和 Service 資源，而 ask-hongkong 這個叢集中的 Deployment 資源顯示黃色，是因為 Pod 例項還沒有完全啟動。

該功能也支援通過不同叢集，不同元件進行搜尋篩選查詢，幫助開發者快速聚焦並發現問題，以極低的門檻瞭解應用底層的交付運轉狀態。

如果你想了解更多功能及其背後的實現原理，歡迎閱讀官方部落格追蹤和視覺化多叢集 Kubernetes 資源拓撲深入瞭解背後的執行機制。

其他關鍵變更

除了核心功能和外掛生態之外，1.4 版本也對工作流等核心功能做了增強：

應用狀態維持支援配置欄位忽略規則，從而實現了 KubeVela 和其他控制器協同工作，比如 HPA 和 Istio 等。
應用資源回收支援基於資源型別設定，目前已支援基於元件名稱，元件型別，特徵型別和資源型別。
工作流支援子步驟能力，子步驟支援併發執行，加速了多叢集高可用場景下的資源交付速度。
工作流步驟支援暫停某一段時間，暫停時間到達後自動繼續執行工作流。
資源部署和回收支援遵循元件依賴規則設定，支援資源按順序部署、按順序回收。
工作流步驟支援條件判斷，目前支援 if: always 規則，代表該步驟在任何情況下執行，從而支援部署失敗通知。
運維特徵支援設定部署範圍，可實現運維特徵與元件部署狀態分離，運維特徵可以獨立部署在管控叢集。

感謝來自阿里雲、招商銀行、Napptive 等三十多個海內外組織和個人的持續貢獻，正是你們的不斷努力，在短短 2 個月的時間內完成了 200 多個功能特性和修復，才使得這次迭代為社群交付出如此多優秀的功能！

更多的變更細節，請參考 Release 說明。

外掛生態（Addon）

隨著 1.3 外掛體系的完善，我們的外掛生態也在快速擴充中：

更新 fluxcd addon 支援了 OCI registry ，支援在部署時選擇 chart 中不同的 values 檔案。
新增 cert-manager 外掛，自動化管理 Kubernetes 證書。
新增 flink-kubernetes-operator 外掛，交付 flink 工作負載。
新增 kruise-rollout 外掛，支援灰度釋出，金絲雀釋出等多種釋出策略。
新增 pyroscope 外掛，支援持續的效能調優。
新增 traefik 外掛，支援配置 API 閘道器。
新增 vegeta 外掛，支援對工作負載做自動化壓測。
新增 argocd 外掛，支援基於 ArgoCD 的 Helm 交付和 GitOps。
新增 dapr 外掛，支援 Dapr 訂閱、釋出的運維能力。
新增 istio 外掛，支援基於 Istio 的閘道器能力和流量灰度。
新增 mysql-operator 外掛，支援部署高可用的分散式 mysql 資料庫。

非常歡迎開發者們參與到社群，製作外掛擴充套件 KubeVela 的系統能力。

如何參與社群

KubeVela 是 CNCF 基金會中全球 Top 級活躍度的開源專案，在這裡有超過 300 位國內外貢獻者、40 多位社群成員和 Maintainer，從程式碼、文件到社群溝通交流均為中英雙語國際化運作方式，有超過 4000 多位社群成員。

如果你對參與到開源社群感興趣，我們非常歡迎你加入到 KubeVela 的社群中來，你可以通過 KubeVela 社群的開發者文件詳細的瞭解參與到開源社群的方式和方法，社群的工程師們也會耐心指導你入門。

近期的規劃

KubeVela 將圍繞兩個月一個迭代週期持續演進，接下來的版本中，我們將聚焦這三個維度：

可觀測性，圍繞 log、metrics、tracing 等維度提供端到端豐富的應用洞察能力，為應用交付的穩定性、智慧化打下堅實的基礎。
工作流交付能力，提供更豐富的框架和整合能力，包括自定義步驟超時、基於上下文資訊的條件判斷和分支工作流等，銜接 CI/CD，為使用者提供更豐富的使用案例和場景。
應用（含外掛）管理能力，支援應用的關閉、重啟，支援應用的匯入、匯出、上傳至應用（外掛）市場等。

如果你想了解更多的規劃、成為貢獻者或者合作伙伴，可以通過參與社群溝通（ http://github.com/kubevela/community ）聯絡我們，期待你的加入！

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

專案程式碼庫：github.com/oam-dev/kubevela 歡迎 Star/Watch/Fork！
專案官方主頁與文件：kubevela.io ，從 1.1 版本開始，已提供中文、英文文件，更多語言文件歡迎開發者進行翻譯。
專案釘釘群：23310022；Slack：CNCF #kubevela Channel
加入微信群：請先新增以下 maintainer 微訊號，表明進入KubeVela使用者群：

點選“此處”，檢視 KubeVela 專案官網。