KubeVela 基礎(chǔ)入門(mén)，有你想知道的一切

作者：陽(yáng)明 2023-10-11 07:29:36
云計(jì)算
云原生 OAM（Open Application Model） 是阿里巴巴和微軟共同開(kāi)源的云原生應(yīng)用規(guī)范模型，OAM 的本質(zhì)是根據(jù)軟件設(shè)計(jì)的興趣點(diǎn)分離原則對(duì)負(fù)責(zé)的 DevOps 流程的高度抽象和封裝，一個(gè)以應(yīng)用為中心的 K8s API 分層，這種模型旨在定義云原生應(yīng)用的標(biāo)準(zhǔn)。

十載的新和網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開(kāi)發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。成都全網(wǎng)營(yíng)銷(xiāo)推廣的優(yōu)勢(shì)是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整新和建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無(wú)論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)從事“新和網(wǎng)站設(shè)計(jì)”,“新和網(wǎng)站推廣”以來(lái)，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。

KubeVela 是一個(gè)開(kāi)箱即用的現(xiàn)代化應(yīng)用交付與管理平臺(tái)，它使得應(yīng)用在面向混合云環(huán)境中的交付更簡(jiǎn)單、快捷，是開(kāi)放應(yīng)用模型（OAM）的一個(gè)實(shí)現(xiàn)，所以我們需要先了解下 OAM。

OAM 簡(jiǎn)介

OAM（Open Application Model） 是阿里巴巴和微軟共同開(kāi)源的云原生應(yīng)用規(guī)范模型，OAM 的本質(zhì)是根據(jù)軟件設(shè)計(jì)的興趣點(diǎn)分離原則對(duì)負(fù)責(zé)的 DevOps 流程的高度抽象和封裝，一個(gè)以應(yīng)用為中心的 K8s API 分層，這種模型旨在定義云原生應(yīng)用的標(biāo)準(zhǔn)。

OAM

從 OAM 名稱中可以看出，它是一個(gè)開(kāi)放的應(yīng)用模型：

• 開(kāi)放（Open）：支持異構(gòu)的平臺(tái)、容器運(yùn)行時(shí)、調(diào)度系統(tǒng)、云供應(yīng)商、硬件配置等，總之與底層無(wú)關(guān)
• 應(yīng)用（Application）：云原生應(yīng)用
• 模型（Model）：定義標(biāo)準(zhǔn)，以使其與底層平臺(tái)無(wú)關(guān)

為什么我們需要 OAM 模型呢？

現(xiàn)階段應(yīng)用管理的主要面臨兩個(gè)挑戰(zhàn)：

• 對(duì)應(yīng)用研發(fā)而言，Kubernetes 的 API 針對(duì)簡(jiǎn)單應(yīng)用過(guò)于復(fù)雜，針對(duì)復(fù)雜應(yīng)用卻又難以上手；
• 對(duì)應(yīng)用運(yùn)維而言，Kubernetes 的擴(kuò)展能力難以管理；Kubernetes 原生的 API 沒(méi)有對(duì)云資源全部涵蓋。

總體而言，面臨的主要挑戰(zhàn)就是：如何基于 Kubernetes 提供真正意義上的應(yīng)用管理平臺(tái)，讓研發(fā)和運(yùn)維只需關(guān)注到應(yīng)用本身。

比如下面是一個(gè)典型的 K8s 資源清單文件，該 yaml 文件已經(jīng)是被簡(jiǎn)化過(guò)的，但實(shí)際上還是比較長(zhǎng)。

k8s yaml

自上而下，我們可以大致把它們分為三塊：

• 一塊是擴(kuò)縮容、滾動(dòng)升級(jí)相關(guān)的參數(shù)，這一塊一般是運(yùn)維的同學(xué)比較關(guān)心的；
• 中間一塊是鏡像、端口、啟動(dòng)參數(shù)相關(guān)的，這一部分應(yīng)該是開(kāi)發(fā)的同學(xué)比較關(guān)心的；
• 最后一塊大家可能根本看不懂，當(dāng)然大部分情況下也不太需要明白，一般來(lái)說(shuō)這屬于 K8s 平臺(tái)層的同學(xué)需要關(guān)心的內(nèi)容。

看到這樣一個(gè) yaml 文件，我們很容易想到，只要把里面的字段封裝一下，把該暴露的暴露出來(lái)就好了。這個(gè)時(shí)候我們就可以去開(kāi)發(fā)一個(gè)應(yīng)該管理平臺(tái)，并做一個(gè)漂亮的前端界面給用戶，只暴露給用戶 5 個(gè)左右的字段，這顯然可以大大降低用戶理解 K8s 的心智負(fù)擔(dān)，底層實(shí)現(xiàn)用類(lèi)似模板的方式把這五個(gè)字段渲染成一個(gè)完整的 yaml 文件。

image: quay.io/coreos/prometheus-operator:v0.34.0
args:
  - --logtostderr=true
ports:
  - containerPort: 8080
    name: http
    protocol: TCP
envs:
  - name: INNER-KEY
    value: app
volumes:
  - name: cache-volume
    emptyDir: {}

該方式針對(duì)簡(jiǎn)單無(wú)狀態(tài)應(yīng)用非常有效，精簡(jiǎn) API 可以大大降低 K8s 的門(mén)檻。但是當(dāng)出現(xiàn)大規(guī)模業(yè)務(wù)后，就會(huì)遇到很多復(fù)雜的應(yīng)用，這個(gè)時(shí)候就會(huì)發(fā)現(xiàn)該 PaaS 應(yīng)用平臺(tái)能力不夠了。比如 ZK 多實(shí)例選主、主從切換這些邏輯，在這五個(gè)字段里就很難描述了。因?yàn)槠帘未罅孔侄蔚姆绞綍?huì)限制基礎(chǔ)設(shè)施本身的能力，而 K8s 的能力是非常強(qiáng)大而靈活的，所以我們不可能為了簡(jiǎn)化而放棄掉 K8s 本身強(qiáng)大的能力。

