In this section, it will introduce how to use CUE to declare app components via
Before reading this part, please make sure you've learned the Definition CRD in KubeVela.
ComponentDefinition scaffolds via
vela def init with existed YAML file.
The YAML file:
ComponentDefinition based on the YAML file:
It generates a file:
.spec.workloadis required to indicate the workload type of this component.
.spec.schematic.cue.templateis a CUE template, specifically:
outputfiled defines the template for the abstraction.
parameterfiled defines the template parameters, i.e. the configurable properties exposed in the
Applicationabstraction (and JSON schema will be automatically generated based on them).
Add parameters in this auto-generated custom component file :
You can use
vela def vet to validate the format:
Declare another component named
task which is an abstraction for run-to-completion workload.
It generates a file:
Edit the generated component file:
ComponentDefinition files to your Kubernetes cluster:
ComponentDefinition can be instantiated in
Application abstraction as below:
Above application resource will generate and manage following Kubernetes resources in your target cluster based on the
output in CUE template and user input in
KubeVela allows you to reference the runtime information of your application via
The most widely used context is application name(
context.appName) component name(
For example, let's say you want to use the component name filled in by users as the container name in the workload instance:
contextinformation are auto-injected before resources are applied to target cluster.
Full available information in CUE
|The revision of the application|
|The revision number(|
|The name of the application|
|The name of the component of the application|
|The namespace of the application|
|The rendered workload API resource of the component, this usually used in trait|
|The rendered trait API resource of the component, this usually used in trait|
It's common that a component definition is composed by multiple API resources, for example, a
webserver component that is composed by a Deployment and a Service. CUE is a great solution to achieve this in simplified primitives.
Another approach to do composition in KubeVela of course is using Helm.
KubeVela requires you to define the template of workload type in
output section, and leave all the other resource templates in
outputs section with format as below:
The reason for this requirement is KubeVela needs to know it is currently rendering a workload so it could do some "magic" like patching annotations/labels or other data during it.
Below is the example for
Apply to your Kubernetes cluster:
The user could now declare an
Application with it:
It will generate and manage below API resources in target cluster:
Please check the Learning CUE documentation about why we support CUE as first-class templating solution and more details about using CUE efficiently.