Posted inDevOps

Deploying KubeVela on Kubernetes: Modern Application Delivery with Open Application Model (OAM)

DevOps tutorial - IT technology blog
DevOps tutorial - IT technology blog

Context & Why — The 2 AM Deployment Nightmare That Changed My Approach

Three months ago, at 2 AM, Slack lit up. The payment service had just crashed in production, but staging was perfectly fine. I diffed the Kubernetes manifests between environments and found it: staging had resources.limits.memory: 256Mi, production had 512Mi. Someone had manually patched the prod config two weeks earlier and nobody caught it until the traffic spike hit.

That incident was my KubeVela wake-up call. Environment drift — where staging, prod, and on-prem clusters slowly diverge over time — quietly causes more production incidents than almost any other Kubernetes failure mode. It is not glamorous. But fixing it changes everything.

KubeVela is a CNCF project that implements the Open Application Model (OAM) spec on top of Kubernetes. The architecture draws a clean line: what to deploy is the app developer’s concern, how to deploy it belongs to the platform team. OAM builds this separation into four primitives:

  • Component — what your app is (a web service, a worker, a database)
  • Trait — what your app needs (autoscaling, ingress, sidecar injection)
  • Policy — where and how (environment-specific overrides, multi-cluster placement)
  • Workflow — the deployment steps (canary, approval gates, progressive rollout)

The result: one Application definition, consistent deployments across dev, staging, prod, cloud, and on-prem — no separate YAML files per environment.

Installation

Prerequisites

You need a running Kubernetes cluster (1.22+), kubectl configured, and Helm 3.x. Any flavor works — EKS, GKE, AKS, k3s, or a bare-metal setup.

Install the KubeVela CLI

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

To pin a specific version for reproducibility:

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

Install KubeVela Core on Your Cluster

helm repo add kubevela https://kubevela.github.io/charts
helm repo update
helm install --create-namespace -n vela-system kubevela kubevela/vela-core

Give it a minute, then confirm everything came up:

kubectl wait --for=condition=Ready pods --all -n vela-system --timeout=300s
kubectl get pods -n vela-system

Expect to see the kubevela-vela-core controller and the cluster-gateway pod both running. Want a web UI too? Enable the VelaUX addon:

vela addon enable velaux

Configuration — One App Spec, Every Environment

Defining Your First OAM Application

Here is exactly what would have saved me that night. Instead of separate YAML files for staging and production, define one Application with environment-specific patches:

# payment-service.yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: payment-service
  namespace: production
spec:
  components:
    - name: payment-api
      type: webservice
      properties:
        image: myregistry/payment-api:v1.2.3
        port: 8080
        cpu: "0.5"
        memory: "512Mi"
      traits:
        - type: scaler
          properties:
            replicas: 3
        - type: gateway
          properties:
            domain: payment.myapp.com
            http:
              "/": 8080
  policies:
    - name: staging-override
      type: override
      properties:
        selector:
          - payment-api
        components:
          - name: payment-api
            type: webservice
            properties:
              cpu: "0.2"
              memory: "256Mi"
            traits:
              - type: scaler
                properties:
                  replicas: 1

Production values (memory: 512Mi, 3 replicas) are the source of truth. Staging gets a named policy that patches only what differs. No drift, no surprises.

Deploy it:

kubectl apply -f payment-service.yaml

Multi-Cluster Deployment

Running both cloud and on-prem clusters? Register them with KubeVela’s cluster manager first:

vela cluster join /path/to/prod-kubeconfig --name prod-cluster
vela cluster join /path/to/dr-kubeconfig --name dr-cluster
vela cluster list

Then add a topology policy to your Application:

  policies:
    - name: multi-cluster
      type: topology
      properties:
        clusters:
          - prod-cluster
          - dr-cluster
        namespace: production

Adding an Approval Gate with Workflow

The workflow feature has saved me from several bad pushes. Insert a mandatory approval step between staging and production:

  workflow:
    steps:
      - name: deploy-staging
        type: deploy
        properties:
          policies:
            - staging-override
      - name: human-approval
        type: suspend
      - name: deploy-production
        type: deploy
        properties:
          policies:
            - multi-cluster

Execution halts at type: suspend. Once staging looks healthy, resume:

vela workflow resume payment-service -n production

At 2 AM, a mandatory checkpoint before prod is not paranoia — it is the difference between a minor incident and a major outage.

Verification & Monitoring

Checking Application Health

One command gives you the full picture:

vela status payment-service -n production

It breaks down health per-component, across every cluster:

About:
  Name:      payment-service
  Namespace: production

Services:
  - Name: payment-api
    Cluster: prod-cluster  Namespace: production
    Type: webservice
    Healthy Ready:3/3
    Traits:
      ✅ scaler
      ✅ gateway

Logs and Port-Forwarding

Stream logs from a specific component without hunting for pod names:

vela logs payment-service --component payment-api -n production

Need to hit the API locally without exposing it to the internet?

vela port-forward payment-service -n production

Web Dashboard

Already enabled VelaUX? Pull up the dashboard:

vela port-forward -n vela-system addon-velaux 8080:80

Open http://localhost:8080 for a visual map of every application, workflow state, cluster, and component history. When a multi-cluster incident hits at 3 AM, a dashboard beats scrolling through kubectl output.

Prometheus Metrics

For production observability, KubeVela exposes controller metrics. Port-forward the controller to inspect them:

kubectl port-forward -n vela-system deployment/kubevela-vela-core 8080:8080
curl http://localhost:8080/metrics | grep vela_

Three metrics worth setting alerts on:

  • vela_application_phase — current phase of each app (running, failed, stopped)
  • vela_reconcile_duration_seconds — reconciliation latency (spikes indicate cluster pressure)
  • vela_reconcile_errors_total — cumulative error count (a rising counter needs investigation)

Wire these into Grafana and you stop flying blind. Full visibility into the delivery pipeline — not just pod health, but the entire lifecycle from commit to cluster.

With this in place three months ago, the memory mismatch would never have reached production. A divergent-config alert would have fired long before the traffic spike hit. That is the real value of KubeVela — not just the tooling, but the operational discipline baked in by design.

Share:
Tags: