Kubernetes CRDs

June 4, 2024

English

Priyansh Khodiyar

Share with friends

In this Kubernetes guide on Kubernetes CRD, we will dive deep into custom resource definitions in K8s, how they work, how to create one, how to use them, and much more.

Kubernetes CRDs - What Are They & How Can You Create One? cover image

In the ever-evolving landscape of containerized applications and microservices, Kubernetes has emerged as the most popular orchestration platform.

One of the key features that set Kubernetes apart is its extensibility, is that it allows the developers to tailor the platform according to their specific needs which leads to flexibility.

Kubernetes has some set of predefined objects, but what if you wanted that Kubernetes should be able to manage other things other than Kubernetes itself and the containers it manages?

This is where creating your own objects using Custom Resource Definitions (CRDs) comes into play. In this article, we dive deep into Kubernetes CRD, how they work, how to create one, and much more.

Before we get into Kubernetes CRDs, let's quickly look at how the Kubernetes API works.

The Kubernetes API

The Kubernetes API serves as the primary key, to communicating and managing your Kubernetes clusters. It provides you with the appropriate operations, resources, and tools through which you as developers and administrators can interact with the Kubernetes environment programmatically.

Operations: The Kubernetes API is designed according to the REST API principles.

It exposes resources as endpoints with corresponding HTTP methods (GET, POST, PUT, DELETE) to perform operations on those resources.

Resources: There are plenty of Kubernetes resources that the API provides, which represent a specific aspect of a cluster. Some are pods, services, config maps, etc.

All the Kubernetes resources are represented as objects.

All these objects have their specific JSON or YAML files which describe their configuration and state.

Objects also have metadata, including names, labels, and annotation which helps to identify them.

API Versions: Kubernetes resources may have different versions, each with its own API endpoint. API versions ensure compatibility when changes are introduced to resources over time.

These are the identical versions that you write in those yaml configurations of deployments and services. apiVersion: apps/v1.

What is Kubernetes Custom Resources (CR)?

Kubernetes Custom resources (CR) are a way to extend the Kubernetes API, by adding different new custom-made resource types for specific applications or use cases.

Kubernetes comes with a rich set of built-in resources like Pods, Services, and Deployments, but these may not cover all the unique needs of different applications.

Custom resources basically enable you to define your own resource types that are meaningful within your application's context.

It basically gives you full freedom to create a fully customized environment for your application, for instance, if your application needs any kind of databases or any other components then you can create Custom Resources to represent and manage them.

What are Kubernetes CRDs or Custom Resource Definitions?

Kubernetes CRDs allow you to introduce new object types into the Kubernetes ecosystem, beyond the built-in resources which are already listed in the Kubernetes API, like Pods, Services, and Deployments.

These custom resources sum up your application-specific configurations and state, enabling you to manage them just like any other Kubernetes resource.

Let's say you want to interact with a pod of yours called “chocolate”.

If you try the classic command (kubectl get) of Kubernetes to interact with this pod, you will encounter an error “error: the server doesn't have a resource type "chocolate".

kubectl get chocolate

“chocolate” is not a valid resource name that comes out of the box in the Kubernetes API.

For making this valid, you have to add “chocolate” as an object to your Kubernetes API using CRD.

I think you have enough of this theoretical knowledge, let's see some realistic examples.

How to Create a CRD in Kubernetes?

Let's say you have an application for managing your books.

In this Kubernetes CRD tutorial, let's create a CRD for a simple "Book" resource. Each book will have a title, author, and publication year.

Step 1: Create a YAML File

The first step is to create a YAML file which will be used to define your CRD. Name it “book-crd.yaml”.

Add the following content to this file and save it.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: books.example.com
spec:
  group: example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                title:
                  type: string
                author:
                  type: string
                year:
                  type: integer
                  minimum: 1000
  scope: Namespaced
  names:
    plural: books
    singular: book
    kind: Book

Step 2: Apply the Manifest File

The next step is to apply the manifest file with the following command:

kubectl apply -f book-crd.yaml

Step 3: Create Instances of CRD

After applying the manifest file, it's time to create some "book" instances.

Here's how to do it.

Create a YAML file for the "Book" instance, name it “book-instance-1.yaml” and use the following content:

apiVersion: example.com/v1
kind: Book
metadata:
  name: sample-book
spec:
  title: "The Example Book"
  author: "John Doe"
  year: 2024

And apply them using this command:

kubectl apply -f book-instance-1.yaml

You can create as many instances, as you want.

Now, you can retrieve the Book instance you created using the kubectl get command:

kubectl get books

Updation: For updating the book instance, you can edit the manifest file and then re-apply it.

Deletion: For deleting the book instance, you can use the following command:

kubectl delete book sample-book-1

The above kubectl delete command will work something like this:

What is the Use of Kubernetes CRDs?

Kubernetes Custom Resource Definitions (CRDs) are a powerful feature that enables you to extend the Kubernetes API and create custom resource types according to your application's specific requirements.

1. Managing Application-Specific Resources

CRDs allow you to define resources that align with your application's domain. For instance, you can create CRDs for databases, message queues, caches, and other components unique to your application.

2. Application Configuration

Kubernetes CRDs can be used to define application configuration settings that can be updated independently using the application's code. This separation of concerns enables easier configuration management.

3. Microservices and APIs

K8s CRDs can represent APIs or microservices, which will allow you to define APIs and their associated configurations within Kubernetes.

Now, let us look at how Kubernetes CRDs are different from Operators.

Kubernetes CRD vs Operator

Kubernetes Custom Resource Definitions and Operators may sound similar but they are quite different.

CRDs are a way to define custom resources in Kubernetes, which allows you to introduce new object types to the Kubernetes API except for the built-in ones like Pods and Services.

Operators

Operators are custom Kubernetes controllers that support CRDs to automate complex application management. They observe and act on CRD instances to ensure that the desired state is achieved and maintained.

Kubernetes Operators automate the management of custom resources using CRDs, while Kubernetes CRD defines a new resource type in Kubernetes.

Operator logic contains the business logic for managing resources based on CRD instances, while Kubernetes CRD describes the structure of these custom resources.

For instance, an operator that manages the provisioning, scaling, and backup of databases is represented by "Database" CRD instances.

In summary, Custom Resource Definitions (CRDs) enable the creation of new resource types, and Operators leverage those CRDs to automate the management of those resources.

With this, we have come to the end of the blog, and here is a cum TL;DR for you all.

TL;DR - Kubernetes CRD

To summarise it all, the Kubernetes API serves as the gateway to managing clusters, which offers a standardized interface.

Custom Resources (CRs) and Custom Resource Definitions (CRDs) empower us to extend Kubernetes, by introducing custom resource types.
CRDs serve as blueprints for CRs, creating a dynamic landscape of possibilities.
CRDs find purpose in managing application-specific objects and behaviors, enhancing automation and flexibility.
From creating CRDs to understanding their differences from Operators, ConfigMaps, and Helm, we've discovered a spectrum of tools.

Each serves unique purposes: CRDs define, Operators automate, ConfigMaps configure, and Helm packages applications. With this amalgamation, we leverage Kubernetes' true potential, making an K8s environment that uniquely suits our needs.