當(dāng)前位置：首頁(yè) > 编程资源 > 编程问答 >内容正文

编程问答

以一致的体验交付和管理云原生多集群应用

發(fā)布時(shí)間：2025/3/20 编程问答 18 豆豆

生活随笔收集整理的這篇文章主要介紹了以一致的体验交付和管理云原生多集群应用小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

作者：馮泳，孫健波

大家好，很高興能在 KubeCon 中國(guó)峰會(huì)給大家做分享，今天的主題是“以一致的體驗(yàn)構(gòu)建和管理多集群應(yīng)用”，主角是 KubeVela 和 OCM，這兩個(gè)都是 CNCF 的開(kāi)源項(xiàng)目。整個(gè)演講大致分為三部分，首先介紹云原生應(yīng)用交付和管理的挑戰(zhàn)，然后介紹這背后的 KubeVela 和 OCM 技術(shù)原理，最后是整體的最佳實(shí)踐，以及一個(gè)完整的 Demo。

背景

隨著云原生生態(tài)的繁榮，Kubernetes?逐漸成為了基礎(chǔ)設(shè)施的標(biāo)準(zhǔn)集成界面，越來(lái)越多的基礎(chǔ)設(shè)施能力變成了開(kāi)箱即用的聲明式 API，CRD Operator [1 ] 的普及也讓運(yùn)維能力也逐漸趨向于聲明式和自動(dòng)化。如圖 1 所示，從底層基礎(chǔ)設(shè)施到上層應(yīng)用開(kāi)發(fā)，如今的?CNCF 生態(tài) [2 ] 中有上千個(gè)項(xiàng)目。

圖 1. CNCF landscape 生態(tài) - 摘自 2021.12

然而眾多的選擇是禮物，也是研發(fā)工程師的煩惱。不同的應(yīng)用架構(gòu)涉及到的不同開(kāi)發(fā)語(yǔ)言、技術(shù)框架、打包方式、制品形態(tài)、云資源、以及運(yùn)維方式各不相同。軟件生命周期中，開(kāi)發(fā)、測(cè)試、預(yù)發(fā)灰度、生產(chǎn)部署對(duì)應(yīng)的環(huán)境和應(yīng)用交付部署體驗(yàn)也存在很大的不一致。研發(fā)人員切換到云原生技術(shù)棧就涉及大量復(fù)雜的新知識(shí)需要學(xué)習(xí)，這就好比對(duì)著大量操作系統(tǒng)底層的 API 寫(xiě)程序，缺乏了編程框架和標(biāo)準(zhǔn)庫(kù)，讓?xiě)?yīng)用開(kāi)發(fā)事倍功半。

如何用好云原生繁榮的技術(shù)生態(tài)，又能讓業(yè)務(wù)的研發(fā)人員獲得一致的低門(mén)檻體驗(yàn)，同時(shí)安全可靠的交付應(yīng)用，是業(yè)界面臨的巨大挑戰(zhàn)。

業(yè)界的典型做法與挑戰(zhàn)

為了解決應(yīng)用交付的這最后一公里問(wèn)題，業(yè)界的典型做法主要分為兩大類(lèi)。

第一類(lèi)是在針對(duì)自身的業(yè)務(wù)場(chǎng)景基于 Kubernetes 構(gòu)建內(nèi)部的 PaaS 平臺(tái)，隱藏 Kubernetes 平臺(tái)接口，提供自身平臺(tái) API。這種模式通常在規(guī)模較大的公司，需要有對(duì) Kubernetes 和業(yè)務(wù)都比較精通的團(tuán)隊(duì)支撐。但是隨著時(shí)間的推移，業(yè)務(wù)場(chǎng)景變得復(fù)雜、需求逐漸增加，內(nèi)部自建的 PaaS 都會(huì)面臨擴(kuò)展能力不足、難以維護(hù)，最后不得不推翻重做的困境，這個(gè)問(wèn)題在阿里早期的應(yīng)用云原生化改造的實(shí)踐過(guò)程中尤為明顯。另一方面，規(guī)模較大的公司通常會(huì)有不同的業(yè)務(wù)團(tuán)隊(duì)，由于頂層設(shè)計(jì)不足，不同團(tuán)隊(duì)各自構(gòu)建的 PaaS 平臺(tái)很容易成為互相獨(dú)立的煙囪，大量相似的能力只能重復(fù)建設(shè)、無(wú)法復(fù)用，更無(wú)法統(tǒng)一管理。每個(gè)不同場(chǎng)景的不同平臺(tái)又給更上層的業(yè)務(wù)團(tuán)隊(duì)帶來(lái)了新的概念和學(xué)習(xí)負(fù)擔(dān)。

針對(duì)第一類(lèi)場(chǎng)景存在的問(wèn)題，業(yè)界逐漸傾向于容器平臺(tái)層原汁原味透出 K8s 原生 API，負(fù)責(zé)提供穩(wěn)定的云原生生態(tài)能力，同時(shí)不影響靈活性和擴(kuò)展性。應(yīng)用交付通過(guò)類(lèi)似 Jenkins/Gitlab 這樣的 Pipeline ，將應(yīng)用制品打包（如 Helm Chart 等），然后直接部署到容器平臺(tái)中，這就延伸出第二類(lèi)做法。基于傳統(tǒng) CI 生態(tài)工具直接對(duì)接容器平臺(tái)的模式，如圖 2 所示，這類(lèi)做法的核心是通過(guò)腳本、配置等方式構(gòu)建抽象體系來(lái)簡(jiǎn)化使用門(mén)檻。這個(gè)方式目前是業(yè)內(nèi)較為流行的解決方案，其好處分工較為明確，容器平臺(tái)層作為 Infra/SRE 團(tuán)隊(duì)維護(hù)基礎(chǔ)設(shè)施能力，應(yīng)用交付則充分利用企業(yè)內(nèi)現(xiàn)有的 CI 體系，不需要建設(shè)平臺(tái)。

圖 2. 業(yè)界典型的解決方案

這種方式一定程度上解決了應(yīng)用管理的問(wèn)題，對(duì)于中小規(guī)模的企業(yè)即使對(duì)容器平臺(tái)缺乏維護(hù)能力，也可以通過(guò)購(gòu)買(mǎi)云服務(wù)的方式解決，同時(shí)也能為業(yè)務(wù)開(kāi)發(fā)者提供一站式的一致體驗(yàn)。但主要問(wèn)題就出現(xiàn)在前面應(yīng)用交付這一環(huán)，無(wú)論是哪種規(guī)模和場(chǎng)景的企業(yè)，都會(huì)很快遇到這些挑戰(zhàn)：

缺乏自動(dòng)化，需要大量手工維護(hù)工作。 比如由于突發(fā)的網(wǎng)絡(luò)原因、或者由于 Pipeline 系統(tǒng)自身的某個(gè)問(wèn)題，就會(huì)中斷所有的發(fā)布并且需要人工介入，缺乏自愈能力。
缺乏統(tǒng)一的應(yīng)用模型。 無(wú)論是作為應(yīng)用的完整交付物，還是作為應(yīng)用的核心入口（single source of truth），應(yīng)用模型的統(tǒng)一都是極其重要的。缺乏統(tǒng)一的模型描述作為應(yīng)用交付入口，就會(huì)導(dǎo)致不同的人可以從多處對(duì)系統(tǒng)進(jìn)行變更，例如通過(guò) CI Pipeline 系統(tǒng)、或者直接更改 Kubernetes，時(shí)間久了系統(tǒng)的配置會(huì)出現(xiàn)很大的不一致，從而引發(fā)故障。
存在安全風(fēng)險(xiǎn)。 基于 CI pipeline 系統(tǒng)構(gòu)建的應(yīng)用交付，CI/CD 體系的安全域通常不具備隔離性，即 CI/CD 通過(guò)一套系統(tǒng)完成，基礎(chǔ)設(shè)施所有集群的秘鑰全都在同一套系統(tǒng)中存儲(chǔ)，一旦被黑客突破容易引發(fā)非常大的系統(tǒng)安全風(fēng)險(xiǎn)。如代碼覆蓋率統(tǒng)計(jì)工具 Codecov 在今年 4 月份就遭遇了一起安全事故 [3 ] ，所有使用該產(chǎn)品的項(xiàng)目配置的 CI 秘鑰全部泄露。另一方面，越來(lái)越多的開(kāi)源軟件被采納到企業(yè)的生產(chǎn)系統(tǒng)，這些軟件的集成也加劇了安全隱患。
維護(hù)成本高。 通過(guò)腳本和模板簡(jiǎn)化開(kāi)發(fā)者心智是這種模式的核心，但是腳本和模板本身的維護(hù)如果缺乏開(kāi)源標(biāo)準(zhǔn)和生態(tài)，很快就會(huì)缺乏活力，久而久之就變成了再也無(wú)人敢碰的神秘代碼，極度依賴(lài)這套體系最初的構(gòu)建者經(jīng)驗(yàn)，難以延續(xù)和迭代。

