KubeVela takes Application as the basis of modeling, uses Components and Traits to complete a set of application deployment plans. After you are familiar with these core concepts, you can develop in accordance with the user manual and administrator manual according to your needs.
In modeling, the YAML file is the bearer of the application deployment plan. A typical YAML example is as follows:
The fields here correspond to:
- apiVersion: The OAM API version used.
- kind: of CRD Resourse Type. The one we use most often is Pod.
- metadata: business-related information. For example, this time I want to create a website.
- Spec: Describe what we need to deliver and tell Kubernetes what to make. Here we put the
- components: KubeVela's component system.
- Traits: KubeVela's operation and maintenance feature system, works in component level.
- Policies: KubeVela's application level policy.
- Workflow: KubeVela's application level deployment workflow, you can custom every deployment step with it.
KubeVela has some built-in component types, you can find them by using KubeVela CLI:
The output shows:
If you're a platform builder who's familiar with Kubernetes, you can learn to define your custom component to extend every kind of component in KubeVela. Especially, Terraform Components is one of the best practice.
KubeVela also has many built-in traits, search them by using KubeVela CLI:
The result can be:
You can learn how to bind trait by these detail docs, such as ingress trait.
If you're a platform builder who's familiar with Kubernetes, you can learn to define your custom trait to extend any operational capability for your users.
Policy allows you to define application level capabilities, such as health check, security group, fire wall, SLO and so on.
Policy is similar to trait, but trait works for component while policy works for the whole application.
In KubeVela, Workflow allows user to glue various operation and maintenance tasks into one process, and achieve automated and rapid delivery of cloud-native applications to any hybrid environment. From the design point of view, the Workflow is to customize the control logic: not only simply apply all resources, but also to provide some process-oriented flexibility. For example, the use of Workflow can help us implement complex operations such as pause, manual verification, waiting state, data flow transmission, multi-environment grayscale, and A/B testing.
The Workflow is based on modular design. Each Workflow module is defined by a Definition CRD and provided to users for operation through K8s API. As a "super glue", the Workflow module can combine any of your tools and processes through the CUE language. This allows you to create your own modules through a powerful declarative language and cloud-native APIs.
Especially, workflow works in application level, if you specify workflow, the resources won't be deployed if you don't specify any step to deploy it.
If you're a platform builder who's familiar with Kubernetes, you can learn to define your own workflow step by using CUE.
Here are some recommended next steps: