Kubernetes

What are Kubernetes CRDs, and should you be bothered about them?

Learn everything about Kubernetes CRDs, ranging from learning about Custom Resources (CR), Custom Resource Definitions (CRDs), How to create a CRD, How to set up a CRD, various Operations in a CRD,

What are Kubernetes CRDs, and should you be bothered about them?

What are Kubernetes CRDs?

Kubernetes provides a robust declarative API system, where the cluster operators specify the record of intent or desired state via the REST API or a YAML file. The controllers operate in a control loop to converge intent with the observed state.

The Kubernetes resources often function as follows at a high level:

  • The creation and preservation of a record of purpose in the data store; and
  • Constantly active controllers read these records and then add, update, or delete resources.

A Kubernetes resource is a group of related objects that may be accessed via the Kubernetes API. By default, Kubernetes includes several resources, including replica sets, deployments, and pods.

Before we proceed to Kubernetes CRDs, we must first understand Kubernetes CR, i.e. Custom Resources.

Custom Resources (CR)

Kubernetes API extensions are custom resources. Custom resources, however, may not always be accessible in a Kubernetes installation that is set up by default.

Customised resources are instead dynamically registered to a cluster. Like users interact with built-in resources like pods, deployments, and services, end users can create, update, and delete a custom resource's object using kubectl after it has been registered.

Small, internal configuration objects called "custom resources" are defined declaratively since they lack matching controller logic.

Custom Resource Definitions

The Custom Resource definition (CRD) was added to Kubernetes 1.7 and is a powerful feature.

Numerous built-in API resources and objects are included in the default Kubernetes release. CRDs allow IT, administrators, to add particular types or objects to the Kubernetes cluster to satisfy their specific needs. A Kubernetes CRD behaves precisely as any other Kubernetes object would: it uses all the ecosystem's tools, including CLI, security, API services, and role-based access control. The custom resource is likewise kept in the etc. cluster with appropriate lifetime management and replication. CRDs also do away with the overhead of implementation that is self-directed.

CRDs are nothing more than data blobs on their own; their primary use is to offer a way to build, expose and store Kubernetes API objects with data that meets any requirements that aren't automatically satisfied. CRDs don't have any particular behaviour or logic; once they've been removed, changed, or added, they don't do anything independently.

Implementing operators or controllers would provide these customised resources with more sophisticated capabilities. These allow IT, administrators, to modify Kubernetes' behaviour without changing the underlying code. The interaction between this functionality and CRDs makes it possible for IT teams to develop some rather sophisticated capabilities and features.

The Kubernetes API is made available by the API server, which is a part of the Kubernetes control plane. The Kubernetes control plane's front end is the API server. However, the apiextensions-apiserver module in kube-apiserver is responsible for handling CRD operations. This module is integrated into kube-apiserver and is not a distinct process.

Now, we will explore the primary use case of Kubernetes CRD.

Consider a platform team developing a CI/CD platform and application hosting system that controls the full application lifecycle. To deploy the application into the Kubernetes cluster using custom patterns, we need to build a pipeline that creates, tests, and publishes the application.

IT administrators can build subjective platform resources on top of Kubernetes by extending the Kubernetes API to specify custom resources. IT organisations can use and create platforms through self-service activity since the APIs are declarative.

We will now explore how to create a CRD on Kubernetes.

CRD is a table. When creating a table, we must provide its format, including the column types and names. These elements are in JSON or YAML  format in the CRD file.

In CRD, the Custom Resource (CR) defines all the values for a record in JSON or YAML format.

CRD formats

The CRD format is split into three sections:

General part: The name CRD is included in the metadata along with mandatory fields of name, kind, and apiVersion.

Example: (name: “vegetable-crd”)


Table level information: Consists of the table name, simpler command lines name in lower case, and name in the plural form.

Example: (kind: “Vegetable”), (simpler: “vegetable”), (plural: “vegetables”)

Column level information: Consists of column type, column name, and nested object.

Example/format: (“boolean”, “string”, “integer”, “object”), (“bitterness”), (props: <columns and child object name>)

Now that we have covered the basic formats of CRD, let us discuss the various steps of creating a CRD.

Setting up a CRD in Kubernetes

A really simple way of creating or generating a CRD would be only to write a “Table” definition and an Operator. 

Installing Table definition to Kubernetes

A CRD table can be simply created using pairs of column names with their types.

Example:

Installing operator to generate CRD (optional)

This step is optional and depends on whether you want to do the generation manually or use a pre-defined operator to perform the generation for you automatically.

To install a pre-defined operator, use the following command:

kubectl apply -f 
{pre-defined operator url}

Use this command to verify that the pod is operating after the Operator has been successfully installed:

kubectl get pod -n pod_name-system
NAME                                         READY   STATUS    RESTARTS   AGE
pod_name-controller-manager-10gbf76b2f-fwey6   2/2     Running   0          7s

Sample generated CRD:

Now that we have seen how to create a CRD, let us explore some of the operations of Kubernetes CRD.

The primary operations in CRD are:

  • Creating a table
  • Creating a record
  • Getting a list of records
  • Getting a record
  • Deleting a record

Let us now explore each one of them briefly.

Creating a table

Use the following command to create a table in CRD (syntax)

kubectl create -f table_name.yaml

Example

kubectl create -f vegetable.yaml

NOTE: This is similar to the following SQL command -

CREATE TABLE table_name;

Creating a record

Use the following command to create a record in CRD (syntax)

kubectl create -f record_name.yaml

Example

kubectl create -f brinjal.yaml

Getting a list of records

Use the following command to get a list of records in CRD (syntax)

kubectl get table_name

Example

kubectl get vegetables

Getting a record

Use the following command to get a record in CRD (syntax)

kubectl get table_name record_name

Example

kubectl get vegetable brinjal

Deleting a record

Use the following command to delete a record in CRD (syntax)

kubectl delete table_name record_name

Example

kubectl delete fruit apple

Conclusion

In this article, we explored Customer Resouce Definitions (CRDs) and Custom Resources(CRs)  in Kubernetes and the use cases of CRDs. We also discussed the various CRD formats, how to set up a CRD using Table definition and Operator, and the various operations we may perform after successfully creating a Kubernetes CRD.

Diksha B Patro
/
September 12, 2022