所以如何構(gòu)建穩(wěn)定可靠的應(yīng)用交付和管理體系，成為了我們亟需探索的關(guān)鍵。

如何構(gòu)建穩(wěn)定可靠的應(yīng)用交付和管理體系？

如何保證應(yīng)用交付的穩(wěn)定、可靠和安全，我們分別來(lái)看解決問(wèn)題的方法。首先，為了解決大規(guī)模應(yīng)用交付的穩(wěn)定性和可靠性問(wèn)題，我們從 Kubernetes 的設(shè)計(jì)中得到了啟示。

Kubernetes 帶來(lái)的啟示

Kubernetes 有兩個(gè)核心理念，一個(gè)是聲明式 API，一個(gè)是面向終態(tài)的控制循環(huán)。

聲明式是用戶(hù)側(cè)抽象的最佳表達(dá)方式，它可以大大簡(jiǎn)化用戶(hù)的心智，從描述過(guò)程到描述結(jié)果。聲明式為什么可以簡(jiǎn)化心智，舉一個(gè)吃飯的例子大家就容易理解了，傳統(tǒng)基于過(guò)程式的描述就好比你自己在家里吃飯，你要購(gòu)買(mǎi)食材、研究菜譜，一直到做出來(lái)吃到，最后還要洗碗，整個(gè)過(guò)程是非常復(fù)雜的。而聲明式的描述就是你去餐廳里吃飯，點(diǎn)菜的時(shí)候告訴服務(wù)員你想吃的菜是什么，最終餐廳會(huì)把你要點(diǎn)的菜端上來(lái)給你。

圖 3. Kubernetes 的控制循環(huán)

另一方面，面向終態(tài)的控制循環(huán)也是保證可靠性的最佳方式，這個(gè)設(shè)計(jì)原則要求我們的系統(tǒng)具備以下特性：

自動(dòng)化，即能夠始終面向最終的狀態(tài)去運(yùn)行，如果沒(méi)達(dá)到狀態(tài)，就繼續(xù)運(yùn)行。自動(dòng)化的特性也保證了我們的系統(tǒng)不會(huì)因?yàn)橐稽c(diǎn)點(diǎn)不穩(wěn)定就中斷，具備很強(qiáng)的自愈能力。
收斂性，即在系統(tǒng)運(yùn)行過(guò)程中結(jié)果可以向終態(tài)靠攏，每次執(zhí)行都能不斷逼近最終結(jié)果。
冪等性，表示我們多次執(zhí)行同樣的流程要保證結(jié)果是一致的，不會(huì)因?yàn)閳?zhí)行了多次就出現(xiàn)意外的問(wèn)題。
確定性，表示系統(tǒng)只要運(yùn)行是正常的，最終能夠不斷執(zhí)行，直到達(dá)成一個(gè)確定的結(jié)果。

這四大特性也是大規(guī)模應(yīng)用交付的核心要素。

