基于 KubeVela 的 GitOps 交付

Posted 2021-11-07 阿里系统软件技术

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了基于 KubeVela 的 GitOps 交付相关的知识，希望对你有一定的参考价值。

作者｜董天欣（雾雾）
审核&校对：溪洋、海珠
编辑&排版：雯燕

KubeVela 是一个简单、易用、且高可扩展的云原生应用管理和交付平台，能让开发人员方便快捷地在 Kubernetes 上定义与交付现代微服务应用，无需了解任何 Kubernetes 基础设施相关的细节。

KubeVela 背后的 OAM 模型天然解决了应用构建过程中对复杂资源的组合、编排等管理问题，同时也将后期的运维策略模型化，这意味着 KubeVela 可以结合 GitOps 管理复杂大规模应用，收敛由于团队与系统规模增长导致的系统复杂度问题。

什么是 GitOps

它的核心思想是将应用系统所需的基础架构和应用配置声明性描述存放在Git仓库中，并配合一个自动化流程，使每次仓库被更新后，自动化过程都能逐渐将环境更新到最新配置。

这样的方式允许开发人员通过直接更改 Git 仓库中的代码和配置来自动部署应用，使用 GitOps 的方式可以为应用研发带来诸多价值，例如：

• 提高生产效率。通过自动的持续部署能够加快平均部署时间，增加开发效率。
• 降低开发人员部署的门槛。通过推送代码而非容器配置，开发人员可以不需要了解 Kubernetes 的内部实现，便可以轻易部署。
• 使变更记录可追踪。通过 Git 来管理集群，可以使每一次更改都可追踪，加强了审计跟踪。
• 可通过 Git 的回滚/分支功能来恢复集群。

KubeVela 与 GitOps

KubeVela 作为一个声明式的应用交付控制平面，天然支持以 GitOps 的方式来使用，并使用户更明显地感受到由 GitOps 带来的益处，和端到端的应用交付与管理体验，包括：

• 应用交付工作流（CD 流水线）：即：KubeVela 支持在 GitOps 模式中描述过程式的应用交付，而不只是简单的声明终态；
• 处理部署过程中的各种依赖关系和拓扑结构；
• 在现有各种 GitOps 工具的语义之上提供统一的上层抽象，简化应用交付与管理过程；
• 统一进行云服务的声明、部署和服务绑定；
• 提供开箱即用的交付策略（金丝雀、蓝绿发布等）；
• 提供开箱即用的混合云/多云部署策略（放置规则、集群过滤规则等）；
• 在多环境交付中提供 Kustomize 风格的 Patch 来描述部署差异，而无需学习任何 Kustomize 本身的细节；
• ……

在本文中，我们主要讲解直接使用 KubeVela 在 GitOps 模式下进行交付的步骤。

GitOps 工作流

GitOps 工作流分为 CI 和 CD 两个部分：

• CI（Continuous Integration）：持续集成对业务应用进行代码构建、构建镜像并推送至镜像仓库。目前有许多成熟的 CI 工具，如开源项目常用的 GitHub Action、Travis 等，以及企业中常用的 Jenkins、Tekton 等。在本文中，我们使用 GitHub Action 来完成 CI 这一步，当然你也可以使用别的 CI 工具来代替，KubeVela 围绕 GitOps 可以对接任意工具下的 CI 流程。
• CD（Continuous Delivery）：持续部署会自动更新集群中的配置，如将镜像仓库中的最新镜像更新到集群中。目前主要有两种方案的 CD：
1）Push-Based：Push 模式的 CD 主要是通过配置 CI 流水线来完成的，这种方式需要将集群的访问秘钥共享给 CI，从而使得 CI 流水线能够通过命令将更改推送到集群中，可以参考我们之前发表的博客：使用 Jenkins + KubeVela 完成应用的持续交付（详见文末相关链接）。
2）Pull-Based：Pull 模式的 CD 会在集群中监听仓库（代码仓库或者配置仓库）的变化，并且将这些变化同步到集群中。与 Push 模式相比，Pull-Based 由集群主动拉取更新，从而避免了秘钥暴露的问题。这也是本文介绍的核心内容。

交付的面向人员有以下两种，我们将分别介绍：

面向平台管理员/运维人员的基础设施交付，用户可以通过直接更新仓库中的配置文件，从而更新集群中的基础设施配置，如系统的依赖软件、安全策略、存储、网络等基础设施配置。
面向终端开发者的交付，用户的代码一旦合并到应用代码仓库，就自动化触发集群中应用的更新，可以更高效的完成应用的迭代，与 KubeVela 的灰度发布、流量调拨、多集群部署等功能结合可以形成更为强大的自动化发布能力。

面向平台管理员/运维人员的交付

如图所示，对于平台管理员/运维人员而言，他们并不需要关心应用的代码，所以只需要准备一个 Git 配置仓库并部署 KubeVela 配置文件，后续对于应用及基础设施的配置变动，便可通过直接更新 Git 配置仓库来完成，使得每一次配置变更可追踪。

准备配置仓库

具体的配置可参考示例仓库 1（详见文末相关链接）。

在本例中，我们将部署一个 mysql 数据库软件作为项目的基础设施，同时部署一个业务应用，使用这个数据库。配置仓库的目录结构如下:

• clusters/ 中包含集群中的 KubeVela GitOps 配置，用户需要将 clusters/ 中的文件手动部署到集群中。这个是一次性的管控操作，执行完成后，KubeVela 便能自动监听配置仓库中的文件变动且自动更新集群中的配置。其中，clusters/apps.yaml 将监听 apps/ 下所有应用的变化，clusters/infra.yaml 将监听 infrastructure/ 下所有基础设施的变化。
• apps/ 目录中包含业务应用的所有配置，在本例中为一个使用数据库的业务应用。
• infrastructure/ 中包含一些基础设施相关的配置和策略，在本例中为 MySQL 数据库。

├── apps
│   └── my-app.yaml
├── clusters
│   ├── apps.yaml
│   └── infra.yaml
└── infrastructure
    └── mysql.yaml

KubeVela 建议使用如上的目录结构管理你的 GitOps 仓库。clusters/ 中存放相关的 KubeVela GitOps 配置并需要被手动部署到集群中，apps/ 和 infrastructure/ 中分别存放你的应用和基础设施配置。通过把应用和基础配置分开，能够更为合理的管理你的部署环境，隔离由应用变动带来的影响。

clusters/ 目录

首先，我们来看下 clusters 目录，这也是 KubeVela 对接 GitOps 的初始化操作配置目录。

以 clusters/infra.yaml 为例：

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: infra
spec:
  components:
  - name: database-config
    type: kustomize
    properties:
      repoType: git
      # 将此处替换成你需要监听的 git 配置仓库地址
      url: https://github.com/FogDong/KubeVela-GitOps-Infra-Demo
      # 如果是私有仓库，还需要关联 git secret
      # secretRef: git-secret
      # 自动拉取配置的时间间隔，由于基础设施的变动性较小，此处设置为十分钟
      pullInterval: 10m
      git:
        # 监听变动的分支
        branch: main
      # 监听变动的路径，指向仓库中 infrastructure 目录下的文件
      path: ./infrastructure

apps.yaml 与 infra.yaml 几乎保持一致，只不过监听的文件目录有所区别。在 apps.yaml 中，properties.path 的值将改为 ./apps，表明监听 apps/ 目录下的文件变动。

cluster 文件夹中的 GitOps 管控配置文件需要在初始化的时候一次性手动部署到集群中，在此之后 KubeVela 将自动监听 apps/ 以及 infrastructure/ 目录下的配置文件并定期更新同步。

apps/ 目录

apps/ 目录中存放着应用配置文件，这是一个配置了数据库信息以及 Ingress 的简单应用。该应用将连接到一个 MySQL 数据库，并简单地启动服务。在默认的服务路径下，会显示当前版本号。在 /db 路径下，会列出当前数据库中的信息。

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: my-app
  namespace: default
spec:
  components:
    - name: my-server
      type: webservice
      properties:
        image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412
        port: 8088
        env:
          - name: DB_HOST
            value: mysql-cluster-mysql.default.svc.cluster.local:3306
          - name: DB_PASSWORD
            valueFrom:
              secretKeyRef:
                name: mysql-secret
                key: ROOT_PASSWORD
      traits:
        - type: ingress
          properties:
            domain: testsvc.example.com
            http:
              /: 8088

这是一个使用了 KubeVela 内置组件类型 webservice 的应用，该应用绑定了 Ingress 运维特征。通过在应用中声明运维能力的方式，只需一个文件，便能将底层的 Deployment、Service、Ingress 集合起来，从而更为便捷地管理应用。

infrastructure/ 目录

infrastructure/ 目录下存放一些基础设施的配置。此处我们使用 mysql controller（详见文末相关链接）来部署了一个 MySQL 集群。

注意，请确保你的集群中有一个 secret，并通过 ROOT_PASSWORD 声明了 MySQL 密码。

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: mysql
  namespace: default
spec:
  components:
    - name: mysql-controller
      type: helm
      properties:
        repoType: helm
        url: https://presslabs.github.io/charts
        chart: mysql-operator
        version: "0.4.0"
    - name: mysql-cluster
      type: raw
      dependsOn:
        - mysql-controller
      properties:
        apiVersion: mysql.presslabs.org/v1alpha1
        kind: MysqlCluster
        metadata:
          name: mysql-cluster
        spec:
          replicas: 1
          # 关联 secret 名称
          secretName: mysql-secret

在这个 MySQL 应用中，我们使用了 KubeVela 工作流的能力。工作流分为两个步骤，第一个步骤会去部署 MySQL 的 controller。当 controller 部署成功且正确运行后，第二个步骤将开始部署 MySQL 集群。

部署 clusters/ 目录下的文件

配置完以上文件并存放到 Git 配置仓库后，我们需要在集群中手动部署 clusters/ 目录下的 KubeVela GitOps 配置文件。

首先，在集群中部署 clusters/infra.yaml。可以看到它自动在集群中拉起了 infrastructure/ 目录下的 MySQL 部署文件：

kubectl apply -f clusters/infra.yaml

$ vela ls
APP     COMPONENT           TYPE        TRAITS  PHASE   HEALTHY STATUS  CREATED-TIME
infra   database-config     kustomize           running healthy         2021-09-26 20:48:09 +0800 CST
mysql   mysql-controller    helm                running healthy         2021-09-26 20:48:11 +0800 CST
└─      mysql-cluster       raw                 running healthy         2021-09-26 20:48:11 +0800 CST

接着，在集群中部署

clusters/apps.yaml，可以看到它自动拉起了 apps/ 目录下的应用部署文件：

kubectl apply -f clusters/apps.yaml

APP     COMPONENT           TYPE        TRAITS  PHASE   HEALTHY STATUS  CREATED-TIME
apps    apps                kustomize           running healthy         2021-09-27 16:55:53 +0800 CST
infra   database-config     kustomize           running healthy         2021-09-26 20:48:09 +0800 CST
my-app  my-server           webservice  ingress running healthy         2021-09-27 16:55:55 +0800 CST
mysql   mysql-controller    helm                running healthy         2021-09-26 20:48:11 +0800 CST
└─      mysql-cluster       raw                 running healthy         2021-09-26 20:48:11 +0800 CST

至此，我们通过部署 KubeVela GitOps 配置文件，自动在集群中拉起了应用及数据库。

通过 curl 应用的 Ingress，可以看到目前的版本是 0.1.5，并且成功地连接到了数据库：

$ kubectl get ingress
NAME        CLASS    HOSTS                 ADDRESS         PORTS   AGE
my-server   <none>   testsvc.example.com   <ingress-ip>    80      162m
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>
Version: 0.1.5
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>/db
User: KubeVela
Description: It\'s a test user

修改配置

完成了首次部署后，我们可以通过修改配置仓库中的配置，来完成集群中应用的配置更新。

