What is a Custom Resource Definition?

What's really being asked

Whether you understand that Kubernetes is extensible and that a CRD adds a new first-class resource type to the API server.

The full answer

A Custom Resource Definition is itself a Kubernetes object that registers a brand-new kind of resource with the API server. It specifies an API group, one or more versions, a kind name, scope (namespaced or cluster), and an OpenAPI schema for validation. Once applied, the API server begins storing, validating, and serving instances of that new kind, and you can manage them with kubectl get, describe, and apply just like Deployments or Services, including RBAC, labels, and watches. The problem it solves is representing domain-specific or application-specific concepts declaratively inside Kubernetes, for example a Database, a Certificate, or a Backup, without modifying or recompiling Kubernetes itself. Importantly, a CRD only defines the type and stores the data; it does not by itself do anything. To give a custom resource behavior you pair it with a controller or operator that watches instances and reconciles real-world state.

The mistakes people make

Thinking a CRD includes the logic that acts on the resource, confusing the CRD with the operator, or believing you must patch the Kubernetes source to add a resource type.

What usually comes next

How does a CRD differ from an aggregated API server? How do CRDs relate to operators? How do you version a CRD schema?

A concrete example

cert-manager ships a CRD for Certificate. Applying the CRD teaches the API server about Certificate objects, so kubectl get certificates works. The CRD alone stores the desired certificate spec; cert-manager's controller watches those objects and actually issues and renews TLS certificates, demonstrating the split between the type definition and the acting controller.