中間件的工程師跟我們說(shuō)，我這有個(gè) Zookeeper 該用哪種 K8s 的工作負(fù)載接入呢？我們當(dāng)然會(huì)想到可以讓他們使用 Operator 了，于是他們就很懵逼的說(shuō)到 Operator 是啥？

然后我們耐心的給他解釋相關(guān)概念 CRD、Controller、Informer、Reflector、Indexer 這些就可以了，當(dāng)然他們就更懵了，當(dāng)然理論上也不需要理解。業(yè)務(wù)方更應(yīng)該專(zhuān)注于他們的業(yè)務(wù)本身，當(dāng)然我們就不得不幫他們一起寫(xiě)這個(gè)控制器了。為此我們需要一個(gè)統(tǒng)一的模型去解決研發(fā)對(duì)應(yīng)用管理的訴求。

除了研發(fā)側(cè)的問(wèn)題之外，在運(yùn)維側(cè)同樣也會(huì)有很多挑戰(zhàn)。

K8s 的 CRD Operator 機(jī)制非常靈活而強(qiáng)大，不光是復(fù)雜應(yīng)用可以通過(guò)編寫(xiě) CRD Operator 實(shí)現(xiàn)，運(yùn)維能力當(dāng)然也可以通過(guò) Operator 來(lái)擴(kuò)展，比如灰度發(fā)布、流量管理、彈性擴(kuò)縮容等等。

比如有一個(gè)案例就是開(kāi)發(fā)了一個(gè) CronHPA 的 CRD，可以定時(shí)設(shè)置 HPA 的范圍，但是應(yīng)用運(yùn)維卻并不知道該 CRD 會(huì)跟原生的 HPA 會(huì)產(chǎn)生沖突，結(jié)果自然是引起了故障。這血的教訓(xùn)提醒我們要做事前檢查，熟悉 K8s 的機(jī)制很容易讓我們想到為每個(gè) Operator 加上 Admission Webhook。這個(gè) Admission Webhook 需要拿到這個(gè)應(yīng)用綁定的所有運(yùn)維能力以及應(yīng)用本身的運(yùn)行模式，然后做統(tǒng)一的校驗(yàn)。如果這些運(yùn)維能力都是一方提供的還好，如果存在兩方，甚至三方提供的擴(kuò)展能力，我們就沒(méi)有一個(gè)統(tǒng)一的方式去獲知了。

如果再深入思考下就知道我們需要一個(gè)統(tǒng)一的模型來(lái)協(xié)商并管理這些復(fù)雜的擴(kuò)展能力。

云原生應(yīng)用有一個(gè)很大的特點(diǎn)，那就是它往往會(huì)依賴云上的資源，包括數(shù)據(jù)庫(kù)、網(wǎng)絡(luò)、負(fù)載均衡、緩存等一系列資源。

當(dāng)我們交付應(yīng)用的時(shí)候比如使用 Helm 進(jìn)行打包，我們只能針對(duì) K8s 原生 API，而如果我們還想啟動(dòng) RDS 數(shù)據(jù)庫(kù)，就比較困難了。如果不想去數(shù)據(jù)庫(kù)的交互頁(yè)面，想通過(guò) K8s 的 API 來(lái)管理，那就又不得不去寫(xiě)一個(gè) CRD 來(lái)定義了，然后通過(guò) Operator 去調(diào)用實(shí)際云資源的 API。

這一整套交付物實(shí)際上就是一個(gè)應(yīng)用的完整描述，即我們所說(shuō)的“應(yīng)用定義”。這種定義方式最終所有的配置還是會(huì)全部堆疊到一個(gè) yaml 文件里，這跟前面說(shuō)的 all-in-one 問(wèn)題其實(shí)是一樣的，而且，這些應(yīng)用定義最終也都成為了黑盒，除了對(duì)應(yīng)項(xiàng)目本身可以使用，其他系統(tǒng)基本無(wú)法復(fù)用了。

而且事實(shí)上很多公司和團(tuán)隊(duì)也在根據(jù)自身業(yè)務(wù)需要進(jìn)行定義，比如 Pinterest 定義的應(yīng)用規(guī)范如下所示：

Pinterest CRD

應(yīng)用定義實(shí)際上是應(yīng)用交付/分發(fā)不可或缺的部分，所以我們可以思考下是否可以定義足夠開(kāi)放的、可復(fù)用的應(yīng)用模型呢？

一個(gè)應(yīng)用定義需要容易上手，但又不失靈活性，更不能是一個(gè)黑盒。應(yīng)用定義同樣需要跟開(kāi)源生態(tài)緊密結(jié)合，沒(méi)有生態(tài)的應(yīng)用定義注定是沒(méi)有未來(lái)的，自然也很難持續(xù)的迭代和演進(jìn)。

這也是為什么我們需要 OAM 的深層次的原因！?。?/p>

前面我們說(shuō)的各種問(wèn)題，歸根結(jié)底在于 K8s 的 All in One API 是為平臺(tái)提供者設(shè)計(jì)的，我們不能像下圖左側(cè)顯示的一樣，讓?xiě)?yīng)用的研發(fā)、運(yùn)維跟 K8s 團(tuán)隊(duì)一樣面對(duì)這一團(tuán) API。

All in One API

一個(gè)合理的應(yīng)用模型應(yīng)該具有區(qū)分使用者角色的分層結(jié)構(gòu)，同時(shí)將運(yùn)維能力模塊化的封裝。讓不同的角色使用不同的 API，如上圖右側(cè)部分。

OAM 模型定義