應(yīng)用交付安全性的原則

然后我們來(lái)看看安全性的問(wèn)題，其實(shí)核心很簡(jiǎn)單，就是像對(duì)待生產(chǎn)環(huán)境一樣對(duì)待應(yīng)用交付系統(tǒng)的安全性。CNCF 基金會(huì)在 2021 年 4 月份也發(fā)布了應(yīng)用交付最佳實(shí)踐 [4 ] 和白皮書(shū) [5] ，其中就提到了應(yīng)用交付的一些安全性原則。

交付環(huán)境隔離，一方面指不同的交付目的地應(yīng)該是隔離的，交付系統(tǒng)不應(yīng)該可以直接訪問(wèn)所有的 Kubernetes 集群，同時(shí)不同的環(huán)境之間也應(yīng)該是隔離的。另一方面，針對(duì) CI/CD 不同應(yīng)用生命周期的階段，安全域也應(yīng)該是隔離的，使用獨(dú)立的秘鑰信息。
集成物檢查，這個(gè)原則指我們?cè)诮桓哆^(guò)程中，要對(duì)集成的開(kāi)源工具，使用的依賴(lài)包，以及應(yīng)用本身的鏡像做必要的安全檢查。
最小權(quán)限，這個(gè)原則大家都比較容易理解，具體到實(shí)踐中就是要做權(quán)限的拆分。比如使用 token 而非永久秘鑰，加入必要的審批流程，使用秘鑰管理工具。尤其是云資源的使用，要對(duì)秘鑰做必要的權(quán)限拆分，如使用子賬號(hào)等機(jī)制，避免一個(gè)秘鑰泄露又不能及時(shí)回收導(dǎo)致出現(xiàn)單點(diǎn)故障。
審計(jì)和安全監(jiān)控，這個(gè)原則要求我們的應(yīng)用交付和管理系統(tǒng)本身也要具備很好的可觀測(cè)性能力，具備交付行為的審計(jì)和整體的安全監(jiān)控。

面向終態(tài)的應(yīng)用交付體系核心要素

所以總結(jié)下來(lái)，一個(gè)穩(wěn)定、可靠、安全的應(yīng)用交付系統(tǒng)，需要具備的核心要素如下圖 4 所示。

圖 4. 應(yīng)用交付體系的核心要素

這個(gè)體系的入口是一個(gè)完整的應(yīng)用模型，涵蓋不同的交付物、云資源、以及各類(lèi)環(huán)境編排的配置，它是應(yīng)用交付的統(tǒng)一入口，也是唯一的依據(jù)。

與此同時(shí)，這個(gè)應(yīng)用模型采用聲明式的方式面向業(yè)務(wù)用戶(hù)，為業(yè)務(wù)層提供針對(duì)使用場(chǎng)景的抽象能力，能夠降低用戶(hù)的使用門(mén)檻，降低底層的 API 的復(fù)雜性，同時(shí)具備靈活擴(kuò)展的能力。交付系統(tǒng)通過(guò)拉取的方式與聲明式 API 交互，用戶(hù)只需要在模型層描述終態(tài)，最終交付系統(tǒng)就會(huì)朝著這個(gè)終態(tài)不斷收斂。

在交付系統(tǒng)內(nèi)部，要具備編排和部署兩大核心功能。同時(shí)這兩大核心功能的背后要始終維持一個(gè)面向終態(tài)持續(xù)運(yùn)行的控制循環(huán)，這個(gè)控制循環(huán)是自動(dòng)化和確定性的基石，同時(shí)也要具備對(duì)交付物、交付流程安全監(jiān)測(cè)和審計(jì)的能力。

其中，編排解決的是不同交付物直接的依賴(lài)關(guān)系、部署順序、數(shù)據(jù)傳遞以及多集群多環(huán)境配置的問(wèn)題，然而編排的復(fù)雜性不應(yīng)該暴露給用戶(hù)。交付系統(tǒng)的編排執(zhí)行引擎應(yīng)該能夠根據(jù)用戶(hù)描述的聲明式終態(tài)自動(dòng)化的完成編排，而不是讓用戶(hù)手動(dòng)編寫(xiě)編排的過(guò)程。部署則解決的是不同交付的部署，如云資源、Kubernetes 資源，以及多集群的交付問(wèn)題，需要能夠提供充分的可擴(kuò)展性，保證不同的交付物均可以部署，同時(shí)能夠在多集群環(huán)境隔離的安全條件下完成部署。

下一代云原生應(yīng)用交付與管理

KubeVela 就是完全遵循這套理念構(gòu)建的現(xiàn)代化的應(yīng)用交付平臺(tái)，它可以讓你的應(yīng)用交付與管理在當(dāng)今流行的混合、多云環(huán)境中變得更加簡(jiǎn)單、輕松、可靠。演進(jìn)至今已有上百位貢獻(xiàn)者參與代碼貢獻(xiàn)，吸納了來(lái)自阿里、螞蟻、騰訊、字節(jié)、第四范式、Gitlab等一系列不同領(lǐng)域公司的工程實(shí)踐，充分利用云原生領(lǐng)域百花齊放的技術(shù)生態(tài)紅利實(shí)現(xiàn)應(yīng)用的交付與管理。

圖 5. KubeVela 架構(gòu)

標(biāo)準(zhǔn)、開(kāi)放的應(yīng)用模型（OAM）

KubeVela 背后有一個(gè)完整的應(yīng)用模型，那就是 OAM（Open Application Model）。OAM 是阿里和微軟在 2019 年聯(lián)合發(fā)布的應(yīng)用模型，如今已經(jīng)被阿里、微軟、Oracle、Salesforce、騰訊等眾多云廠商實(shí)踐到云產(chǎn)品中，同時(shí)也被國(guó)家信通院立項(xiàng)作為《云計(jì)算開(kāi)放應(yīng)用架構(gòu)》行業(yè)標(biāo)準(zhǔn)發(fā)布。

圖 6. OAM 應(yīng)用模型

如圖 6 所示，OAM 模型將復(fù)雜的應(yīng)用交付和管理抽象成應(yīng)用、組件、運(yùn)維能力，以及工作流這四個(gè)核心概念，使得用戶(hù)可以通過(guò)一份配置文件，描述應(yīng)用交付和管理的全部?jī)?nèi)容。OAM 具備充分的可擴(kuò)展性，滿(mǎn)足應(yīng)用交付到不同云、不同環(huán)境的訴求。同時(shí) OAM 也不綁定 Kubernetes 生態(tài)，若開(kāi)箱即用的 KubeVela 不滿(mǎn)足需求，OAM 社區(qū)也歡迎用戶(hù)參與到模型層的建設(shè)中，根據(jù)模型獨(dú)立實(shí)現(xiàn)。

基于 Kubernetes 的應(yīng)用交付控制平面

KubeVela 是一個(gè)微內(nèi)核的架構(gòu)，其核心是一個(gè)基于 Kubernetes 的應(yīng)用交付和管理控制平面，具備自愈、冪等、收斂以及確定這四大特性。最小化部署的 KubeVela 只需要 0.5 核以及 200M 內(nèi)存即可支持上百個(gè)應(yīng)用的交付。同時(shí) KubeVela 自身也具備一系列開(kāi)箱即用的插件，支持包括多集群交付、云資源管理、GitOps、Helm chart、可觀測(cè)性等一系列功能，甚至包括 KubeVela 自身的 UI 控制臺(tái)也是通過(guò)插件的方式集成的。

KubeVela 也不僅局限于 Kubernetes 生態(tài)，官方內(nèi)置的云資源插件就可以集成任意的 terraform 模塊，交付不同的云資源，甚至虛擬機(jī)。同時(shí)得益于 OAM 模型以及 KubeVela 從設(shè)計(jì)之初就嚴(yán)格遵循的可擴(kuò)展性原則，用戶(hù)可以輕易的增加和擴(kuò)展生態(tài)的能力。

安全、可靠的多集群管理技術(shù)（OCM）

KubeVela 背后的多集群技術(shù)也是保證應(yīng)用穩(wěn)定、安全、大規(guī)模交付的核心。我們知道，因?yàn)榈赜?#xff0c;規(guī)模，容災(zāi)等方面的考慮，多集群早已成為企業(yè)內(nèi)部基礎(chǔ)設(shè)施的普遍形態(tài)。然而，Kubernetes 原生的管理能力目前仍然停留在單集群級(jí)別。每一個(gè)集群可以穩(wěn)定地自治運(yùn)行，但是卻缺乏橫貫多個(gè)集群的統(tǒng)籌管理能力。為了形成一個(gè)穩(wěn)定、統(tǒng)一的應(yīng)用交付和管理平臺(tái)，需要具備如下能力：

運(yùn)維管理人員能夠獲知多集群水位的變化，節(jié)點(diǎn)健康狀態(tài)等信息
業(yè)務(wù)負(fù)責(zé)人能夠決策如何調(diào)配應(yīng)用服務(wù)在各個(gè)集群中的部署分布
應(yīng)用運(yùn)維人員能夠獲知服務(wù)狀態(tài)，下發(fā)騰挪的策略

得益于 RedHat 和螞蟻、阿里云共同發(fā)起并開(kāi)源的 OCM（Open Cluster Management）多集群技術(shù)，KubeVela 可以輕松解決多集群、混合環(huán)境下資源、應(yīng)用、配置、策略等對(duì)象的生命周期管理問(wèn)題。OCM 使得用戶(hù)在多集群和混合環(huán)境下也能像在單個(gè) Kubernetes 集群平臺(tái)上一樣，使用自己熟悉的開(kāi)源項(xiàng)目和產(chǎn)品輕松交付和管理應(yīng)用。

圖 7. OCM 的技術(shù)特點(diǎn)

與目前已有的多集群技術(shù)相比，OCM 的架構(gòu)在以下方面具有技術(shù)領(lǐng)先優(yōu)勢(shì)，滿(mǎn)足用戶(hù)對(duì)云原生應(yīng)用交付安全、穩(wěn)定、大規(guī)模能力的核心訴求：

模塊化： OCM 管理平臺(tái)由管理原語(yǔ)，基礎(chǔ)組件和眾多可擴(kuò)展組件構(gòu)成，這些組件可以像樂(lè)高積木一樣自由組合構(gòu)建滿(mǎn)足用戶(hù)需求的功能集合。這一理念與 KubeVela 也天然契合，共同為用戶(hù)提供了充分的生態(tài)可擴(kuò)展性。
大規(guī)模： OCM的基礎(chǔ)架構(gòu)繼承了 Kubernetes 開(kāi)放，可擴(kuò)展的特點(diǎn)。正如單一 Kubernetes 集群可以支持?jǐn)?shù)千個(gè)節(jié)點(diǎn)一樣，OCM 在設(shè)計(jì)上可以支持?jǐn)?shù)千個(gè)被管理集群。
安全： OCM 在設(shè)計(jì)上以零信任和最小權(quán)限為基礎(chǔ)，管理組件和被管理上的 agent 之間的注冊(cè)通信采用兩次握手的方式。此外證書(shū)的更新，訪問(wèn)權(quán)限的管理，權(quán)限 token 的分發(fā)也采用和 Kubernetes 類(lèi)似的設(shè)計(jì)，由相應(yīng)的可擴(kuò)展組件通過(guò) Kubernetes 原生 API 方式實(shí)現(xiàn)。
可擴(kuò)展性： OCM 提供了可擴(kuò)展組件的編程框架和管理 API，和基礎(chǔ)組件，管理原語(yǔ)一起，能夠方便的將Kubernetes 生態(tài)中的項(xiàng)目遷移到 OCM 多集群管理平臺(tái)。通過(guò)編程框架，OCM 社區(qū)已經(jīng)在多集群環(huán)境實(shí)現(xiàn)了眾多 Kubernetes 的管理能力，也得益于此，KubeVela 與 OCM 可以輕松實(shí)現(xiàn)深度集成。

