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:
Simply apply this manifest like so:
And now if you check the resources, you’ll see quite a few of them created for you based on just this code.
But how did I know what all resources I want to create?
For this, take a look back at line number 8 of that manifest. We mentioned
webservice as the type of our application. This brings us to the next CRD
There are several predefined
componentdefinitions you can use. You can list them like so:
The one we used,
webservice, is a long-running, scalable, containerized service that has a stable network endpoint to receive external traffic from customers. And hence, it creates a deployment (long-running and scalable) with a stable network endpoint (service and ingress).
There’s plenty of other
componentdefinitions you can use but say you have a requirement that isn’t solved by any. Say you have to make some additions to one of them? Or make a new one altogether? Well, both are possible.
To create a custom
componentdefinition, you 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:
Note that the parameters have a default value
min : 1,
max : 10 and
cpuUtil : 50 which means that the user may or may not pass them in the application definition file.
Just to add, given how efficiently all the resources are packed together in one application, the clean-up is just as easy.
Now, if you check the resources using
kubectl get all,ingress
You won’t find any of these.
OAM, in my eyes at least, is the kind of standardization we need in the DevOps community. And KubeVela is a great example of how it will benefit us.
I should mention that there is one downside of this tool. The documentation wasn’t originally written in English, but was translated into English. So, it’s just not as good as you’d expect.