How KubeVela 1.7 Simplifies Workload Adoption and Boosts Performance

Workload Adoption Modes

KubeVela 1.7 introduces two adoption policies for existing workloads:

Read‑only mode – Vela only observes the resources; it never writes or deletes them. Deleting the adopted Application leaves the underlying resources untouched, and external changes remain visible.

Take‑over mode – Vela fully manages the adopted resources. Updates, deletions and lifecycle actions are controlled by the Application. External modifications are reverted unless an apply‑once strategy is added.

Policies are defined in an OAM Application resource.

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: read-only
spec:
  components:
  - name: nginx
    type: webservice
    properties:
      image: nginx
  policies:
  - type: read-only
    name: read-only
    properties:
      rules:
      - selector:
          resourceTypes: ["Deployment"]

Take‑over example:

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: take-over
spec:
  components:
  - name: nginx-take-over
    type: k8s-objects
    properties:
      objects:
      - apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: nginx
    traits:
    - type: scaler
      properties:
        replicas: 3
  policies:
  - type: take-over
    name: take-over
    properties:
      rules:
      - selector:
          resourceTypes: ["Deployment"]

One‑Click CLI Adoption

The vela adopt command automatically adopts native resources or Helm releases. By default it uses read‑only mode; add --mode take-over for full management.

$ vela adopt deployment/default/example configmap/default/example
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  labels:
    app.oam.dev/adopt: native
  name: example
  namespace: default
spec:
  components:
  - name: example.Deployment.example
    properties:
      objects:
      - apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: example
          namespace: default
        spec:
          replicas: 1
          ...
  - name: example.config
    properties:
      objects:
      - apiVersion: v1
        kind: ConfigMap
        metadata:
          name: example
          namespace: default
  policies:
  - name: read-only
    type: read-only
    properties:
      rules:
      - selector:
          componentNames:
          - example.Deployment.example
          - example.config

Supported default adoption types include CRDs, Namespaces, Deployments, Services, ConfigMaps, ServiceAccounts, Webhooks, and PersistentVolumes. Bulk adoption is possible with: vela adopt --all --apply Custom resource topology rules can be supplied via --resource-topology-rule and CUE templates.

Performance Optimizations

KubeVela 1.7 improves controller throughput and per‑application capacity by 5‑10×. ResourceTracker and ApplicationRevision objects are compressed with zstd, reducing their size by ~10× and expanding supported resource capacity.

Memory usage drops to one‑third by lowering default revision history (applications keep 2 revisions instead of 10, component versions disabled) and trimming definition history from 20 to 2 entries. API QPS limits increased from 100 to 200.

Usability Enhancements

Dry‑run now accepts multiple policy and workflow files, enabling separate test and production configurations:

vela dry-run -f app.yaml -f test-policy.yaml -f test-workflow.yaml
vela dry-run -f app.yaml -f prod-policy.yaml -f prod-workflow.yaml

Application deletion gained three options:

Interactive deletion for clusters that have lost connectivity. --orphan to keep underlying resources while removing the Application metadata. --force to delete Applications after the controller has been uninstalled.

Plugins can provide custom NOTES via a NOTES.cue file. Example for the backstage plugin:

info: string
if !parameter.pluginOnly {
  info: """
    By default, the backstage app serves at 127.0.0.1:7007. Check it with:
        vela port-forward addon-backstage -n vela-system
    You can build your own backstage app for other domains.
  """
}
if parameter.pluginOnly {
  info: "You can use the endpoint of 'backstage-plugin-vela' in your own backstage app by configuring the 'vela.host', see https://github.com/wonderflow/vela-backstage-demo."
}
notes: (info)

Workflow capabilities were expanded with step retry, automatic step naming, parameter overriding, and new built‑in steps such as built-push-image for building and pushing container images.

VelaUX Improvements

Richer workflow orchestration UI with sub‑steps, inputs/outputs, timeouts, conditions, and dependencies.

Application version rollback and diff view.

Enhanced multi‑tenant RBAC alignment with Kubernetes.

Future Roadmap (1.8)

Planned enhancements include large‑scale controller performance and sharding, out‑of‑the‑box gray‑release support in VelaUX, and stronger GitOps integration.

References

Project repository: https://github.com/kubevela/kubevela

Official documentation: https://kubevela.net/zh/docs/end-user/policies/resource-adoption

Adopt template example: https://github.com/kubevela/kubevela/blob/master/references/cli/adopt-templates/default.cue

Performance PR: https://github.com/kubevela/kubevela/pull/5090

Built‑in workflow steps: https://kubevela.net/docs/end-user/workflow/built-in-workflow-defs