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

OAM 簡介

OAM（Open Application Model） 是阿里巴巴和微軟共同開源的云原生應用規范模型，OAM 的本質是根據軟件設計的興趣點分離原則對負責的 DevOps 流程的高度抽象和封裝，一個以應用為中心的 K8s API 分層，這種模型旨在定義云原生應用的標準。

OAM

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

• 開放（Open）：支持異構的平臺、容器運行時、調度系統、云供應商、硬件配置等，總之與底層無關
• 應用（Application）：云原生應用
• 模型（Model）：定義標準，以使其與底層平臺無關

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

現階段應用管理的主要面臨兩個挑戰：

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

總體而言，面臨的主要挑戰就是：如何基于 Kubernetes 提供真正意義上的應用管理平臺，讓研發和運維只需關注到應用本身。

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

k8s yaml

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

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

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

該方式針對簡單無狀態應用非常有效，精簡 API 可以大大降低 K8s 的門檻。但是當出現大規模業務后，就會遇到很多復雜的應用，這個時候就會發現該 PaaS 應用平臺能力不夠了。比如 ZK 多實例選主、主從切換這些邏輯，在這五個字段里就很難描述了。因為屏蔽大量字段的方式會限制基礎設施本身的能力，而 K8s 的能力是非常強大而靈活的，所以我們不可能為了簡化而放棄掉 K8s 本身強大的能力。

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

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

除了研發側的問題之外，在運維側同樣也會有很多挑戰。

K8s 的 CRD Operator 機制非常靈活而強大，不光是復雜應用可以通過編寫 CRD Operator 實現，運維能力當然也可以通過 Operator 來擴展，比如灰度發布、流量管理、彈性擴縮容等等。

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

如果再深入思考下就知道我們需要一個統一的模型來協商并管理這些復雜的擴展能力。

云原生應用有一個很大的特點，那就是它往往會依賴云上的資源，包括數據庫、網絡、負載均衡、緩存等一系列資源。

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

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

而且事實上很多公司和團隊也在根據自身業務需要進行定義，比如 Pinterest 定義的應用規范如下所示：

Pinterest CRD

應用定義實際上是應用交付/分發不可或缺的部分，所以我們可以思考下是否可以定義足夠開放的、可復用的應用模型呢？

一個應用定義需要容易上手，但又不失靈活性，更不能是一個黑盒。應用定義同樣需要跟開源生態緊密結合，沒有生態的應用定義注定是沒有未來的，自然也很難持續的迭代和演進。

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

前面我們說的各種問題，歸根結底在于 K8s 的 All in One API 是為平臺提供者設計的，我們不能像下圖左側顯示的一樣，讓應用的研發、運維跟 K8s 團隊一樣面對這一團 API。

All in One API

一個合理的應用模型應該具有區分使用者角色的分層結構，同時將運維能力模塊化的封裝。讓不同的角色使用不同的 API，如上圖右側部分。

OAM 模型定義

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

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

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

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

OAM模型

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

KubeVela 簡介

KubeVela 是 OAM 規范（實際上 OAM 規范會滯后于 KubeVela 中使用的規范）的一個實現，是一個開箱即用的現代化應用交付與管理平臺，它使得應用在面向混合云環境中的交付更簡單、快捷。使用 KubeVela 的軟件開發團隊，可以按需使用云原生能力構建應用，隨著團隊規模的發展、業務場景的變化擴展其功能，一次構建應用，隨處運行。

KubeVela

核心功能

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

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

關注點分離

關注點分離這個屬于 KubeVela 的核心理念，它是 KubeVela 的設計哲學，也是 KubeVela 與眾不同的地方。KubeVela 的用戶天然分為兩種角色，由公司的兩個團隊（或個人）承擔。

• 平臺團隊
  由平臺工程師完成，他們需要準備應用部署環境，維護穩定可靠的基礎設施功能（如 mysql operator），并將基礎設施能力作為 KubeVela 模塊定義注冊到集群中。他們需要具備豐富的基礎設施經驗。
• 最終用戶
  最終用戶即業務應用的開發者，使用平臺的過程中首先選擇部署環境，然后挑選能力模塊，填寫業務參數并組裝成 KubeVela 應用。他們無需關心基礎設施細節。

關注點分離

核心概念

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

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

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

整體定義如下所示：

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: <應用名稱>
spec:
  components:
    - name: <組件名稱1>
      type: <組件類型1>
      properties: <組件參數>
      traits:
        - type: <運維特征類型1>
          properties: <運維特征類型>
        - type: <運維特征類型2>
          properties: <運維特征類型>
    - name: <組件名稱2>
      type: <組件類型2>
      properties: <組件參數>
  policies:
    - name: <應用策略名稱>
      type: <應用策略類型>
      properties: <應用策略參數>
  workflow:
    - name: <工作流節點名稱>
      type: <工作流節點類型>
      properties: <工作流節點參數>

無論待交付的組件是 Helm Chart 還是云數據庫，目標基礎設施是 Kubernetes 集群還是云平臺，KubeVela 都通過 Application 這樣一個統一的、上層的交付描述文件來同用戶交互，不會泄露任何復雜的底層基礎設施細節，真正做到讓用戶完全專注于應用研發和交付本身。

KubeVela

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

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

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

KubeVela 架構

KubeVela 的整體架構如下所示：

KubeVela 架構

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

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

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

在具體實現上，KubeVela 依賴一個獨立的 Kubernetes 集群來運行。具體來說，KubeVela 主要由如下幾個部分組成:

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

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

• 如果你還沒有任何 Kubernetes 集群，構建在 k3s 和 k3d 之上的 VelaD 工具可以幫助你一鍵啟動所有這些東西。它將 KubeVela 與 Kubernetes 控制平面集成在一起，這對于構建開發/測試環境非常有幫助。

還有一個非常重要的點是 KubeVela 是可編程的。現實世界中的應用交付，往往是一個比較復雜的過程。哪怕是一個比較通用的交付流程，也會因為場景、環境、用戶甚至團隊的不同而千差萬別。所以 KubeVela 從第一天起就采用了一種可編程式的方法來實現它的交付模型，這使得 KubeVela 可以以前所未有的靈活度適配到你的應用交付場景中。

KubeVela 安裝

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

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

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

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

安裝完成后，會創建一個 vela-system 的命名空間，對應的 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

當然如果你習慣使用 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 控制臺，可以通過瀏覽器訪問它，當然你也可以不安裝，這是可選的。

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

vela addon enable velaux

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

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

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

選擇 > local | velaux | velaux 來啟用端口轉發。

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

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

一旦服務訪問方式指定為 LoadBalancer 或者 NodePort，你可以通過執行 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 作為其數據庫。默認數據庫為 Kubernetes，我們強烈建議你通過使用 MongoDB 來增強你的生產環境使用體驗。

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

VelaUX

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

vela ui

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

VelaUX

項目（Project）

項目作為在 KubeVela 平臺組織人員和資源的業務承載，項目中可以設定成員、權限、應用和分配環境。在項目維度集成外部代碼庫、制品庫，呈現完整 CI/CD Pipeline；集成外部需求管理平臺，呈現項目需求管理；集成微服務治理，提供多環境業務聯調和統一治理能力。項目提供了業務級的資源隔離能力。

默認情況下，VelaUX 會創建一個名為 default 的項目，你可以在 項目管理 中創建更多的項目。

項目

環境（Environment）

環境指通常意義的開發、測試、生產的環境業務描述，它可以包括多個交付目標。環境協調上層應用和底層基礎設施的匹配關系，不同的環境對應管控集群的不同 Kubernetes Namespace。處在同一個環境中的應用才能具備內部互訪和資源共享能力。

同樣默認情況下，VelaUX 會創建一個名為 default 的環境，你可以在 環境管理 中創建更多的環境。

環境

應用可綁定多個環境進行發布，對于每一個環境可設置環境級部署差異。

交付目標（Target）

交付目標用于描述應用的相關資源實際部署的物理空間，對應 Kubernetes 集群或者云的區域（Region）和專有網絡（VPC）。對于普通應用，組件渲染生成的資源會在交付目標指定的 Kubernetes 集群中創建（可以精確到指定集群的 Namespace）；對于云服務，資源創建時會根據交付目標中指定的云廠商的參數創建到對應的區域和專有網絡中，然后將生成的云資源信息分發到交付目標指定的 Kubernetes 集群中。單個環境可關聯多個交付目標，代表該環境需要多集群交付。單個交付目標只能對應一個環境。

交付目標

應用（Application）

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

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

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

第一個 KubeVela 應用

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

下面我們定義了一個簡單的 OAM 應用，它包括了一個無狀態服務組件和運維特征，然后定義了三個部署策略和工作流步驟。此應用描述的含義是將一個服務部署到兩個目標命名空間，并且在第一個目標部署完成后等待人工審核后部署到第二個目標，且在第二個目標時部署 2 個實例。

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

要先創建 prod 命名空間，可以使用 vela env init 命令，當然也可以直接使用 kubectl create ns 命令：

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

接下來就可以啟動我們的第一個 KubeVela 應用了:

$ 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 對象根據我們的描述翻譯渲染成對應的 K8s 資源對象，部署完成后可以使用 vela 的相關命令來了解該應用的相關信息。

首先可以使用 vela status 命令來查看下應用的當前狀態。由于上面應用定義的 Workflow 是先將應用部署到 local 集群的 default 命名空間中，然后進入第二個步驟的時候是一個 suspend 類型的工作流，所以正常情況下應用完成第一個目標部署后會進入暫停狀態（左側的 workflowSuspending 狀態）。

$ 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

要繼續工作流，則需要進行人工審核（左側顯示的第二個步驟），批準應用進入第二個目標部署，直接使用下面的命令即可：

vela workflow resume first-vela-app

當然在 VelaxUX 控制臺中也可以看到應用的狀態，也可以在控制臺中直接進行人工審核操作。

VelaxUX 審批

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

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

VelaUX 應用

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