KubeVela 和 OCM 協(xié)同下的安全、一致的應(yīng)用交付體驗(yàn)

KubeVela 和 OCM 天生具有互補(bǔ)性。KubeVela 負(fù)責(zé)應(yīng)用層的交付和生命周期管理，OCM 則管理集群基礎(chǔ)設(shè)施資源的生命周期。它們緊密合作在一起提供了應(yīng)用在多集群環(huán)境下交付和生命周期管理的端到端能力。

圖 8. 跨環(huán)境、多集群交付的一致體驗(yàn)

如圖 8 所示，使用 KubeVela 和 OCM，用戶(hù)在不同環(huán)境的交付過(guò)程將完全自動(dòng)化，節(jié)省大量人工操作。

同一個(gè)應(yīng)用，業(yè)務(wù)研發(fā)人員只要描述一次組件，就可以在不同交付環(huán)境下綁定不同運(yùn)維能力獨(dú)立運(yùn)行，比如開(kāi)發(fā)環(huán)境可以使用端云聯(lián)調(diào)，而預(yù)發(fā)生產(chǎn)環(huán)境可以綁定可觀測(cè)性策略等等，無(wú)需重復(fù)諸如鏡像、端口、環(huán)境變量等組件級(jí)別的參數(shù)，大大節(jié)省了心智負(fù)擔(dān)。
另一方面，在控制平面，不同一個(gè)應(yīng)用的跨環(huán)境部署可以在一次交付過(guò)程中自動(dòng)化完成，可以自助選擇多種審批方式或是全自動(dòng)執(zhí)行。

更為重要的是，基于 KubeVela 和 OCM，可以構(gòu)建完全基于訂閱模式的安全 GitOps 多集群應(yīng)用交付。

圖 9. GitOps 模式下的安全應(yīng)用交付

如圖 7 所示，CI 的流程還是沿用之前的模式，但是 CD 這一側(cè)則描述一個(gè)獨(dú)立的配置倉(cāng)庫(kù)，首先從 Git 倉(cāng)庫(kù)配置層面，兩個(gè)倉(cāng)庫(kù)的權(quán)限是完全隔離的。通過(guò)統(tǒng)一的應(yīng)用模型，用戶(hù)可以在配置倉(cāng)庫(kù)完整的描述應(yīng)用，同時(shí) KubeVela 也可以監(jiān)聽(tīng)完整應(yīng)用描述的變化，從而主動(dòng)拉取應(yīng)用配置。這個(gè)過(guò)程中，Git 倉(cāng)庫(kù)不持有交付系統(tǒng)的任何秘鑰。在交付系統(tǒng)完成編排以后，管控?cái)?shù)據(jù)則通過(guò) OCM 完成下發(fā)，整個(gè)過(guò)程也是由運(yùn)行時(shí)集群主動(dòng)拉取的，交付系統(tǒng)沒(méi)有中央管控任何子集群的秘鑰。管控?cái)?shù)據(jù)下發(fā)到子集群以后，就可以由子集群的 GitOps agent 主動(dòng)獲取交付制品的變化，形成新的自治。

我們可以看到，每一個(gè)環(huán)節(jié)都獨(dú)立工作、自成體系，每一個(gè)環(huán)節(jié)都根據(jù)需要進(jìn)行授權(quán)和審核，安全可靠。KubeVela 和 OCM 的協(xié)同可以統(tǒng)一編排和管理混合云、多集群、以及邊緣應(yīng)用，最終實(shí)現(xiàn)云邊協(xié)同的安全交付。

開(kāi)啟你的端到端平臺(tái)化之路

