KubeVela 基礎(chǔ)入門

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

OAM 簡介

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

OAM

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

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

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

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

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

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

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

k8s yaml

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

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

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

    

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

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

Operator是啥

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

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

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

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

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

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

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

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

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

Pinterest CRD

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

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

這也是為什么我們需要 OAM 的深層次的原因！！！

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

All in One API

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

OAM 模型定義

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

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

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

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

OAM模型

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

KubeVela 簡介

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

KubeVela

核心功能

KubeVela 具有以下幾個核心功能：

• 應(yīng)用部署即代碼（Deployment as Code），完整定義全交付流程

  使用 OAM 作為應(yīng)用交付的頂層抽象，這種方式使你可以用聲明式的方式描述應(yīng)用交付全流程，自動化的集成 CI/CD 及 GitOps 體系，通過  CUE  輕松擴(kuò)展或重新編寫你的交付過程。

• 天然支持企業(yè)級集成，安全、合規(guī)、可觀測性一應(yīng)俱全

  支持多集群認(rèn)證和授權(quán)并與 K8s RBAC 集成，還可以從社區(qū)的插件中心找到一系列開箱即用的平臺擴(kuò)展，包括多種用戶體系（LDAP 等）集成、多租戶權(quán)限控制、安全校驗(yàn)和掃描、應(yīng)用可觀測性等大量企業(yè)級能力。

• 面向多云多集群混合環(huán)境，豐富的應(yīng)用交付和管理能力

  原生支持豐富的多集群/混合環(huán)境持續(xù)交付策略，包括金絲雀、藍(lán)綠、多環(huán)境差異化配置等，同樣也支持跨環(huán)境交付，這些交付策略為你的分布式交付流程提供了充足的效率和安全保證。

• 輕量并且架構(gòu)高度可擴(kuò)展，滿足企業(yè)不同場景的定制化需求

  KubeVela 最小的部署模式僅需 1 個 pod （0.5 核 1G 內(nèi)存）就可以用于部署上千個應(yīng)用。其微內(nèi)核、高可擴(kuò)展的架構(gòu)可以輕松滿足你的擴(kuò)展和定制化需求，銜接企業(yè)內(nèi)部的權(quán)限體系、微服務(wù)、流量治理、配置管理、可觀測性等模塊。不僅如此，社區(qū)還有一個正在快速增長的插件市場可供你選擇和使用，你可以在這里貢獻(xiàn)、復(fù)用社區(qū)豐富的功能模塊。

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

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

• 平臺團(tuán)隊

  由平臺工程師完成，他們需要準(zhǔn)備應(yīng)用部署環(huán)境，維護(hù)穩(wěn)定可靠的基礎(chǔ)設(shè)施功能（如 mysql operator），并將基礎(chǔ)設(shè)施能力作為 KubeVela 模塊定義注冊到集群中。他們需要具備豐富的基礎(chǔ)設(shè)施經(jīng)驗(yàn)。

• 最終用戶

  最終用戶即業(yè)務(wù)應(yīng)用的開發(fā)者，使用平臺的過程中首先選擇部署環(huán)境，然后挑選能力模塊，填寫業(yè)務(wù)參數(shù)并組裝成 KubeVela 應(yīng)用。他們無需關(guān)心基礎(chǔ)設(shè)施細(xì)節(jié)。

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

核心概念

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

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

• 組件（Component）

  組件是構(gòu)成微服務(wù)應(yīng)用的基本單元。一個應(yīng)用中可以包括多個組件，最佳的實(shí)踐方案是一個應(yīng)用中包括一個主組件（核心業(yè)務(wù)）和附屬組件（強(qiáng)依賴或獨(dú)享的中間件，運(yùn)維組件等）。KubeVela 內(nèi)置支持多種類型的組件交付，包括 Helm Chart、容器鏡像、CUE 模塊、Terraform 模塊等。同時也允許平臺管理員以 CUE 語言的形式定制其它任意類型的組件。

• 運(yùn)維特征（Trait）

  運(yùn)維特征是可以隨時綁定給待部署組件的模塊化、可拔插的運(yùn)維能力，比如：副本數(shù)調(diào)整、數(shù)據(jù)持久化、設(shè)置網(wǎng)關(guān)策略、自動設(shè)置 DNS 解析等。用戶可以從社區(qū)獲取成熟的能力，也可以自行定義。

• 工作流（Workflow）

  工作流由多個步驟組成，允許用戶自定義應(yīng)用在某個環(huán)境的交付過程。典型的工作流步驟包括人工審核、數(shù)據(jù)傳遞、多集群發(fā)布、通知等。

• 應(yīng)用策略（Policy）

  應(yīng)用策略負(fù)責(zé)定義指定應(yīng)用交付過程中的策略，比如多集群部署的差異化配置、安全組策略、防火墻規(guī)則等。

整體定義如下所示：

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

    

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

KubeVela

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

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

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

KubeVela 架構(gòu)

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

KubeVela 架構(gòu)

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

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

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

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

• KubeVela 核心控制器：為整個系統(tǒng)提供核心控制邏輯，完成諸如編排應(yīng)用和工作流、修訂版本快照、垃圾回收等等基礎(chǔ)邏輯。
• Cluster Gateway 控制器：提供統(tǒng)一的多集群訪問接口和操作。
• 插件體系：注冊和管理 KubeVela 的擴(kuò)展功能，包括 CRD 控制器和相關(guān)模塊定義。例如，下面列出了幾個常用的插件：
  • VelaUX 插件是 KubeVela 的 Web UI。 此外，它在架構(gòu)中更像是一個功能齊全的 “應(yīng)用交付平臺”，將業(yè)務(wù)邏輯耦合在起特定的 API 中，并為不了解 k8s 的業(yè)務(wù)開發(fā)者提供開箱即用的平臺體驗(yàn)。
  • Workflow 插件是一個獨(dú)立的工作流引擎，可以作為統(tǒng)一的 Pipeline 運(yùn)行以部署多個應(yīng)用程序或其他操作。與傳統(tǒng) Pipeline 相比，它主要使用 CUE 驅(qū)動基于 IaC 的 API，而不是每一步都運(yùn)行容器（或 pod）。 它與 KubeVela 核心控制器的應(yīng)用工作流使用相同的機(jī)制。
  • Vela Prism 插件是 KubeVela 的擴(kuò)展 API 服務(wù)器，基于 Kubernetes Aggregated API 機(jī)制構(gòu)建。它可以將諸如 Grafana 創(chuàng)建儀表盤等第三方服務(wù) API 映射為 Kubernetes API，方便用戶將第三方資源作為 Kubernetes 原生資源進(jìn)行 IaC 化管理。
  • Terraform 插件允許用戶使用 Terraform 通過 Kubernetes 自定義資源管理云資源。
  • 此外，KubeVela 有一個不斷增長的插件市場，其中已經(jīng)包含 50 多個用于集成的社區(qū)插件，包括 ArgoCD、FluxCD、Backstage、OpenKruise、Dapr、Crossplane、Terraform、OpenYurt 等等。
• 如果你還沒有任何 Kubernetes 集群，構(gòu)建在 k3s 和 k3d 之上的 VelaD 工具可以幫助你一鍵啟動所有這些東西。它將 KubeVela 與 Kubernetes 控制平面集成在一起，這對于構(gòu)建開發(fā)/測試環(huán)境非常有幫助。

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

KubeVela 安裝

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

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

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

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

    

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

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

    

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

      
      vela install

    

安裝完成后，會創(chuàng)建一個 vela-system 的命名空間，對應(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，也可以通過如下 Helm 命令完成 VelaCore 的安裝和升級：

      
      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 控制平面，我們一般情況下也會安裝 VelaUX，它是 KubeVela 的 UI 控制臺，可以通過瀏覽器訪問它，當(dāng)然你也可以不安裝，這是可選的。

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

      
      vela addon enable velaux

    

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

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

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

    

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

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

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

    

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

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

    

期望得到的輸出如下：

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

    

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

      
      $ 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ù)庫。默認(rèn)數(shù)據(jù)庫為 Kubernetes，我們強(qiáng)烈建議你通過使用 MongoDB 來增強(qiáng)你的生產(chǎn)環(huán)境使用體驗(yàn)。

      
      vela addon enable velaux dbType=mongodb dbURL=mongodb://<MONGODB_USER>:<MONGODB_PASSWORD>@<MONGODB_URL>

    

VelaUX

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

vela ui

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

VelaUX

項目（Project）

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

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

項目

環(huán)境（Environment）

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

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

環(huán)境

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

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

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

交付目標(biāo)

應(yīng)用（Application）

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

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

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

第一個 KubeVela 應(yīng)用

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

下面我們定義了一個簡單的 OAM 應(yīng)用，它包括了一個無狀態(tài)服務(wù)組件和運(yùn)維特征，然后定義了三個部署策略和工作流步驟。此應(yīng)用描述的含義是將一個服務(wù)部署到兩個目標(biāo)命名空間，并且在第一個目標(biāo)部署完成后等待人工審核后部署到第二個目標(biāo)，且在第二個目標(biāo)時部署 2 個實(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 是一個內(nè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 是一個內(nèi)置的應(yīng)用策略類型，它可以將應(yīng)用部署到多個目標(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 是一個內(nèi)置的應(yīng)用策略類型，它可以覆蓋組件的參數(shù)
      properties:
        components:
          - type: webservice
            traits:
              - type: scaler
                properties:
                  replicas: 2
  workflow: # 應(yīng)用工作流
    steps:
      - name: deploy2default
        type: deploy # deploy 是一個內(nèi)置的工作流類型，它可以將應(yīng)用部署到指定的目標(biāo)
        properties:
          policies: ["target-default"]
      - name: manual-approval
        type: suspend # suspend 是一個內(nè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

    

接下來就可以啟動我們的第一個 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 命令會將上面定義的 Application 對象根據(jù)我們的描述翻譯渲染成對應(yīng)的 K8s 資源對象，部署完成后可以使用 vela 的相關(guān)命令來了解該應(yīng)用的相關(guān)信息。

首先可以使用 vela status 命令來查看下應(yīng)用的當(dāng)前狀態(tài)。由于上面應(yīng)用定義的 Workflow 是先將應(yīng)用部署到 local 集群的 default 命名空間中，然后進(jìn)入第二個步驟的時候是一個 suspend 類型的工作流，所以正常情況下應(yīng)用完成第一個目標(biāo)部署后會進(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è)顯示的第二個步驟），批準(zhǔn)應(yīng)用進(jìn)入第二個目標(biāo)部署，直接使用下面的命令即可：

      
      vela workflow resume first-vela-app

    

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

VelaxUX 審批

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

經(jīng)過上面的整個工作流過后，最終應(yīng)用會在 default 命名空間下面創(chuàng)建一個 Pod，在 prod 命名空間下面創(chuàng)建兩個副本的 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 控制臺中也可以看到應(yīng)用的狀態(tài)：

VelaUX 應(yīng)用

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