Standardizing the Kubernetes infrastructure to give Devs the ease and Ops the freedom
This article is about one of the few implementations of an amazing and crucial concept for a fast-paced development environment, the Open Application Model (OAM).
OAM is a concept that promotes the idea of developers focussing completely on their application and not on the knowledge of underlying infrastructure. It states that the approach should be application-first, extensible, and run-time agnostic. You can read more about it here.
Coming back to our topic, the implementation of OAM that I am talking about here is KubeVela. I mentioned it briefly in my last post on Crossplane and thought that this is the right time to go deeper into it.
To get started with KubeVela, simply follow the installation steps.
For managing resources with more ease, you can optionally install vela CLI. For a Mac system, you can simply use
brew like so
brew install kubevela
Once you have vela CLI ready, you can install the core components (CRDs) on your cluster simply by running
vela install --version v1.4.2
If you wish to skip the vela CLI, you can also install it directly using helm like so
helm repo add kubevela https://charts.kubevela.net/core
helm repo update
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.4.2 --wait
You should see an output like the following:
As part of the installation, a few CRDs are installed.
There’s quite a lot of stuff here but we’ll focus on the highlighted ones only.
Application is what the developer would be creating, containing only the details specific to the application and its configuration. There would be no Kubernetes resources mentioned in this file. Let us create one for ourselves below:
To create a custom
componentdefinitionyou don’t have to start from scratch. Use an existing Kubernetes manifest and run
vela def init (more details here).
If you look at one of these component definition YAMLs, you’ll see that they have a
schematic block which can be written in cue, Kube, or helm.
I personally prefer cue due to its flexibility but it comes at a cost of learning a whole language. If you don’t want to do that, go for helm or Kube. Also, if you’re familiar with Kustomize, Kube might come easy to you (it’s standard Kubernetes manifest with parameterization).
Lastly, we have the option to extend an existing
componentdefinition. You can use it for say, adding horizontal pod autoscaling to the existing webservice application you created above.
TraitDefinition resource would also be defined quite similarly to
componentdefinition in terms of
schematic section with a template code written under it. One difference here would be
appliesToWorkloads which will define when to trigger this trait. In our case, it would be with deployments, so it would look something like this: