Custom Resource Definitions (CRDs)

The integrated resources in Kubernetes, such as pods, services, and volumes, provide everyday functions for common-use instances. However, you can not use them on your precise and unique requirements. This is wherein CRDs come into the picture.

As the popularity of Kubernetes maintains to grow, so does the need for customizing and extending its competencies. CRDs stands for Custom Resource Definition. The name is self-explanatory. You can use CRDs to construct your custom resource when you have a particular requirement or use case no longer blanketed by means of the integrated resources. Custom Resource Definitions (CRDs) have emerged as a powerful mechanism to outline custom resources inside a Kubernetes cluster. In this article, we are able to explore CRDs, their importance, and how they empower developers and operators to create custom resources tailored to their needs.

What Are Custom Resource Definitions (CRDs)?

Custom Resource Definitions (CRDs) are extensions to the Kubernetes API that enables the creation of custom resources. While Kubernetes comes with a fixed predefined useful resource kind as pods, deployments, and offerings, CRDs permit customers to create their own resource types and controllers.

CRDs introduce new API endpoints to the Kubernetes API server, which allows customers to interact with and control their custom resources through the use of familiar Kubernetes tools and workflows. This feature lets in the seamless integration of custom resources into the Kubernetes ecosystem. 

Custom resources are the heart of CRDs. They provide a way to outline and represent new abstractions within a Kubernetes cluster. With custom sources, software developers can encapsulate complicated logic and domain-specific capability into Kubernetes-native objects. It can be used to represent many different concepts, which include databases, message queues, machine learning models, or entire applications. Developers may successfully manage and operate their custom abstractions by creating custom resources that can take advantage of the robust tooling and rich Kubernetes ecosystem.

Benefits of CRDs

Let’s discuss the benefits of CRDs for Kubernetes users:

• Extensibility: CRDs assist you to extend Kubernetes with custom resources tailored to your specific application or infrastructure requirements. This empowers you to create higher-level abstractions and declarative APIs that match the domain you’re working in, making Kubernetes more intuitive and user-friendly.
• Reusability: CRDs offer a mechanism to package and distribute your custom resources as reusable components. By defining CRDs, you create a standardized way for others to consume and engage along with your custom resources, promoting code reuse and collaboration throughout teams.
• Consistency: CRDs enable you to set up consistent patterns and practices within your Kubernetes deployments. By encapsulating domain-specific logic and behavior into custom resources, you could implement best practices, implement access controls, and follow specific validation rules, making sure that your deployments adhere to desired standards.
• Automation: CRDs facilitate the automation of complicated operations and workflows. By defining custom resources, you can leverage Kubernetes controllers to screen modifications and take action accordingly. This automation simplifies management tasks, improves operational efficiency, and decreases the potential for human errors.

At the development stage, custom resource definitions also work as a mechanism for wrapping intricate software-level logical dependencies within bespoke asset definitions – streamlining traditional control and lowering operational overheads among improvement companies. With custom beneficial resource definitions in the region, developers can create more than one instance of a particular custom resource that they previously defined.

These resources can then be transferred or shared with different teams or programs within the equal company for improved collaboration among participants. The Kubernetes operators and custom controllers can also be used by developers to integrate complicated software common sense effects while facilitating automation throughout the application’s lifecycle management process.

Moreover, because of the truth that custom beneficial useful resource definitions are significantly utilized inside the Kubernetes environment, there exists a big community of users eagerly sharing high-quality practices, tools, and precious insights on the usage of CRDs.

How To Create Custom Resources?

We can create custom resources to fulfill our unique needs using CRDs. Let’s look into the steps to create a custom resource.

We use the YAML syntax to specify the structure and schema of the resource. The attributes defined within the YAML configuration file enable us to add objects to the Kubernetes API and build unique resources suited to our application’s requirements.

Given below is the sample YAML code, which can be used to define Custom Resources named MyApp with CRDs.

```


apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: myapps.sample.com
spec:
group: sample.com
version: v1
names:
 kind: MyApp
 singular: myapp
 plural: myapps

```

We can make use of our custom resources for creating instances using it. Let’s create a custom resource

In this GitHub repository, we have some sample YAML files to create CRDs. To create the CRDs, we need to run the `kubectl apply -f <filename>`. On executing the custom resources will get created with an output as shown below. 

kubectl apply

Here instead of creating the YAML file locally, we have pushed the YAML file to GitHub and used the link to create the custom resource.

If you notice above, the name of the resource is based on the YAML file `crd1.yaml` which looks like this:

custom resource definition

To get the list of custom resource definitions, you can run the `kubectl get crds` commands, which will give an output as shown below:

kubetcl get crds

How to create instances of custom resources?

Creating Instances of Custom Resources:  We can use kubectl or another Kubernetes client to create instances of the custom resources, also called custom objects. These unique objects can represent various things, including programs, services, databases, or other things pertinent to the deployed application.

How can you create instances using custom resources? Let’s look at a sample YAML file below, which can be used to create an instance of the custom resource `MyApp.`

```

apiVersion: example.com/v1
kind: MyApp
metadata:
name: myapp-1
spec:
# under this, we can specify the custom configuration for MyApp

```

Our sample YAML file to create an instance based on the above custom resource looks like this:

Create instance from CRDs in Kubernetes

We will run the kubectl create command to create the instance, which will give an instance-created message as output. To get the list of resources of our custom type we can make use of the command `kubectl get <custom_resource_name>`. Here our custom resource name is crontab, so the command is `kubectl get crontab`.

Create instances from CRDs

After successfully creating an instance of custom resources, we have to manage the whole lifecycle of the custom resources.

Managing the Lifecycle of Custom Resources

Lifecycle management of custom resources includes creation, updation, and deletion. CRDs help us to specify use lifecycle activities that can be performed, such as create, update, and delete. We can conduct these activities on the custom resources using kubectl or other Kubernetes tools, just like any other Kubernetes object.

Let’s look into some commands we can use to manage the resource life cycle.

The `kubectl create -f myapp.yaml` command is used to create a custom resource. We used this command to create the instance.

Sometimes it happens that we need some updates in my custom resources. Can we change the custom resource specification? So the answer is yes we can update the resource file.

We can use the `kubectl apply -f myapp.yaml` command to easily update a custom resource. 

If we don’t want a custom resource, we can delete the same using the `kubectl delete myapp myapp-1` command. After deleting the resource if you check the list, you will find it empty, as the resource has been deleted. Here, the resource name is crontab, and the instance name is my-new-cron-object, so the command to delete becomes `kubectl delete crontab my-new-cron-object`.

delete custom resources in Kubernetes

You can also delete the custom resource using the delete command instead of apply, as shown below:

delete CRDs in Kubernetes

Conclusion

In conclusion, Custom Resource Definitions (CRDs) are a vital feature in Kubernetes, which enables customers to extend and customize the platform. CRDs provide extensibility, reusability, consistency, and automation advantages, allowing customers to create domain-specific resources and enhance their Kubernetes deployments. By leveraging CRDs, customers can harness the power of Kubernetes to build resilient, scalable, and efficient systems tailored to their requirements. Understanding and using CRDs is key to unlocking the full potential of Kubernetes for various use cases.