上面我們了解了為什么需要 OAM 模型，那么 OAM 模型到底是如何定義的呢？

在最新的 API 版本 v0.3.0 版本(core.oam.dev/v1beta1)中，OAM 定義了以下內(nèi)容：

• ComponentDefiniton：組件模型，OAM 中最基礎(chǔ)的單元，應(yīng)用程序中的每個(gè)微服務(wù)都可以被描述為一個(gè)組件，在實(shí)踐中，一個(gè)簡(jiǎn)單的容器化工作負(fù)載、Helm Chart 或云數(shù)據(jù)庫(kù)都可以定義為一個(gè)組件。
• WorkloadDefiniton: 工作負(fù)載是一個(gè)特定組件定義的關(guān)鍵特征，由平臺(tái)提供，以便用戶可以檢查平臺(tái)并了解哪些工作負(fù)載類(lèi)型可供使用。請(qǐng)注意，工作負(fù)載類(lèi)型不允許最終用戶創(chuàng)建新的（僅限平臺(tái)提供商） 。
• TraitDefinition: 為組件工作負(fù)載實(shí)例增加的運(yùn)維特征，運(yùn)維人員可以對(duì)組件的配置做出具體的決定。例如，向 WordPress Helm Chart 的工作負(fù)載注入 sidecar 容器的 sidecar trait。特征可以是適用于單個(gè)組件的分布式應(yīng)用程序的任何配置，例如負(fù)載均衡策略、網(wǎng)絡(luò)入口路由、斷路器、速率限制、自動(dòng)擴(kuò)展策略、升級(jí)策略等，特征是運(yùn)維人員的關(guān)注點(diǎn)。
• Application Scope: 應(yīng)用范圍是通過(guò)提供不同形式的應(yīng)用邊界和相同組的行為，將組件組合成邏輯應(yīng)用。應(yīng)用范圍可以決定組件是否可以被同時(shí)部署到同一應(yīng)用范圍類(lèi)型的多個(gè)實(shí)例中。
• Application: Application 定義了在部署應(yīng)用程序后將被實(shí)例化的組件列表。

因此，一個(gè)應(yīng)用程序是由一組具有一些運(yùn)維特征的組件組成的，并且被限定在一個(gè)或多個(gè)應(yīng)用程序邊界中。

OAM模型

具體的模型定義規(guī)范可以查看 OAM Spec 文檔了解更多，不過(guò)需要注意的是現(xiàn)在 KubeVela 的規(guī)范和 OAM 的規(guī)范并不是完全一樣的。

KubeVela 簡(jiǎn)介

KubeVela 是 OAM 規(guī)范（實(shí)際上 OAM 規(guī)范會(huì)滯后于 KubeVela 中使用的規(guī)范）的一個(gè)實(shí)現(xiàn)，是一個(gè)開(kāi)箱即用的現(xiàn)代化應(yīng)用交付與管理平臺(tái)，它使得應(yīng)用在面向混合云環(huán)境中的交付更簡(jiǎn)單、快捷。使用 KubeVela 的軟件開(kāi)發(fā)團(tuán)隊(duì)，可以按需使用云原生能力構(gòu)建應(yīng)用，隨著團(tuán)隊(duì)規(guī)模的發(fā)展、業(yè)務(wù)場(chǎng)景的變化擴(kuò)展其功能，一次構(gòu)建應(yīng)用，隨處運(yùn)行。

KubeVela

核心功能

KubeVela 具有以下幾個(gè)核心功能：

• 應(yīng)用部署即代碼（Deployment as Code），完整定義全交付流程
  使用 OAM 作為應(yīng)用交付的頂層抽象，這種方式使你可以用聲明式的方式描述應(yīng)用交付全流程，自動(dòng)化的集成 CI/CD 及 GitOps 體系，通過(guò)  CUE  輕松擴(kuò)展或重新編寫(xiě)你的交付過(guò)程。
• 天然支持企業(yè)級(jí)集成，安全、合規(guī)、可觀測(cè)性一應(yīng)俱全
  支持多集群認(rèn)證和授權(quán)并與 K8s RBAC 集成，還可以從社區(qū)的插件中心找到一系列開(kāi)箱即用的平臺(tái)擴(kuò)展，包括多種用戶體系（LDAP 等）集成、多租戶權(quán)限控制、安全校驗(yàn)和掃描、應(yīng)用可觀測(cè)性等大量企業(yè)級(jí)能力。
• 面向多云多集群混合環(huán)境，豐富的應(yīng)用交付和管理能力
  原生支持豐富的多集群/混合環(huán)境持續(xù)交付策略，包括金絲雀、藍(lán)綠、多環(huán)境差異化配置等，同樣也支持跨環(huán)境交付，這些交付策略為你的分布式交付流程提供了充足的效率和安全保證。
• 輕量并且架構(gòu)高度可擴(kuò)展，滿足企業(yè)不同場(chǎng)景的定制化需求
  KubeVela 最小的部署模式僅需 1 個(gè) pod （0.5 核 1G 內(nèi)存）就可以用于部署上千個(gè)應(yīng)用。其微內(nèi)核、高可擴(kuò)展的架構(gòu)可以輕松滿足你的擴(kuò)展和定制化需求，銜接企業(yè)內(nèi)部的權(quán)限體系、微服務(wù)、流量治理、配置管理、可觀測(cè)性等模塊。不僅如此，社區(qū)還有一個(gè)正在快速增長(zhǎng)的插件市場(chǎng)可供你選擇和使用，你可以在這里貢獻(xiàn)、復(fù)用社區(qū)豐富的功能模塊。

關(guān)注點(diǎn)分離

