Custom resources are defined as extensions of the Kubernetes API. In this article, we will discuss when you should add a custom resource to your Kubernetes cluster and when you should use a standalone service. It describes the two methods for adding custom resources and how to choose between them.
CRD Concepts In K8S
In order to understand what CRD is, you must have an understanding of some basic concepts in Kubernetes which includes resource and custom resource.
• Resource: It is an endpoint in Kubernetes API that permits you to store an API object of any kind.
• Custom Resource: It permits you to create your own API objects and define your own kind just like Pod, Deployment, ReplicaSet, etc.
Custom resources let you extend the Kubernetes capabilities by adding any type of API object useful for your application. It is a powerful way to extend Kubernetes capabilities beyond the default installation.
How Can You Create A CRD?
The manifest mentioned below shows an example CRD crd.yaml
apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: name: appconfigs.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true scope: Namespaced names: plural: appconfigs singular: appconfig kind: AppConfig shortNames: - ac
Now, let’s have a look at the explanation of what will be created by the above CRD:
• In the first two lines, it is explained that what the apiversion is and that we want to create a custom resource definition.
• With the help of the metadata field, we define what the name of the resource is. In this case it is appconfigs (plural).
• We use the Spec group to define the name of the group.
• Spec version defines the version. As mentioned above our version is V1 which means that we want this to be our storage version.
• Kubernetes allows you to define a version of our CRD and only one version can be a storage version at a time. You have to make sure that CRD is namespaced and it should not be cluster wide. This permits you to create the CRD for either just a specific namespace or for the whole cluster.
• Moving further, we defined the singular and plural name of our CRD.
• In the end, we defined the kind name and short name. We can then create it with “kubectl create -f crd.yaml”. The new namespaced RESTful API endpoint for our CRD will be found at /apis/stable.example.com/v1/namespaces/*/appconfigs/
Now you must be wondering how can this be useful for you? To put the above CRD in use, we will create a manifest using the kind we created with the CRD. Let’s take an example of my-kind.yamlhere.
apiVersion: "stable.example.com/v1" kind: AppConfig metadata: name: demo-appconfig spec: uri: "some uri" Command: "some command" image: my-image
As it is evident from the above example that we used the kind we defined in our CRD, then we defined the fields we want to have for our kind object. Here we wish to define the uri, command and image of our app. Now, in case we run “kubectl create -f my-kind.yaml” our application can consume the data we created using the manifest above. To see the results, we can run “kubectl get ac -o yaml”, this will reveal the detailed information on what we just created. Here, notice how we are using the short name (ac) we previously defined in our CRD.
How Can You Delete A CRD?
Deleting a CRD and the resources we created is a simple process in which you just need to run kubectl delete just like with any other resources. It is essential to know that the above CRD is just data that can be stored and retrieved; hence, it doesn’t give us a fully declarative API. In order to make this resource fully declarative, we can add a custom controller, which is responsible to ensure that the current and the desired state are always in sync. You can take replication controller as an example here.
Final Note
To conclude, CRD is a way to extend K8s which allows us to create a custom resource we wish and make it declarative with the help of a custom controller.
