一、KubeVela 简介

KubeVela 是 OAM 规范（实际上 OAM 规范会滞后于 KubeVela 中使用的规范）的一个实现，是一个开箱即用的现代化应用交付与管理平台，它使得应用在面向混合云环境中的交付更简单、快捷。使用 KubeVela 的软件开发团队，可以按需使用云原生能力构建应用，随着团队规模的发展、业务场景的变化扩展其功能，一次构建应用，随处运行。

1.1、核心功能

KubeVela 具有以下几个核心功能：

• 应用部署即代码（Deployment as Code），完整定义全交付流程

  使用 OAM 作为应用交付的顶层抽象，这种方式使你可以用声明式的方式描述应用交付全流程，自动化的集成 CI/CD 及 GitOps 体系，通过  CUE  轻松扩展或重新编写你的交付过程。

• 天然支持企业级集成，安全、合规、可观测性一应俱全

  支持多集群认证和授权并与 K8s RBAC 集成，还可以从社区的插件中心找到一系列开箱即用的平台扩展，包括多种用户体系（LDAP 等）集成、多租户权限控制、安全校验和扫描、应用可观测性等大量企业级能力。

• 面向多云多集群混合环境，丰富的应用交付和管理能力

  原生支持丰富的多集群/混合环境持续交付策略，包括金丝雀、蓝绿、多环境差异化配置等，同样也支持跨环境交付，这些交付策略为你的分布式交付流程提供了充足的效率和安全保证。

• 轻量并且架构高度可扩展，满足企业不同场景的定制化需求

  KubeVela 最小的部署模式仅需 1 个 pod （0.5 核 1G 内存）就可以用于部署上千个应用。其微内核、高可扩展的架构可以轻松满足你的扩展和定制化需求，衔接企业内部的权限体系、微服务、流量治理、配置管理、可观测性等模块。不仅如此，社区还有一个正在快速增长的插件市场可供你选择和使用，你可以在这里贡献、复用社区丰富的功能模块。

1.2、关注点分离

关注点分离这个属于 KubeVela 的核心理念，它是 KubeVela 的设计哲学，也是 KubeVela 与众不同的地方。KubeVela 的用户天然分为两种角色，由公司的两个团队（或个人）承担。

• 平台团队

  由平台工程师完成，他们需要准备应用部署环境，维护稳定可靠的基础设施功能（如 mysql operator），并将基础设施能力作为 KubeVela 模块定义注册到集群中。他们需要具备丰富的基础设施经验。

• 最终用户

  最终用户即业务应用的开发者，使用平台的过程中首先选择部署环境，然后挑选能力模块，填写业务参数并组装成 KubeVela 应用。他们无需关心基础设施细节。

1.3、核心概念

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 这样一个统一的、上层的交付描述文件来同用户交互，不会泄露任何复杂的底层基础设施细节，真正做到让用户完全专注于应用研发和交付本身。

在实际使用时，用户通过上述 Application 对象来引用预置的组件、运维特征、应用策略、以及工作流节点模块，填写这些模块暴露的用户参数即可完成一次对应用交付的建模。

当然上面提到的几个类型背后都是由一组称为模块定义（Definitions）的可编程模块来提供具体功能。KubeVela 会像胶水一样基于 K8s API 定义基础设施定义的抽象并将不同的能力组合起来。

将定义的 OAM 模块和背后的 K8s CRD 控制器结合起来就可以形成 KubeVela 的 Addon 插件，社区已经有一个完善的且在不断扩大的插件市场，比如  terraform 插件提供了云资源的供给，fluxcd 插件提供了 GitOps 能力等等。我们可以自己根据需求开发插件，类似于 Helm 可以提供一个插件仓库来发现和分发插件。

1.4、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>@<MONGO

三、VelaUX

现在我们可以通过 http://vela.k8s.local 来访问 VelaUX 控制台了，第一次访问可以配置管理员账号信息：

VelaUX 是 KubeVela 的插件，它是一个企业可以开箱即用的云原生应用交付和管理平台。与此同时，也加入了一些企业使用中需要的概念。

3.1、项目（Project）

项目作为在 KubeVela 平台组织人员和资源的业务承载，项目中可以设定成员、权限、应用和分配环境。在项目维度集成外部代码库、制品库，呈现完整 CI/CD Pipeline；集成外部需求管理平台，呈现项目需求管理；集成微服务治理，提供多环境业务联调和统一治理能力。项目提供了业务级的资源隔离能力。

默认情况下，VelaUX 会创建一个名为 default 的项目，你可以在 项目管理 中创建更多的项目。

3.2、环境（Environment）

环境指通常意义的开发、测试、生产的环境业务描述，它可以包括多个交付目标。环境协调上层应用和底层基础设施的匹配关系，不同的环境对应管控集群的不同 Kubernetes Namespace。处在同一个环境中的应用才能具备内部互访和资源共享能力。

同样默认情况下，VelaUX 会创建一个名为 default 的环境，你可以在 环境管理 中创建更多的环境。

应用可绑定多个环境进行发布，对于每一个环境可设置环境级部署差异。

3.3、交付目标（Target）

交付目标用于描述应用的相关资源实际部署的物理空间，对应 Kubernetes 集群或者云的区域（Region）和专有网络（VPC）。对于普通应用，组件渲染生成的资源会在交付目标指定的 Kubernetes 集群中创建（可以精确到指定集群的 Namespace）；对于云服务，资源创建时会根据交付目标中指定的云厂商的参数创建到对应的区域和专有网络中，然后将生成的云资源信息分发到交付目标指定的 Kubernetes 集群中。单个环境可关联多个交付目标，代表该环境需要多集群交付。单个交付目标只能对应一个环境。

3.4、应用（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 控制台中也可以看到应用的状态，也可以在控制台中直接进行人工审核操作。

审批通过后会执行第三个步骤 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 控制台中也可以看到应用的状态：

到这里就完成了我们的第一个 KubeVela 应用的部署流程。