在我們了解了以 KubeVela 和 OCM 為核心的應(yīng)用交付和管理引擎設(shè)計(jì)原理以后，我可以看到，這一套模式帶給我們的最大好處是自動(dòng)化、低門(mén)檻以及安全性。那么如何展開(kāi)實(shí)踐呢？從最新的 KubeVela v1.2 版本開(kāi)始，我們?cè)鰪?qiáng)了端到端的完整用戶(hù)實(shí)踐，你可以通過(guò)可視化的方式交付和管理應(yīng)用。

首先，KubeVela 的架構(gòu)是完全基于微內(nèi)核以及高可擴(kuò)展的模式打造的，它可以幫助用戶(hù)以最小的成本，按需構(gòu)建自己的云原生解決方案。如下圖 8 所示是 KubeVela 的插件管理頁(yè)面，包括 KubeVela 自身的 UI 功能以及 OCM 多集群功能，都是 KubeVela 的插件，在微內(nèi)核的基礎(chǔ)上，用戶(hù)可以任意定制和切換自己的擴(kuò)展功能。同時(shí)，它也幫助用戶(hù)敏捷地獲取更多的云原生生態(tài)能力，幫助企業(yè)更好的實(shí)現(xiàn)資源管理、 DevOps 、應(yīng)用治理等場(chǎng)景。實(shí)現(xiàn)層面，KubeVela 的插件體系完全基于開(kāi)源社區(qū)的模式共建互助，一切提交到社區(qū)插件倉(cāng)庫(kù) [6] 的內(nèi)容，就會(huì)自動(dòng)化的被 KubeVela 內(nèi)核發(fā)現(xiàn)，我們相信在不久的將來(lái)其即可有眾多的選擇。

圖 10. KubeVela 可視化插件頁(yè)面

KubeVela 也默認(rèn)支持了一系列組件類(lèi)型，如圖 9 所示，包括基于容器鏡像的應(yīng)用交付，該模式門(mén)檻低、無(wú)需了解 Kubernetes 知識(shí)，適用于大多數(shù)企業(yè)用戶(hù)；當(dāng)然也支持 Kubernetes 的 YAML 應(yīng)用，圍繞 OCM 技術(shù)將應(yīng)用交付到多個(gè)集群；另外，用戶(hù)通過(guò)安裝官方維護(hù)的插件，可以獲取到 Helm Chart 包、多種云廠商的云資源等組件類(lèi)型，并獲得對(duì)應(yīng)的完整應(yīng)用交付和管理能力。你可以充分發(fā)揮想象，通過(guò)擴(kuò)展，KubeVela 還能交付哪些類(lèi)型的應(yīng)用呢？

圖 11. KubeVela 的組件

KubeVela 端到端的 UI 體系中，也默認(rèn)添加了環(huán)境的概念，支持應(yīng)用開(kāi)發(fā)和交付生命周期中涉及到的不同環(huán)境，例如開(kāi)發(fā)、測(cè)試、生產(chǎn)環(huán)境等。同一個(gè)應(yīng)用在不同的環(huán)境中部署完全隔離，安全可靠，同時(shí)又無(wú)需用戶(hù)重復(fù)配置，給用戶(hù)帶來(lái)了一致的體驗(yàn)。

圖 12. 同一個(gè)環(huán)境中定義交付到多個(gè)集群

圖 13. 通過(guò)可配置的工作流控制交付流程

目前，KubeVela 1.2 已發(fā)布預(yù)覽版本?1.2.0-beta.3 [7] ，歡迎社區(qū)用戶(hù)下載體驗(yàn)。

未來(lái) KubeVela 將更多的提供端到端的完整用戶(hù)體驗(yàn)，豐富更多垂直場(chǎng)景下的能力，朝著開(kāi)發(fā)者能夠自助完成應(yīng)用交付的方向演進(jìn)，讓混合環(huán)境下的應(yīng)用交付就像我們今天使用 App Store 一樣簡(jiǎn)單。

總結(jié)

以上是生活随笔為你收集整理的以一致的体验交付和管理云原生多集群应用的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

集群

上一篇：基于 ASK + EB 构建容器事件驱动
下一篇：阿里云 MSE 云原生网关助力斯凯奇轻松