Kubernetes Custom Resource Definition (CRDs)
In the IT world, we mayn’t get always what we are want, especially with opensource, as there will be some feature still missing. If it is enterprise application or in-house, we have some option to get the feature enabled by request. With opensource, we should customize what we are looking for (if the tool/software supports). Like that even in Kubernetes, though it gives wide range of solutions, still there will be some custom change required. For that Kubernetes has enabled Custom Resource Definition from version 1.7, this enables user to create their own/custom objects to the Kubernetes cluster and define the kind just like pod, deployment, etc.
In this post, lets discuss about custom resource definition (CRD), what CRDs are, how to use and create it.
What is a Custom Resource Definition (CRD)
As we mentioned above in the Kubernetes API, a resource is an endpoint that stores a collection of API objects of a certain kind. The standard Kubernetes distribution comes with lot of inbuilt API objects/resources. For example, the built-in pods’ resource contains a collection of Pod objects. CRD comes when we want to introduce our own object into the Kubernetes cluster to fulfil our custom requirements. Once we create a CRD in Kubernetes we can use it like any other native Kubernetes object thus leveraging all the features of Kubernetes like its CLI, security, API services, RBAC etc.
The custom resource created is also stored in the etcd cluster with proper replication and lifecycle management. This is a powerful way to extend Kubernetes capabilities beyond the default installation. Also, it allows us to extend Kubernetes capabilities by adding any kind of API object useful for our application. This is a powerful way to extend Kubernetes capabilities beyond the default installation.
How to create a CRD
The manifest below shows an example CRD crd.yaml, You can modify it based on your need or understanding.
- name: v1
description: foxcrd is the foxutech custom resource definition
description: 'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
description: 'Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
description: foxcrdsSpoc is the spec for a foxcrds resource
description: foxcrdsStatus is the status for a foxcrds resource
Let’s explain what the CRD above will create:
- The first two lines defines what the apiversion is and we are saying we want to create a custom resource definition.
- The metadata field helps us define what the name of the resource is. In our case foxcrds (plural).
- Spec group help us define what the group name will be.
- Spec version helps us define the version. In our case we are versioning it as v1.
- As you can see, we can define a version of our CRD and only one version can be a storage version at a time, so keep that in mind. We then made sure that this CRD is a namespaced and not cluster wide. This allows us to create the CRD for either just a specific namespace or for the whole cluster.
- Next, we defined what the singular and plural name of our CRD will be.
- Lastly, we defined the kind name and the 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/*/foxcrds/
You can check the api-resources using following command,
Please continue reading on Kubernetes Custom Resource Definition (CRDs) — FoxuTech.