修改应用 Ingress 的 Domain：

...
      traits:
        - type: ingress
          properties:
            domain: kubevela.example.com
            http:
              /: 8089

经过一段时间后，重新查看集群中的 Ingress：

NAME        CLASS    HOSTS                 ADDRESS         PORTS   AGE
my-server   <none>   kubevela.example.com  <ingress-ip>    80      162m

可以看到，Ingress 的 Host 地址已被成功更新。

通过这种方式，我们可以方便地通过更新 Git 配置仓库中的文件，从而自动化更新集群中的配置。

面向终端开发者的交付

对于终端开发者而言，在 KubeVela Git 配置仓库以外，还需要准备一个应用代码仓库。如图所示，在用户更新了应用代码仓库中的代码后，需要配置一个 CI 来自动构建镜像并推送至镜像仓库中。KubeVela 会监听镜像仓库中的最新镜像，并自动更新配置仓库中的镜像配置，最后再更新集群中的应用配置。使用户可以达成在更新代码后，集群中的配置也自动更新的效果。

准备代码仓库

准备一个代码仓库，里面包含一些源代码以及对应的 Dockerfile。

这些代码将连接到一个 MySQL 数据库，并简单地启动服务。在默认的服务路径下，会显示当前版本号。在 /db 路径下，会列出当前数据库中的信息。

http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        _, _ = fmt.Fprintf(w, "Version: %s\\n", VERSION)
    })
    http.HandleFunc("/db", func(w http.ResponseWriter, r *http.Request) {
        rows, err := db.Query("select * from userinfo;")
        if err != nil {
            _, _ = fmt.Fprintf(w, "Error: %v\\n", err)
        }
        for rows.Next() {
            var username string
            var desc string
            err = rows.Scan(&username, &desc)
            if err != nil {
                _, _ = fmt.Fprintf(w, "Scan Error: %v\\n", err)
            }
            _, _ = fmt.Fprintf(w, "User: %s \\nDescription: %s\\n\\n", username, desc)
        }
    })
    if err := http.ListenAndServe(":8088", nil); err != nil {
        panic(err.Error())
    }

我们希望用户改动代码进行提交后，自动构建出最新的镜像并推送到镜像仓库。这一步 CI 可以通过集成 GitHub Actions、Jenkins 或者其他 CI 工具来实现。在本例中，我们通过借助 GitHub Actions 来完成持续集成。具体的代码文件及配置可参考示例仓库 2（详见文末相关链接）。

配置秘钥信息

在新的镜像推送到镜像仓库后，KubeVela 会识别到新的镜像，并更新仓库及集群中的 Application 配置文件。因此，我们需要一个含有 Git 信息的 Secret，使 KubeVela 向 Git 仓库进行提交。部署如下文件，将其中的用户名和密码替换成你的 Git 用户名及密码（或 Token）：

apiVersion: v1
kind: Secret
metadata:
  name: git-secret
type: kubernetes.io/basic-auth
stringData:
  username: <your username>
  password: <your password>

准备配置仓库

配置仓库与之前面向运维人员的配置大同小异，只需要加上与镜像仓库相关的配置即可。具体配置请参考示例仓库 1（详见文末相关链接）。

修改 clusters/ 中的 apps.yaml，该 GitOps 配置会监听仓库中 apps/ 下的应用文件变动以及镜像仓库中的镜像更新：

...
  imageRepository:
    # 镜像地址
    image: <your image>
    # 如果这是一个私有的镜像仓库，可以通过 `kubectl create secret docker-registry` 创建对应的镜像秘钥并相关联
    # secretRef: imagesecret
    filterTags:
      # 可对镜像 tag 进行过滤
      pattern: \'^master-[a-f0-9]+-(?P<ts>[0-9]+)\'
      extract: \'$ts\'
    # 通过 policy 筛选出最新的镜像 Tag 并用于更新
    policy:
      numerical:
        order: asc
    # 追加提交信息
    commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"

修改 apps/my-app.yaml 中的 image 字段，在后面加上 # {"$imagepolicy": "default:apps"} 的注释。KubeVela 会通过该注释去更新对应的镜像字段。default:apps 是上面 GitOps 配置对应的命名空间和名称。

spec:
  components:
    - name: my-server
      type: webservice
      properties:
        image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412 # {"$imagepolicy": "default:apps"}

将 clusters/ 中包含镜像仓库配置的文件更新到集群中后，我们便可以通过修改代码来完成应用的更新。

修改代码

将代码文件中的 Version 改为 0.1.6，并修改数据库中的数据：

const VERSION = "0.1.6"
...
func InsertInitData(db *sql.DB) {
    stmt, err := db.Prepare(insertInitData)
    if err != nil {
        panic(err)
    }
    defer stmt.Close()
    _, err = stmt.Exec("KubeVela2", "It\'s another test user")
    if err != nil {
        panic(err)
    }
}

提交该改动至代码仓库，可以看到，我们配置的 CI 流水线开始构建镜像并推送至镜像仓库。

而 KubeVela 会通过监听镜像仓库，根据最新的镜像 Tag 来更新配置仓库中 apps/ 下的应用 my-app。

此时，可以看到配置仓库中有一条来自 kubevelabot 的提交，提交信息均带有 Update image automatically. 前缀。你也可以通过 {{range .Updated.Images}}{{println .}}{{end}} 在 commitMessage 字段中追加你所需要的信息。

值得注意的是，如果你希望将代码和配置放在同一个仓库，需要过滤掉来自 kubevelabot 的提交来防止流水线的重复构建。可以在 CI 中通过如下配置过滤：

jobs:
publish:
  if: "!contains(github.event.head_commit.message, \'Update image automatically\')"

重新查看集群中的应用，可以看到经过一段时间后，应用 my-app 的镜像已经被更新。

KubeVela 会通过你配置的 interval 时间间隔，来每隔一段时间分别从配置仓库及镜像仓库中获取最新信息：

• 当 Git 仓库中的配置文件被更新时，KubeVela 将根据最新的配置更新集群中的应用。
• 当镜像仓库中多了新的 Tag 时，KubeVela 将根据你配置的 policy 规则，筛选出最新的镜像 Tag，并更新到 Git 仓库中。而当代码仓库中的文件被更新后，KubeVela 将重复第一步，更新集群中的文件，从而达到了自动部署的效果。

通过 curl 对应的 Ingress 查看当前版本和数据库信息：

$ kubectl get ingress
NAME        CLASS    HOSTS                 ADDRESS         PORTS   AGE
my-server   <none>   kubevela.example.com  <ingress-ip>    80      162m
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>
Version: 0.1.6
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>/db
User: KubeVela
Description: It\'s a test user
User: KubeVela2
Description: It\'s another test user

版本已被成功更新！至此，我们完成了从变更代码，到自动部署至集群的全部操作。

总结

在运维侧，如若需要更新基础设施（如数据库）的配置，或是应用的配置项，只需要修改配置仓库中的文件，KubeVela 将自动把配置同步到集群中，简化了部署流程。

在研发侧，用户修改代码仓库中的代码后，KubeVela 将自动更新配置仓库中的镜像。从而进行应用的版本更新。

通过与 GitOps 的结合，KubeVela 加速了应用从开发到部署的整个流程。

戳原文，查看 KubeVela 项目官方主页与文档！！

相关链接
1）使用 Jenkins + KubeVela 完成应用的持续交付：
https://kubevela.io/zh/blog/2021/09/02/kubevela-jenkins-cicd
2）示例仓库 1：
https://github.com/oam-dev/samples/tree/master/9.GitOps_Demo/for-SREs
3）mysql controller：
https://github.com/bitpoke/mysql-operator
4）示例仓库 2：
https://github.com/oam-dev/samples/tree/master/9.GitOps_Demo/for-developers/app-code

了解更多相关信息，请钉钉扫描下方二维码或搜索钉钉群号（35922870）加入阿里云原生资讯交流群！获取更多相关资讯！

KubeVela 为 CNCF 孵化器带来软件交付控制平面能力

CNCF TOC（Technical Oversight Committee，技术监督委员会）已经投票接受 KubeVela 作为 CNCF 的孵化项目。

KubeVela [ 1] 是一个应用交付引擎，也是基于 Kubernetes 的扩展插件，它可以让你的应用交付在当今流行的混合、多云环境中变得更加简单、高效、可靠。KubeVela 可以通过基于工作流的应用交付模型来编排、部署和操作工作负载和云资源。KubeVela 的应用交付抽象由 OAM [ 2] （Open Application Model，开放应用模型）提供支持。

KubeVela 项目的前身是 oam-kubernetes-runtime [ 3] 项目，它由来自八家不同组织的开发者一同在社区发起 [ 4] ，包括阿里云、微软、Upbound 等。它于 2020 年 11 月发布正式对外开源，2021 年 4 月发布了 v1.0，2021 年 6 月加入 CNCF 成为沙箱项目。该项目目前的贡献者来自世界各地，有超过 260 多名贡献者 [5 ] ，包括招商银行、滴滴、京东、极狐 GitLab、SHEIN 等。

“KubeVela 开创了一条跨多云/多集群环境交付应用程序的道路，具有统一且可扩展的抽象。”CNCF TOC Sponsor 张磊表示：“这项创新开启了下一代软件交付体验，填补了现有社区生态应用交付的‘最后一公里’，该实践专注于更简单的‘部署’而不是复杂‘编排’。我们很高兴在 CNCF 社区中能涌现出更多以应用为中心的工具/平台，并期待看到 KubeVela 的采用在快速发展的应用交付生态系统中发展到一个新的水平。”

KubeVela 目前已被多家公司所采纳，被用于大部分的公共云以及内部部署的生产中。大多数用户采用 KubeVela 作为他们的内部“PaaS ”，作为 CI/CD 流水线的一部分，或者作为一个可扩展的 DevOps 内核来构建他们自己的 IDP。公开采用者 [ 6] 包括阿里巴巴，使用 KubeVela 作为核心，进行跨混合环境交付和管理应用；字节跳动，使用 KubeVela 和 Crossplane 提供进阶的游戏 PaaS 能力；招商银行，利用 KubeVela 搭建混合云应用平台，统一从搭建、发布、运行的全流程；以及其他更多行业的公司。

“我们发现现在运维、安全、可观测等能力，随着对应开源工具和云服务的出现，逐渐走向标准化。”阿里云 aPaaS & Serverless 团队的负责人司徒放说，“这些能力可以被集成到应用开发工具链上，也可以融入到应用交付流程里。这样开发人员可以自助使用、轻松配置、自动触发。并且他能从流程里得到更快的反馈，从而大幅提升迭代效率。KubeVela 非常适合做这类应用交付流程的整合和定制，是平台工程的最佳实践。”

“KubeVela 使招商银行能够快速建立大规模统一的 OAM 云原生应用管理平台，降低金融科技云的复杂性，加快现代应用的标准化开发和交付，”招商银行高级架构师兼 KubeVela 维护者徐佳航表示。“KubeVela 提供了应用模型和可编程 CRD、基于工作流程编排的应用交付、可观测性和配置功能，能够更好地赋能云原生应用和 CNCF 生态系统。”

主要组件

是 KubeVela 的主要组成部分，也称为 KubeVela 控制平面。它为创建、编排和交付 OAM 应用程序提供了控制器（operator）和 webhook。7][Vela Core
Vela Workflow[8]引擎基于 CUE 编写的步骤完成编排和执行。这是一个公共库，可以作为独立的引擎工作，也可以在 KubeVela 应用程序中运行。
KubeVela CLI提供了各种命令来帮助你操作应用程序，例如管理定义、查看资源、重新启动工作流和滚动版本。
VelaUX [ 9] 是 KubeVela 的 Web UI。它将业务逻辑合并到基础 API 中，并为不懂 K8s 的用户提供开箱即用的用户体验。
KubeVela 的 Terraform Controller [ 10] 允许用户使用 Terraform 通过 Kubernetes 自定义资源来管理云资源。
Cluster Gateway [ 11] 提供统一的多集群访问接口。
KubeVela 还拥有一个不断增长的Catalog [ 12] ，其中包含 50 多个用于集成的社区插件，包括 ArgoCD、FluxCD、Backstage、OpenKruise、Dapr、Crossplane、Terraform、OpenYurt 等。

显著的里程碑

超过 4.8k GitHub 星星
超过 3.5k 拉取请求
超过 1.6k 提问
超过 290 名贡献者
超过 150 个版本

自从加入 CNCF 沙箱以来，到 v1.7 为止，KubeVela 发布了 7 个小版本，增加了 5 个新组件，包括独立工作流、VelaUX、ClusterGateway、VelaD 和 Vela Prism。贡献者数量从 90+ 增长到 290+，GitHub 星星从 1900+ 增长到 4700+，贡献组织从 20+ 增长到 70+。

“KubeVela 凭借其现代化的开源软件交付控制平台，改善了开发人员在复杂多云环境中的体验。”CNCF 首席技术官 Chris Aniszczyk 表示："我们期待能支持社区朝着毕业项目的方向不断成长和成熟。"

展望未来， KubeVela 社区计划通过交付工作流改善云资源创建和消费的用户体验，增强混合/多集群场景中整个 CI/CD 交付流程的安全，支持用户使用 KubeVela Dynamic API 轻松与第三方 API 集成，等等。请访问 RoadMap [ 13] 了解更多信息。

“对于用户和贡献者的信任和支持，我们深感谦卑和感激，”阿里云高级技术专家、KubeVela 维护者孙健波说。“KubeVela 高度可扩展的设计非常适合社区多样化的用户场景，为我们的应用交付生态系统带来了强大的引擎。感谢 CNCF 的支持和认可，我相信达到孵化阶段是该项目的一个重要里程碑。KubeVela 维护人员期待与 CNCF 合作，共同实现我们的目标，让在当今的混合环境中部署和运行应用程序变得更容易、更快速、更可靠。”

“多亏了 Kubevela，我们在 Kubernetes 中部署和管理应用程序的方式现在变得更加便捷。”Napptive 首席技术官、KubeVela 维护者 Daniel Higuero 表示：“使用 Application（应用程序）和 Workflow（工作流）作为顶层概念极大地简化了 Kubernetes 上的常见流程。这种方法的优势，在于它能够简化基本用例，同时通过多租户和多集群支持实现复杂用例。同时，通过与社区插件的可扩展系统相结合，允许它与其他工具集成并添加自定义定义，以根据你的使用案例定制体验。”

“CNCF 社区孵化了大量的云原生操作和原子管理能力，”阿里云技术专家、KubeVela 维护者曾庆国表示。“我们希望通过一个统一的、以应用为中心的概念来整合各种能力，并帮助越来越多的平台开发者，在企业中轻松实现标准化的应用。KubeVela 正在成长为企业践行平台工程的有力帮手。”

“KubeVela 旨在为各行各业提供丰富的云原生基础设施的便利和进步，”阿里云高级工程师、KubeVela 维护者殷达表示。“为了满足现代应用交付需求，KubeVela 一直在探索可扩展和灵活的架构，并添加开创性的想法，包括多集群交付、可编程工作流和自动化可观测能力。KubeVela 还持续关注控制平面的安全性和稳定性，这为社区采用者树立了生产信心。我们预计 KubeVela 的开放性可以使其成为云原生时代的前沿探索者。”

作为 CNCF 托管的项目，KubeVela 是一个中立基金会的一部分，该基金会与其技术利益和更大的 Linux 基金会保持一致，提供治理、营销支持和社区拓展。该项目与其他 35 个项目，包括 Backstage、Cilium、Istio、Knative、OpenTelemetry 等，同样进入孵化阶段 [ 14] 。关于每个级别的成熟度要求，请访问 CNCF 毕业标准 [ 15] 。