Hello, readers! This article talks about Custom Resource Definition in Kubernetes with a detailed demonstration.
So, let us begin!! 🙂
What is a Custom Resource in Kubernetes?
Kubernetes offers us the concept of resources that actually happens to be the endpoint of the Kubernetes API. It enables us to store the information about an API object of a specific type in Kubernetes. For example, the resource replicaset stores information about the collection of replica sets in Kubernetes.
On similar lines, a custom resource in Kubernetes is a way of defining customized resources for the installation of the software pieces. It is like an extension to the default resource. Thus we can customize a particular type of Kubernetes resource to an extent with the custom resources.
Once the Kubernetes administrator installs the custom resource, we can make use of kubectl to install the resources within it like any other usual resource such as pods, deployments, etc.
Advangates of a Custom Resource in Kubernetes
- When we wish to make use of Kubernetes Client libraries or CLI for the creation or patching of a resource, this is when we should make use of a custom resource.
- It provides top-notch support from Kubernetes through the kubectl command-line tool.
- A custom resource is a good choice if we plan to build a new API.
- Using a Custom resource makes our created API a declarative one.
- The resources created under the custom resource type can restrict by a cluster or namespace scope.
- We can reuse Kubernetes API support features with Custom resources.
- We can customize the application by integrating custom resource with the basic language.
Using CustomResourceDefinition in Kubernetes
With CustomResourceDefinition API, we can easily use and define a custom resource. The API handles the storage of any custom resource altogether.
When we define a CustomResourceDefinition object, it will create a custom resource according to the details of the schema.
Benefits of using a CustomResourceDefinition:
- They are handled directly by an API server.
- We won’t need to handle multiple versions of the API.
- Any other generic bug is picked up and fixed as a part of master upgrade.
- With the enabled features, it performs arbitrary checks while performing any operation.
- It has strong integration with horizontal pod auto scaling and pod disruption budgets as well.
Creating a CRD in Kubernetes
Let us now move ahead and create a CustomResourceDefinition for any custom resource.
Have a look at the below YAML.
apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: # name must match the spec fields below, and be in the form: <plural>.<group> name: crontabs.stable.example.com spec: # group name to use for REST API: /apis/<group>/<version> group: stable.example.com # list of versions supported by this CustomResourceDefinition versions: - name: v1 # Each version can be enabled/disabled by Served flag. served: true # One and only one version must be marked as the storage version. storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: cronSpec: type: string image: type: string replicas: type: integer # either Namespaced or Cluster scope: Namespaced names: # plural name to be used in the URL: /apis/<group>/<version>/<plural> plural: crontabs # singular name to be used as an alias on the CLI and for display singular: crontab # kind is normally the CamelCased singular type. Your resource manifests use this. kind: CronTab # shortNames allow shorter string to match your resource on the CLI shortNames: - ct
In the above YAML, we have specified the kind as CustomResourceDefinition to create objects of kind CronTab. Usually, the CRD is cluster scoped as well as namespaced. In our case, we have restricted the scope to Namespace.
After a few minutes, the CustomResourceDefinition will be enabled and thus it makes us eligible to create resources of kind CronTab.
Moving ahead, we can now create resources of kind CronTab which will abide by the functionality maintained by the CustomResourceDefinition.
By this, we have approached the end of this topic. Feel free to comment below, in case you come across any questions.
For more such posts related to Kubernetes, Stay tuned with us.
Till then, Happy Learning!! 🙂