KubeVela Application Delivery Platform

KubeVela is a modern application delivery platform designed to simplify deploying and operating applications across hybrid and multi-cloud environments. It follows a "render, orchestrate, deploy" workflow and is built upon the Open Application Model (OAM).

Key capabilities include:

• Deployment as Code: Declare deployment plans as workflows that can be integrated with CI/CD or GitOps systems. Workflows can be extended using CUE.
• Multi-cloud/Hybrid Support: Native support for progressive rollouts (canary, blue-green), continuous verification, and placement strategies across different clusters and clouds.
• Built-in Governance: Out-of-the-box support for multi-tenancy, LDAP integration, fine-grained RBAC, and automated observability dashboards.
• Extensibility: A lightweight architecture that uses reusable modules (addons) to orchestrate infrastructure capabilities.

The Definition Kit (defkit) is a Go SDK that allows platform engineers to author KubeVela X-Definitions (ComponentDefinition, TraitDefinition, PolicyDefinition, and WorkflowStepDefinition) using native Go code instead of CUE.

Key benefits include:

• Full IDE support: Autocomplete, type checking, and inline documentation.
• Testability: Use standard Go testing frameworks (go test) to unit test definitions.
• Compile-time safety: Catch invalid field names and type mismatches before deployment.
• Standard Distribution: Share definitions as versioned Go modules via go get.
• Transparent Compilation: The SDK compiles Go to CUE automatically; the KubeVela controller remains compatible without needing to execute Go code at runtime.

package myplatform

import (
    "github.com/oam-dev/kubevela/pkg/definition/defkit"
)

func init() {
    defkit.Register(WebserviceComponent())
}

The Cluster Infrastructure Abstraction is a multi-phase architectural design for KubeVela to manage cluster lifecycles, including provisioning, adoption, and connection. The implementation is divided into several key functional areas:

• Core CRDs & Controllers: Management of Cluster, ClusterPlane, ClusterBlueprint, and ClusterProviderDefinition.
• Cluster Lifecycle: Workflows for provisioning (via Crossplane/Terraform), adopting existing clusters, and connecting to remote clusters via kubeconfig.
• Definition System: Introduction of a definition.oam.dev/scope annotation to distinguish between application and cluster scoped definitions.
• Rollout Engine: Managing cluster updates via ClusterRolloutStrategy using waves, maintenance windows, and approval gates.
• Health & Observability: Hierarchical health aggregation (Cluster → Plane → Component → Resource) using providers like Prometheus or Datadog.
• Drift Detection: Comparing cluster state against blueprints and providing remediation via vela cluster remediate.

KubeVela supports a hierarchical composition model where one ComponentDefinition can delegate to another using the def.#RenderComponent function. This allows developers to create layers of abstraction:

1. Base Components (Level 1): Low-level definitions that map directly to Kubernetes resources (e.g., a webservice defining a Deployment).
2. Abstraction Layers (Level 2): Intermediate definitions that wrap base components to simplify configuration (e.g., a myorg-service that maps a size parameter like s, m, or l to specific CPU/Memory/Replica values).
3. Minimal Interfaces (Level 3): High-level, user-facing definitions that expose only the most essential parameters (e.g., a myorg-simple-service that only asks for an image).

When a user deploys a high-level component, KubeVela recursively calls def.#RenderComponent down the chain, compiling and evaluating CUE templates at each step until final Kubernetes manifests are generated.

graph TD
    subgraph "Level 3: Simple Interface"
        A[myorg-simple-service<br/>Parameters: image]
    end
    
    subgraph "Level 2: Size-Based"
        B[myorg-service<br/>Parameters: image, size]
    end
    
    subgraph "Level 1: Full Featured"
        C[webservice<br/>Parameters: image, replicas,<br/>resources, env, ports, etc.]
    end
    
    A -->|def.#RenderComponent| B
    B -->|def.#RenderComponent| C
    C --> D[Kubernetes Deployment]

When an addon module is updated, API lines (versions) follow a specific deprecation lifecycle managed via AddonModuleStatus:

1. Active: The line is available and used by applications.
2. Deprecated: A line enters this state if enabled evaluates to false (via _version.cue) or if the line is removed from the current addon version.
   • Behavior: Deprecated lines remain on the cluster indefinitely and are not automatically removed. However, the admission webhook blocks new Applications from referencing them.
   • Reversibility: If the deprecation was caused by a context-based disable (disabled-by-context), it is reversible if the context becomes enabled again. If the line was physically removed from the source (line-removed), it is a one-way transition.
3. Removal: Removal of a line is an explicit action (e.g., upgrading the addon or KubeVela controller).