關(guān)注點(diǎn)分離這個(gè)屬于 KubeVela 的核心理念，它是 KubeVela 的設(shè)計(jì)哲學(xué)，也是 KubeVela 與眾不同的地方。KubeVela 的用戶天然分為兩種角色，由公司的兩個(gè)團(tuán)隊(duì)（或個(gè)人）承擔(dān)。

• 平臺(tái)團(tuán)隊(duì)
  由平臺(tái)工程師完成，他們需要準(zhǔn)備應(yīng)用部署環(huán)境，維護(hù)穩(wěn)定可靠的基礎(chǔ)設(shè)施功能（如 mysql operator），并將基礎(chǔ)設(shè)施能力作為 KubeVela 模塊定義注冊(cè)到集群中。他們需要具備豐富的基礎(chǔ)設(shè)施經(jīng)驗(yàn)。
• 最終用戶
  最終用戶即業(yè)務(wù)應(yīng)用的開(kāi)發(fā)者，使用平臺(tái)的過(guò)程中首先選擇部署環(huán)境，然后挑選能力模塊，填寫(xiě)業(yè)務(wù)參數(shù)并組裝成 KubeVela 應(yīng)用。他們無(wú)需關(guān)心基礎(chǔ)設(shè)施細(xì)節(jié)。

關(guān)注點(diǎn)分離

核心概念

KubeVela 遵循 OAM 規(guī)范通過(guò)一個(gè) Application 的對(duì)象來(lái)聲明一個(gè)微服務(wù)應(yīng)用的完整交付流程，其中包含了待交付組件、關(guān)聯(lián)的運(yùn)維能力、交付流水線等內(nèi)容。所有待交付組件、運(yùn)維動(dòng)作和流水線中的每一個(gè)步驟，都遵循 OAM 規(guī)范設(shè)計(jì)為獨(dú)立的可插拔模塊，允許用戶按照自己的需求進(jìn)行組合或者定制。

基本上 Application  對(duì)象是終端用戶唯一需要了解的對(duì)象，它表達(dá)了一個(gè)微服務(wù)應(yīng)用的部署計(jì)劃。遵循 OAM 規(guī)范，一個(gè)應(yīng)用部署計(jì)劃（Application）由組件（Component）、運(yùn)維特征（Trait）、部署工作流（Workflow）、應(yīng)用執(zhí)行策略（Policy）四部分組成，這些組件是平臺(tái)構(gòu)建者維護(hù)的可編程模塊，這種抽象方式是高度可擴(kuò)展、可定制的。

• 組件（Component）
  組件是構(gòu)成微服務(wù)應(yīng)用的基本單元。一個(gè)應(yīng)用中可以包括多個(gè)組件，最佳的實(shí)踐方案是一個(gè)應(yīng)用中包括一個(gè)主組件（核心業(yè)務(wù)）和附屬組件（強(qiáng)依賴或獨(dú)享的中間件，運(yùn)維組件等）。KubeVela 內(nèi)置支持多種類(lèi)型的組件交付，包括 Helm Chart、容器鏡像、CUE 模塊、Terraform 模塊等。同時(shí)也允許平臺(tái)管理員以 CUE 語(yǔ)言的形式定制其它任意類(lèi)型的組件。
• 運(yùn)維特征（Trait）
  運(yùn)維特征是可以隨時(shí)綁定給待部署組件的模塊化、可拔插的運(yùn)維能力，比如：副本數(shù)調(diào)整、數(shù)據(jù)持久化、設(shè)置網(wǎng)關(guān)策略、自動(dòng)設(shè)置 DNS 解析等。用戶可以從社區(qū)獲取成熟的能力，也可以自行定義。
• 工作流（Workflow）
  工作流由多個(gè)步驟組成，允許用戶自定義應(yīng)用在某個(gè)環(huán)境的交付過(guò)程。典型的工作流步驟包括人工審核、數(shù)據(jù)傳遞、多集群發(fā)布、通知等。
• 應(yīng)用策略（Policy）
  應(yīng)用策略負(fù)責(zé)定義指定應(yīng)用交付過(guò)程中的策略，比如多集群部署的差異化配置、安全組策略、防火墻規(guī)則等。

整體定義如下所示：

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: <應(yīng)用名稱>
spec:
  components:
    - name: <組件名稱1>
      type: <組件類(lèi)型1>
      properties: <組件參數(shù)>
      traits:
        - type: <運(yùn)維特征類(lèi)型1>
          properties: <運(yùn)維特征類(lèi)型>
        - type: <運(yùn)維特征類(lèi)型2>
          properties: <運(yùn)維特征類(lèi)型>
    - name: <組件名稱2>
      type: <組件類(lèi)型2>
      properties: <組件參數(shù)>
  policies:
    - name: <應(yīng)用策略名稱>
      type: <應(yīng)用策略類(lèi)型>
      properties: <應(yīng)用策略參數(shù)>
  workflow:
    - name: <工作流節(jié)點(diǎn)名稱>
      type: <工作流節(jié)點(diǎn)類(lèi)型>
      properties: <工作流節(jié)點(diǎn)參數(shù)>

無(wú)論待交付的組件是 Helm Chart 還是云數(shù)據(jù)庫(kù)，目標(biāo)基礎(chǔ)設(shè)施是 Kubernetes 集群還是云平臺(tái)，KubeVela 都通過(guò) Application 這樣一個(gè)統(tǒng)一的、上層的交付描述文件來(lái)同用戶交互，不會(huì)泄露任何復(fù)雜的底層基礎(chǔ)設(shè)施細(xì)節(jié)，真正做到讓用戶完全專(zhuān)注于應(yīng)用研發(fā)和交付本身。

KubeVela

在實(shí)際使用時(shí)，用戶通過(guò)上述 Application 對(duì)象來(lái)引用預(yù)置的組件、運(yùn)維特征、應(yīng)用策略、以及工作流節(jié)點(diǎn)模塊，填寫(xiě)這些模塊暴露的用戶參數(shù)即可完成一次對(duì)應(yīng)用交付的建模。

當(dāng)然上面提到的幾個(gè)類(lèi)型背后都是由一組稱為模塊定義（Definitions）的可編程模塊來(lái)提供具體功能。KubeVela 會(huì)像膠水一樣基于 K8s API 定義基礎(chǔ)設(shè)施定義的抽象并將不同的能力組合起來(lái)。

將定義的 OAM 模塊和背后的 K8s CRD 控制器結(jié)合起來(lái)就可以形成 KubeVela 的 Addon 插件，社區(qū)已經(jīng)有一個(gè)完善的且在不斷擴(kuò)大的插件市場(chǎng)，比如  terraform 插件提供了云資源的供給，fluxcd 插件提供了 GitOps 能力等等。我們可以自己根據(jù)需求開(kāi)發(fā)插件，類(lèi)似于 Helm 可以提供一個(gè)插件倉(cāng)庫(kù)來(lái)發(fā)現(xiàn)和分發(fā)插件。

KubeVela 架構(gòu)

KubeVela 的整體架構(gòu)如下所示：

KubeVela 架構(gòu)

KubeVela 是一個(gè)的應(yīng)用交付與管理控制平面，它架在 Kubernetes 集群、云平臺(tái)等基礎(chǔ)設(shè)施之上，通過(guò) OAM 來(lái)對(duì)組件、云服務(wù)、運(yùn)維能力、交付工作流進(jìn)行統(tǒng)一的編排和交付。KubeVela 這種與基礎(chǔ)設(shè)施本身完全解耦的設(shè)計(jì)，很容易就能幫助你面向混合云/多云/多集群基礎(chǔ)設(shè)施進(jìn)行應(yīng)用交付與管理。

而為了能夠同任何 CI 流水線或者 GitOps 工具無(wú)縫集成，KubeVela 的 API 被設(shè)計(jì)為是聲明式、完全以應(yīng)用為中心的，它包括：

• 幫助用戶定義應(yīng)用交付計(jì)劃的 Application 對(duì)象
• 幫助平臺(tái)管理員通過(guò) CUE 語(yǔ)言定義平臺(tái)能力和抽象的 X-Definition 對(duì)象，比如 ComponentDefinition、TraitDefinition 等。

在具體實(shí)現(xiàn)上，KubeVela 依賴一個(gè)獨(dú)立的 Kubernetes 集群來(lái)運(yùn)行。具體來(lái)說(shuō)，KubeVela 主要由如下幾個(gè)部分組成:

• KubeVela 核心控制器：為整個(gè)系統(tǒng)提供核心控制邏輯，完成諸如編排應(yīng)用和工作流、修訂版本快照、垃圾回收等等基礎(chǔ)邏輯。
• Cluster Gateway 控制器：提供統(tǒng)一的多集群訪問(wèn)接口和操作。
• 插件體系：注冊(cè)和管理 KubeVela 的擴(kuò)展功能，包括 CRD 控制器和相關(guān)模塊定義。例如，下面列出了幾個(gè)常用的插件：

• VelaUX 插件是 KubeVela 的 Web UI。 此外，它在架構(gòu)中更像是一個(gè)功能齊全的 “應(yīng)用交付平臺(tái)”，將業(yè)務(wù)邏輯耦合在起特定的 API 中，并為不了解 k8s 的業(yè)務(wù)開(kāi)發(fā)者提供開(kāi)箱即用的平臺(tái)體驗(yàn)。
• Workflow 插件是一個(gè)獨(dú)立的工作流引擎，可以作為統(tǒng)一的 Pipeline 運(yùn)行以部署多個(gè)應(yīng)用程序或其他操作。與傳統(tǒng) Pipeline 相比，它主要使用 CUE 驅(qū)動(dòng)基于 IaC 的 API，而不是每一步都運(yùn)行容器（或 pod）。 它與 KubeVela 核心控制器的應(yīng)用工作流使用相同的機(jī)制。
• Vela Prism 插件是 KubeVela 的擴(kuò)展 API 服務(wù)器，基于 Kubernetes Aggregated API 機(jī)制構(gòu)建。它可以將諸如 Grafana 創(chuàng)建儀表盤(pán)等第三方服務(wù) API 映射為 Kubernetes API，方便用戶將第三方資源作為 Kubernetes 原生資源進(jìn)行 IaC 化管理。
• Terraform 插件允許用戶使用 Terraform 通過(guò) Kubernetes 自定義資源管理云資源。
• 此外，KubeVela 有一個(gè)不斷增長(zhǎng)的插件市場(chǎng)，其中已經(jīng)包含 50 多個(gè)用于集成的社區(qū)插件，包括 ArgoCD、FluxCD、Backstage、OpenKruise、Dapr、Crossplane、Terraform、OpenYurt 等等。

• 如果你還沒(méi)有任何 Kubernetes 集群，構(gòu)建在 k3s 和 k3d 之上的 VelaD 工具可以幫助你一鍵啟動(dòng)所有這些東西。它將 KubeVela 與 Kubernetes 控制平面集成在一起，這對(duì)于構(gòu)建開(kāi)發(fā)/測(cè)試環(huán)境非常有幫助。

還有一個(gè)非常重要的點(diǎn)是 KubeVela 是可編程的?，F(xiàn)實(shí)世界中的應(yīng)用交付，往往是一個(gè)比較復(fù)雜的過(guò)程。哪怕是一個(gè)比較通用的交付流程，也會(huì)因?yàn)閳?chǎng)景、環(huán)境、用戶甚至團(tuán)隊(duì)的不同而千差萬(wàn)別。所以 KubeVela 從第一天起就采用了一種可編程式的方法來(lái)實(shí)現(xiàn)它的交付模型，這使得 KubeVela 可以以前所未有的靈活度適配到你的應(yīng)用交付場(chǎng)景中。

