What is a custom resource definition?
The Kubernetes API is extended with new Custom Resource Definition (CRDs), which make it possible to create new resources. CRDs allow users to design their own resource types and controllers, whereas Kubernetes comes with a fixed predefined usable resource kind, such as pods, deployments, and offerings.
Using well-known Kubernetes tools and workflows, CRDs add additional API endpoints to the Kubernetes API server, enabling users to communicate with and manage their customised resources. Custom resources can be seamlessly integrated into the Kubernetes environment with this feature.
The core of Custom Resource Definition (CRDs) are custom resources. Within a Kubernetes cluster, they offer a means of delineating and illustrating novel abstractions. Software developers can incorporate complex logic and domain-specific capabilities into Kubernetes-native objects by using custom sources. Databases, message queues, machine learning models, and complete applications are just a few of the many things that it may be used to represent. By building unique resources that may benefit from the powerful tooling and extensive Kubernetes ecosystem, developers can effectively manage and run their bespoke abstractions.
Benefits of CRDs
Extensibility:
Custom Resource Definition (CRDs) help you add unique resources to Kubernetes that are suited to your particular application or infrastructure needs. This makes Kubernetes more natural and user-friendly by enabling you to develop declarative APIs and higher-level abstractions that correspond to the domain you’re working in.
Reusability
Custom Resource Definition (CRDs) provide a way to share and package your unique resources into parts that can be used again. By establishing CRDs, you facilitate code reuse and teamwork by providing a standardised method for others to interact with and consume your unique resources.
Consistency
You may establish dependable routines and procedures in your Kubernetes deployments by using CRDs. You may ensure that your deployments meet desired standards by implementing best practices, access controls, and unique validation criteria by encapsulating domain-specific logic and behaviour into custom resources.
Automation
Complex processes and workflows can be automated with the help of Custom Resource Definition (CRDs). You can use Kubernetes controllers to filter changes and respond appropriately by establishing custom resources. This automation reduces the possibility of human error, streamlines managerial duties, and increases operational effectiveness.
- Custom resource definitions also serve as a way to wrap complex software-level logical dependencies in bespoke asset definitions during the development stage, simplifying traditional control and reducing operational costs for improvement firms. Developers are able to construct several instances of a specific custom resource that they have previously established with the region’s custom beneficial resource definitions.
- For better participant participation, these resources can then be shared or moved to other teams or initiatives within the same organisation. Developers can also leverage the Kubernetes operators and custom controllers to automate the application lifecycle management process and integrate complex software common sense effects.
- Furthermore, a large user community is actively exchanging best practices, tools, and valuable insights on the use of CRDs due to the fact that custom beneficial resource definitions are heavily utilised inside the Kubernetes environment.
How To Create Custom Resources?
With Custom Resource Definition (CRDs) it can produce specialised resources to meet particular requirements. Let’s examine how to make a custom resource.
The resource’s structure and schema are specified using the YAML syntax. It may create unique resources that meet the needs of application and add objects to the Kubernetes API with the properties specified in the YAML configuration file.
The sample YAML code that may be used to define Custom Resources with the name MyApp and CRDs is provided below.
“`apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: myapps.sample.com
spec:
group: sample.com
version: v1
names:
kind: MyApp
singular: myapp
plural: myapps“`
It allows us to create instances by utilising own resources. Let’s make a unique resource.
It have some sample YAML files for creating CRDs in GitHub repository. It must execute the kubectl apply -f <filename>
in order to generate the CRDs. The output, which is displayed below, will be generated when the custom resources are executed.
![YAML files YAML files](https://media.geeksforgeeks.org/wp-content/uploads/20230424212202/crd1.png)
Here, it have uploaded the YAML file to GitHub and used the link to generate the custom resource rather than constructing it locally.
As you can see above, the resource’s name is derived from the <crd1.yaml` YAML file, which has the following appearance:
![The YAML file to GitHub and used the link The YAML file to GitHub and used the link](https://b3682738.smushcdn.com/3682738/wp-content/uploads/2025/01/image-37.png?lossy=1&strip=1&webp=1)
You can use the kubectl get crds
commands to obtain the list of custom resource definitions. The output will look like this:
![Kubernetes Custom Resource Definition Benefits & Use cases crds Lightbox](https://media.geeksforgeeks.org/wp-content/uploads/20230424212020/crds.png)
Use cases of CRDs
Consider a platform team developing a CI/CD and application hosting platform that oversees the full application lifecycle. IT teams use in-house techniques to deploy the application into the Kubernetes cluster using a pipeline that will build, test, and publish the application.
IT administrators can build specialised platform resources on top of Kubernetes by extending the Kubernetes API to specify custom resources. IT companies can create and utilise platforms through self-service activities since the APIs are declarative.
Let’s examine an example use case to demonstrate how to use Custom Resource Definitions (CRDs) on the Kubernetes API: Building an application CI/CD platform and making it available as a Kubernetes custom resource is the goal of the IT operations team. In order to develop and launch an application on top of Kubernetes, this custom resource needs user input. The minimal setup input is shown in the first section of the instruction below:
- The unique name of the application, expressed as a string identifier, is appId.
- Any established language that the framework supports, like C#, Python, or Go, is referred to as the code language.
- Only Windows or Linux are available as OS alternatives.
- For the spun-up pods, instanceSize should be “T-shirt size” with preset CPU and memory sizes (for example, “small” may indicate 100m CPU and 512 mebibyte RAM). Small, medium, and large values are all acceptable.
- The metadata known as environmentType categorises the app’s environment type. The values dev, test, and prod are acceptable.
- replicas, which should be set to one, is the bare minimum of app replicas that must be maintained.