United States

Understanding Custom Resource Definitions (CRDs) in Kubernetes

Understanding Custom Resource Definitions (CRDs) in Kubernetes

Overview

Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. Kubernetes provides a robust and scalable framework for running distributed systems resiliently, allowing for declarative configuration and automation.

When it comes to the Kubernetes API, its extensibility allows you to customize the cluster’s behavior without altering the core code. Kubernetes includes various objects representing common application components like pods, jobs, ConfigMaps, and secrets.

However, if you need to define application-specific data, for example Database, while maintaining its structure and enabling custom behavior, Custom Resource Definitions (CRDs) are the solution.

Kubernetes custom resource definitions (CRDs) let you add new object types to the Kubernetes API.

In this blog, I will describe you about CRD. The goal here is to help you to understand the basics of customer resource definitions (CRDs) and how to begin creating your own CRDs.

Exploring Custom Resources

Custom Resources (CRs) in Kubernetes allow you to extend the Kubernetes API that let you introduce your own resource types. By defining custom resources, you can manage and interact with your application-specific objects as if they were native Kubernetes resources. To create a custom resource, you use a Custom Resource Definition (CRD). Once you apply the CRD to your cluster, Kubernetes will recognize your custom resource.

Controllers and Operators are having an important part in the custom resource. To make custom resources functional, you typically need to write a controller.

A Kubernetes controller keeps an eye on resource types and performs tasks to achieve desired state changes which means It ensures that the resource’s current state matches what you want it to be.

Operators in Kubernetes are specialized extensions for applications, offering controllers and CRDs that automate tasks within your cluster, like deploying applications and managing maintenance tasks such as backups, scaling, migrations.

Keep in mind that this is just a broad summary. Developing a controller or operator requires significant coding effort, careful management of edge cases and so on.

Let’s delve into CRDs

Custom Resource Definitions (CRDs) in Kubernetes enable users to extend the Kubernetes API, adding functionality and capabilities beyond the built-in features. CRDs provide a flexible mechanism. Each CRD you create receives its own API endpoints, allowing you to query, create, and modify instances of that resource. Custom resources are fully integrated with kubectl and manage your own application’s objects.

Let you create custom resources in Kubernetes, allowing custom solutions to specific application needs.

Defining a Custom Resource Definition (CRD)

Let’s create a CRD for a custom resource called ‘CustomDatabase’, which can be used to manage database instances within a Kubernetes cluster.

Define the CRD

Here we are creating a crd named ‘database-crd.yaml’, with the following content:
image

 

Here, the name of the ‘kind’ defined as ‘CustomDatabase’. Along with this, you can see ‘versions’, where version number is been mentioned as ‘v1’ and there consist of two properties such as ‘served’ and ‘storage’.

‘served’ property means you can have multiple versions of the CRD. Also note that, there can be only one definition that can be served at a time. So, for this property, it is set as ‘true’ which is to be specify that this version of the definition is to be going to be served.

storage’ property which specifies that what type of resource instances will be stored into the Kubernetes database.
Next, we can see there mentioned the ‘scope’. It defines where does this custom resource definition instances will be created such as want to be created in a particular namespace or available globally. 

Now, let’s look at the main part of the definition which is ‘schema’.  It defines the structure and validation rules for the custom resource. Here ‘schema’ section defines how the ‘CustomDatabase’ custom resource should be structured and what types of values are expected for its fields.

Apply the CRD


Apply the CRD using kubectl:

kubectl apply -f database-crd.yaml
 

Create a Custom Resource (CR)

Now you can create an instance of the ‘CustomDatabase’ resource which can be named as ‘database-instance.yaml’ :

image

 

Here, the object ‘metadata’ which specifies the name of my custom resource definition instance.

Apply the custom resource:

 

kubectl apply -f database-instance.yaml

 

Verify the Custom Resource

Now use the above kind and query Kubernetes.

kubectl get customdbs
kubectl get customdb app1-database -o yaml

image

 

Conclusion

In conclusion, Custom Resource Definitions (CRDs) in Kubernetes provide a powerful way to extend the Kubernetes API and manage custom resources within your cluster.

Controllers and operators play a crucial role in managing these custom resources. Controllers are responsible for reconciling the state of the cluster, while operators build on this concept to manage more complex application-specific logic.

If you’re looking to dive deeper into these topics or need assistance with your Kubernetes journey, feel free to contact us at stackgenie. Our expertise can help to guide you.

Kittu Sabu
Kittu Sabu

I'm an experienced Technical Consultant who's worked in the IT industry for a while. I know my way around Web Servers, Bash scripting, Red Hat Linux, MySQL, Virtualization, and Openstack. I earned a Diploma in Engineering, focusing on Electronics and Communications Engineering from Govt Polytechnic College, Ezhokone. I'm passionate about finding smart solutions and making technology work for people.

Related Posts