Mastering KubeVela GitOps: A Step‑by‑Step Guide to Automated Cloud‑Native Deployments

What is GitOps?

GitOps stores declarative infrastructure and application configuration in a Git repository and runs an automated process that continuously reconciles the cluster state to match the latest commit, enabling developers to trigger deployments simply by pushing code or configuration changes.

Improves productivity by shortening deployment cycles.

Lowers the barrier for developers who no longer need deep Kubernetes knowledge.

Provides an auditable change history.

Allows easy rollback using Git branches or tags.

KubeVela and GitOps

KubeVela is a cloud‑native application delivery platform built on the OAM model. It natively supports GitOps, offering:

Declarative CD pipelines that describe the full delivery process, not just the final state.

Dependency and topology handling during deployment.

A unified abstraction over existing GitOps tools.

Automatic cloud service provisioning, binding, and multi‑cloud deployment strategies.

Built‑in delivery policies such as canary and blue‑green releases.

Kustomize‑style patches for multi‑environment differences.

The article focuses on using KubeVela directly in GitOps mode.

GitOps Workflow Overview

The workflow consists of two parts:

CI (Continuous Integration) : Build the application, create a container image, and push it to a registry. The example uses GitHub Actions, but any CI tool (Jenkins, Tekton, etc.) can be substituted.

CD (Continuous Delivery) : Automatically update the cluster when the Git repository or image registry changes. Two CD patterns are described:

Push‑Based : The CI pipeline holds cluster credentials and pushes changes directly to the cluster.

Pull‑Based (the focus of this guide): The cluster pulls changes from the Git repository, avoiding credential exposure.

Delivery for Platform Administrators / Operators

Operators maintain a Git configuration repository that contains three top‑level directories:

├── apps</code><code>│   └── my-app.yaml</code><code>├── clusters</code><code>│   ├── apps.yaml</code><code>│   └── infra.yaml</code><code>└── infrastructure</code><code>    └── mysql.yaml

clusters/ holds KubeVela GitOps configuration files that must be applied once manually (e.g., kubectl apply -f clusters/infra.yaml and kubectl apply -f clusters/apps.yaml). After that, KubeVela continuously watches the apps/ and infrastructure/ directories for changes.

Example clusters/infra.yaml (simplified):

apiVersion: core.oam.dev/v1beta1</code><code>kind: Application</code><code>metadata:</code><code>  name: infra</code><code>spec:</code><code>  components:</code><code>  - name: database-config</code><code>    type: kustomize</code><code>    properties:</code><code>      repoType: git</code><code>      url: https://github.com/FogDong/KubeVela-GitOps-Infra-Demo</code><code>      pullInterval: 10m</code><code>      git:</code><code>        branch: main</code><code>      path: ./infrastructure

The corresponding clusters/apps.yaml is identical except that path points to ./apps.

After applying the cluster files, you can verify the resources:

$ vela ls</code><code>APP   COMPONENT          TYPE      PHASE   HEALTHY   CREATED‑TIME</code><code>infra database-config    kustomize running healthy 2021‑09‑26 20:48:09</code><code>mysql mysql-controller   helm      running healthy 2021‑09‑26 20:48:11

Deploying clusters/apps.yaml brings up the sample web service and its Ingress. You can then query the Ingress to see the version and database content.

Delivery for End‑User Developers

Developers maintain a separate code repository containing source code and a Dockerfile. A CI pipeline (GitHub Actions in the example) builds the image and pushes it to a registry. KubeVela watches the registry, updates the image field in apps/my-app.yaml via an

{