Build flexible abstraction for any Kubernetes Resources with CUE and KubeVela
Jianbo Sun
KubeVela TeamThis blog will introduce how to use CUE and KubeVela to build you own abstraction API to reduce the complexity of Kubernetes resources. As a platform builder, you can dynamically customzie the abstraction, build a path from shallow to deep for your developers per needs, adapt to growing number of different scenarios, and meet the iterative demands of the company's long-term business development.
#
Convert Kubernetes API Objects Into Custom ComponentsLet's start the journey by using the Kubernetes StatefulSet as example, we will convert it to be a customized module and provide capabilities.
Save the YAML example of StatefulSet in the official document locally and name it as my-stateful.yaml
, then execute command as below:
View the generated "my-stateful.cue" file:
Modify the generated file as follows:
- The example of the official StatefulSet website is a composite component composed of two objects
StatefulSet
andService
. According to KubeVela Rules for customize component, in composite components, one of the resources such (StatefulSet in our example) need to be represented by thetemplate.output
field as a core workload, and other auxiliary objects are represented bytemplate.outputs
, so we make some adjustments and all the automatically generated output and outputs are switched. - Then we fill in the apiVersion and kind data of the core workload into the part marked as
<change me>
After modification, you can use vela def vet
to do format check and verification.
The file after two steps of changes is as follows:
Install ComponentDefinition into the Kubernetes cluster:
You can see that a my-stateful
component via vela components
command:
When you put this customized component into Application
, it looks like:
#
Define Customized Parameters For ComponentIn previous section we have defined a ComponentDefinition that has no parameter. In this section we will show how to expose parameters.
In this example, we expose the following parameters to the user:
- Image name, allowing users to customize the image
- Instance name, allowing users to customize the instance name of the generated StatefulSet object and Service object
After modification, use vela def apply
to install to the cluster:
Then as a platform builder, you have finished your setup. Let's see what's the developer experience now.
#
Developer ExperienceThe only thing your developer need to learn is the Open Application Model which always follow a unified format.
#
Discover the ComponentThe developers can discover and check the parameters of my-stateful
component as follows:
Updating the ComponentDefinition will not affect existing Applications. It will take effect only after updating the Applications next time.
#
Use the Component in ApplicationThe developers can easily specify the three new parameters in the application:
The only thing left is to deploy the yaml file ( assume the name app-stateful.yaml
) by executing vela up -f app-stateful.yaml
.
Then you can see that the name, image, and number of instances of the StatefulSet object have been updated.
#
Dry-run for diagnose or integrationIn order to ensure that the developer's application can run correctly with the parameters, you can also use the vela dry-run
command to verify the trial run of your template.
By viewing the output, you can compare whether the generated object is consistent with the object you actually expect. You can even execute this YAML directly into the Kubernetes cluster and use the results of the operation for verification.
You can also use vela dry-run -h
to view more available function parameters.
context
to avoid duplication#
Use KubeVela allows you to reference the runtime information of your application via context
keyword.
In our example above, the field name
in the properties and the field name
of the Component have the same meaning, so we can use the context
to avoid duplication. We cann use the context.name
to reference the component name in the runtime, thus the name parameter in parameter
is no longer needed.
Just modify the definition file (my-stateful.cue) as the following
Then deploy the changes by the following:
After that, the developers can immediately run application as below:
There's no upgrade or restart for any system, they're all running into affect dynamically per your needs.
#
Add Operational Traits On DemandOAM follows the principle of "separation of concerns", after the developers finished the component part, the operators can add traits into the application to control the rest part configuration of the deployment. For example, the operators can
control replicas, adding labels/annotations, injecting environment variables/sidecars, adding persistent volumes, and so on.
Technically, the trait system works in two ways:
- Patch/Override the configurations defined in component.
- Generate more configuration.
The customized process works the same with the component, they both use CUE but has some different keywords for path and override, you can refer to customize trait for details.
#
Operator Experience with traitsThere're already some built-in traits after KubeVela installed. The operator can use vela traits
to view, the traits marked with *
are general traits, which can operate on common Kubernetes resource objects.
Taking sidecar as an example, you can check the usage of sidecar:
Use the sidecar directly to inject a container, the application description is as follows:
Deploy and run the application, and you can see that a fluentd sidecar has been deployed and running in the StatefulSet.
Both components and traits are re-usable on any KubeVela systems, we can package components, traits along with the CRD controllers together as an addon. There're a growing catalog of addons in the community.
#
SummarizeThis blog introduces how to deliver complete modular capabilities through CUE. The core is that it can dynamically increase configuration capabilities according to user needs, and gradually expose more functions and usages, so as to reduce the overall learning threshold for users and ultimately improve R&D efficient. The out-of-the-box capabilities provided by KubeVela, including components, traits, policy, and workflow, are also designed as plugable and modifiable capabilities.