KubeVela 安裝

如果你沒(méi)有 K8s 環(huán)境，可以選擇使用 VelaD 來(lái)獨(dú)立安裝 KubeVela。它是一個(gè)命令行工具，將 KubeVela 最小安裝以及使用 VelaUX 的一切依賴打包為一個(gè)可執(zhí)行文件，VelaD 會(huì)集成了 K3s 和 k3d 用于自動(dòng)化管理 Kubernetes 集群。

我們這里當(dāng)然選擇基于先有的 K8s 集群來(lái)安裝 KubeVela。要求集群版本 >= v1.19 && <= v1.26。

首先需要安裝 KubeVela 命令行工具，KubeVela CLI 提供了常用的集群和應(yīng)用管理能力，直接使用下面的命令即可安裝：

curl -fsSl https://kubevela.io/script/install.sh | bash

安裝完成后，可以通過(guò) vela version 命令查看版本信息：

$ vela version
CLI Version: 1.9.6
Core Version:
GitRevision: git-9c57c098
GolangVersion: go1.19.12

然后我們可以使用如下命令來(lái)安裝 KubeVela 控制平面：

vela install

安裝完成后，會(huì)創(chuàng)建一個(gè) vela-system 的命名空間，對(duì)應(yīng)的 Pod 列表如下所示：

$ kubectl get pods -n vela-system
NAME                                                        READY   STATUS      RESTARTS   AGE
kubevela-cluster-gateway-b689d74dc-mtzrh                    1/1     Running     0          134m
kubevela-vela-core-85fd59d846-49q22                         1/1     Running     0          134m
kubevela-vela-core-admission-patch-8x9lv                    0/1     Completed   0          131m
kubevela-vela-core-cluster-gateway-tls-secret-patch-xjcw9   0/1     Completed   0          129m

當(dāng)然如果你習(xí)慣使用 Helm，也可以通過(guò)如下 Helm 命令完成 VelaCore 的安裝和升級(jí)：

helm repo add kubevela https://charts.kubevela.net/core
helm repo update
helm upgrade --install --create-namespace -n vela-system kubevela kubevela/vela-core --wait

上面的只是安裝了 KubeVela 控制平面，我們一般情況下也會(huì)安裝 VelaUX，它是 KubeVela 的 UI 控制臺(tái)，可以通過(guò)瀏覽器訪問(wèn)它，當(dāng)然你也可以不安裝，這是可選的。

要安裝也非常簡(jiǎn)單，只需要執(zhí)行下面的命令啟用 velaux 插件即可：

vela addon enable velaux

VelaUX 需要認(rèn)證訪問(wèn)，默認(rèn)的用戶名是 admin，默認(rèn)密碼是 VelaUX12345。請(qǐng)務(wù)必在第一次登錄之后重新設(shè)置和保管好你的新密碼。

另外默認(rèn)情況下，VelaUX 沒(méi)有暴露任何端口。端口轉(zhuǎn)發(fā)會(huì)以代理的方式允許你通過(guò)本地端口來(lái)訪問(wèn) VelaUX 控制臺(tái)。

vela port-forward addon-velaux -n vela-system

選擇 > local | velaux | velaux 來(lái)啟用端口轉(zhuǎn)發(fā)。

VelaUX 控制臺(tái)插件支持三種和 Kubernetes 服務(wù)一樣的服務(wù)訪問(wèn)方式，它們是：ClusterIP、NodePort 以及 LoadBalancer，默認(rèn)的服務(wù)訪問(wèn)方式為 ClusterIP。我們可以用下面的方式來(lái)改變 VelaUX 控制臺(tái)的訪問(wèn)方式

vela addon enable velaux serviceType=LoadBalancer
# 或者
vela addon enable velaux serviceType=NodePort

一旦服務(wù)訪問(wèn)方式指定為 LoadBalancer 或者 NodePort，你可以通過(guò)執(zhí)行 vela status來(lái)獲取訪問(wèn)地址：

vela status addon-velaux -n vela-system --endpoint

期望得到的輸出如下：

+----------------------------+----------------------+
|  REF(KIND/NAMESPACE/NAME)  |       ENDPOINT       |
+----------------------------+----------------------+
| Service/vela-system/velaux | http:// |
+----------------------------+----------------------+

如果你集群中擁有可用的 ingress 和域名，那么你可以按照下面的方式給你的 VelaUX 在部署過(guò)程中指定一個(gè)域名。

$ vela addon enable velaux domain=vela.k8s.local
Addon velaux enabled successfully.
Please access addon-velaux from the following endpoints:
+---------+---------------+-----------------------------------+--------------------------------+-------+
| CLUSTER |   COMPONENT   |     REF(KIND/NAMESPACE/NAME)      |            ENDPOINT            | INNER |
+---------+---------------+-----------------------------------+--------------------------------+-------+
| local   | velaux-server | Service/vela-system/velaux-server | velaux-server.vela-system:8000 | true  |
| local   | velaux-server | Ingress/vela-system/velaux-server | http://vela.k8s.local          | false |
+---------+---------------+-----------------------------------+--------------------------------+-------+
    To open the dashboard directly by port-forward:

    vela port-forward -n vela-system addon-velaux 8000:8000

    Please refer to https://kubevela.io/docs/reference/addons/velaux for more VelaUX addon installation and visiting method.

此外 VelaUX 支持 Kubernetes 和 MongoDB 作為其數(shù)據(jù)庫(kù)。默認(rèn)數(shù)據(jù)庫(kù)為 Kubernetes，我們強(qiáng)烈建議你通過(guò)使用 MongoDB 來(lái)增強(qiáng)你的生產(chǎn)環(huán)境使用體驗(yàn)。

vela addon enable velaux dbType=mongodb dbURL=mongodb://:@

VelaUX

現(xiàn)在我們可以通過(guò) http://vela.k8s.local 來(lái)訪問(wèn) VelaUX 控制臺(tái)了，第一次訪問(wèn)可以配置管理員賬號(hào)信息：

vela ui

VelaUX 是 KubeVela 的插件，它是一個(gè)企業(yè)可以開(kāi)箱即用的云原生應(yīng)用交付和管理平臺(tái)。與此同時(shí)，也加入了一些企業(yè)使用中需要的概念。

VelaUX

項(xiàng)目（Project）

項(xiàng)目作為在 KubeVela 平臺(tái)組織人員和資源的業(yè)務(wù)承載，項(xiàng)目中可以設(shè)定成員、權(quán)限、應(yīng)用和分配環(huán)境。在項(xiàng)目維度集成外部代碼庫(kù)、制品庫(kù)，呈現(xiàn)完整 CI/CD Pipeline；集成外部需求管理平臺(tái)，呈現(xiàn)項(xiàng)目需求管理；集成微服務(wù)治理，提供多環(huán)境業(yè)務(wù)聯(lián)調(diào)和統(tǒng)一治理能力。項(xiàng)目提供了業(yè)務(wù)級(jí)的資源隔離能力。

默認(rèn)情況下，VelaUX 會(huì)創(chuàng)建一個(gè)名為 default 的項(xiàng)目，你可以在 項(xiàng)目管理 中創(chuàng)建更多的項(xiàng)目。

項(xiàng)目

環(huán)境（Environment）

環(huán)境指通常意義的開(kāi)發(fā)、測(cè)試、生產(chǎn)的環(huán)境業(yè)務(wù)描述，它可以包括多個(gè)交付目標(biāo)。環(huán)境協(xié)調(diào)上層應(yīng)用和底層基礎(chǔ)設(shè)施的匹配關(guān)系，不同的環(huán)境對(duì)應(yīng)管控集群的不同 Kubernetes Namespace。處在同一個(gè)環(huán)境中的應(yīng)用才能具備內(nèi)部互訪和資源共享能力。

同樣默認(rèn)情況下，VelaUX 會(huì)創(chuàng)建一個(gè)名為 default 的環(huán)境，你可以在 環(huán)境管理 中創(chuàng)建更多的環(huán)境。

環(huán)境

應(yīng)用可綁定多個(gè)環(huán)境進(jìn)行發(fā)布，對(duì)于每一個(gè)環(huán)境可設(shè)置環(huán)境級(jí)部署差異。

交付目標(biāo)（Target）

交付目標(biāo)用于描述應(yīng)用的相關(guān)資源實(shí)際部署的物理空間，對(duì)應(yīng) Kubernetes 集群或者云的區(qū)域（Region）和專(zhuān)有網(wǎng)絡(luò)（VPC）。對(duì)于普通應(yīng)用，組件渲染生成的資源會(huì)在交付目標(biāo)指定的 Kubernetes 集群中創(chuàng)建（可以精確到指定集群的 Namespace）；對(duì)于云服務(wù)，資源創(chuàng)建時(shí)會(huì)根據(jù)交付目標(biāo)中指定的云廠商的參數(shù)創(chuàng)建到對(duì)應(yīng)的區(qū)域和專(zhuān)有網(wǎng)絡(luò)中，然后將生成的云資源信息分發(fā)到交付目標(biāo)指定的 Kubernetes 集群中。單個(gè)環(huán)境可關(guān)聯(lián)多個(gè)交付目標(biāo)，代表該環(huán)境需要多集群交付。單個(gè)交付目標(biāo)只能對(duì)應(yīng)一個(gè)環(huán)境。

交付目標(biāo)

應(yīng)用（Application）

應(yīng)用是定義了一個(gè)微服務(wù)業(yè)務(wù)單元所包括的制品（二進(jìn)制、Docker 鏡像、Helm Chart...）或云服務(wù)的交付和管理需求，它由組件、運(yùn)維特征、工作流、應(yīng)用策略四部分組成，應(yīng)用的生命周期操作包括：

• 創(chuàng)建(Create) 應(yīng)用是創(chuàng)建元信息，并不會(huì)實(shí)際部署和運(yùn)行資源。
• 部署(Deploy) 指執(zhí)行指定的工作流， 將應(yīng)用在某一個(gè)環(huán)境中完成實(shí)例化。
• 回收(Recycle) 刪除應(yīng)用部署到某一個(gè)環(huán)境的實(shí)例，回收其占用的資源。
• 刪除應(yīng)用會(huì)刪除元數(shù)據(jù)，前提是應(yīng)用實(shí)例已經(jīng)完全被回收后才能刪除。

VelaUX 應(yīng)用中其他概念均與 KubeVela 控制器中的概念完全一致。

第一個(gè) KubeVela 應(yīng)用

上面我們已經(jīng)安裝好了 KubeVela，接下來(lái)我們就可以開(kāi)始使用 KubeVela 來(lái)部署我們的第一個(gè)應(yīng)用了。

下面我們定義了一個(gè)簡(jiǎn)單的 OAM 應(yīng)用，它包括了一個(gè)無(wú)狀態(tài)服務(wù)組件和運(yùn)維特征，然后定義了三個(gè)部署策略和工作流步驟。此應(yīng)用描述的含義是將一個(gè)服務(wù)部署到兩個(gè)目標(biāo)命名空間，并且在第一個(gè)目標(biāo)部署完成后等待人工審核后部署到第二個(gè)目標(biāo)，且在第二個(gè)目標(biāo)時(shí)部署 2 個(gè)實(shí)例。

# first-vela-app.yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: first-vela-app
spec:
  components:
    - name: express-server
      type: webservice # webservice 是一個(gè)內(nèi)置的組件類(lèi)型
      properties: # 組件參數(shù)
        image: oamdev/hello-world
        ports:
          - port: 8000
            expose: true
      traits: # 組件運(yùn)維特征
        - type: scaler
          properties:
            replicas: 1
  policies:
    - name: target-default
      type: topology # topology 是一個(gè)內(nèi)置的應(yīng)用策略類(lèi)型，它可以將應(yīng)用部署到多個(gè)目標(biāo)
      properties:
        clusters: ["local"] # local 集群即 Kubevela 所在的集群
        namespace: "default"
    - name: target-prod
      type: topology
      properties:
        clusters: ["local"]
        namespace: "prod" # 此命名空間需要在應(yīng)用部署前完成創(chuàng)建
    - name: deploy-ha
      type: override # override 是一個(gè)內(nèi)置的應(yīng)用策略類(lèi)型，它可以覆蓋組件的參數(shù)
      properties:
        components:
          - type: webservice
            traits:
              - type: scaler
                properties:
                  replicas: 2
  workflow: # 應(yīng)用工作流
    steps:
      - name: deploy2default
        type: deploy # deploy 是一個(gè)內(nèi)置的工作流類(lèi)型，它可以將應(yīng)用部署到指定的目標(biāo)
        properties:
          policies: ["target-default"]
      - name: manual-approval
        type: suspend # suspend 是一個(gè)內(nèi)置的工作流類(lèi)型，它可以暫停工作流的執(zhí)行
      - name: deploy2prod
        type: deploy
        properties:
          policies: ["target-prod", "deploy-ha"]

要先創(chuàng)建 prod 命名空間，可以使用 vela env init 命令，當(dāng)然也可以直接使用 kubectl create ns 命令：

# 此命令用于在管控集群創(chuàng)建命名空間
vela env init prod --namespace prod

接下來(lái)就可以啟動(dòng)我們的第一個(gè) KubeVela 應(yīng)用了:

$ vela up -f first-vela-app.yaml
Applying an application in vela K8s object format...
 App has been deployed 
    Port forward: vela port-forward first-vela-app -n prod
             SSH: vela exec first-vela-app -n prod
         Logging: vela logs first-vela-app -n prod
      App status: vela status first-vela-app -n prod
        Endpoint: vela status first-vela-app -n prod --endpoint
Application prod/first-vela-app applied.

vela up 命令會(huì)將上面定義的 Application 對(duì)象根據(jù)我們的描述翻譯渲染成對(duì)應(yīng)的 K8s 資源對(duì)象，部署完成后可以使用 vela 的相關(guān)命令來(lái)了解該應(yīng)用的相關(guān)信息。

首先可以使用 vela status 命令來(lái)查看下應(yīng)用的當(dāng)前狀態(tài)。由于上面應(yīng)用定義的 Workflow 是先將應(yīng)用部署到 local 集群的 default 命名空間中，然后進(jìn)入第二個(gè)步驟的時(shí)候是一個(gè) suspend 類(lèi)型的工作流，所以正常情況下應(yīng)用完成第一個(gè)目標(biāo)部署后會(huì)進(jìn)入暫停狀態(tài)（左側(cè)的 workflowSuspending 狀態(tài)）。

$ vela status first-vela-app -n prod
About:

  Name:         first-vela-app
  Namespace:    prod
  Created at:   2023-10-10 16:50:17 +0800 CST
  Status:       workflowSuspending

Workflow:

  mode: StepByStep-DAG
  finished: false
  Suspend: true
  Terminated: false
  Steps
  - id: kkotnerd76
    name: deploy2default
    type: deploy
    phase: succeeded
  - id: axtmf24jcx
    name: manual-approval
    type: suspend
    phase: suspending
    message: Suspended by field suspend

Services:

  - Name: express-server
    Cluster: local  Namespace: default
    Type: webservice
    Healthy Ready:1/1
    Traits:
       scaler

要繼續(xù)工作流，則需要進(jìn)行人工審核（左側(cè)顯示的第二個(gè)步驟），批準(zhǔn)應(yīng)用進(jìn)入第二個(gè)目標(biāo)部署，直接使用下面的命令即可：

vela workflow resume first-vela-app

當(dāng)然在 VelaxUX 控制臺(tái)中也可以看到應(yīng)用的狀態(tài)，也可以在控制臺(tái)中直接進(jìn)行人工審核操作。

VelaxUX 審批

審批通過(guò)后會(huì)執(zhí)行第三個(gè)步驟 deploy2prod，應(yīng)用 target-prod、deploy-ha 這兩個(gè)策略了。

經(jīng)過(guò)上面的整個(gè)工作流過(guò)后，最終應(yīng)用會(huì)在 default 命名空間下面創(chuàng)建一個(gè) Pod，在 prod 命名空間下面創(chuàng)建兩個(gè)副本的 Pod。

$ kubectl get pods -n prod
NAME                              READY   STATUS    RESTARTS   AGE
express-server-5447567596-jcpnh   1/1     Running   0          72s
express-server-5447567596-lgqdz   1/1     Running   0          72s
$ kubectl get pods
NAME                                     READY   STATUS    RESTARTS         AGE
express-server-5447567596-clbgb          1/1     Running   0                7m36s

在 VelaUX 控制臺(tái)中也可以看到應(yīng)用的狀態(tài)：

VelaUX 應(yīng)用

到這里就完成了我們的第一個(gè) KubeVela 應(yīng)用的部署流程。

分享題目：KubeVela基礎(chǔ)入門(mén)，有你想知道的一切
本文來(lái)源：http://fisionsoft.com.cn/article/dhpoooc.html