CustomResourceDefinition(CRD)
An API extension mechanism that lets you define new resource types in Kubernetes, treated like built-in objects by the API server.
Also known as: CRD
What is CustomResourceDefinition?
A CustomResourceDefinition (CRD) extends the Kubernetes API with new resource types defined by users or software. Once a CRD is registered, Kubernetes automatically creates a new API endpoint for the resource type (e.g., /apis/databases.example.com/v1/postgresclusters), handles CRUD operations via the API server, stores instances in etcd, and makes them available through kubectl and the Kubernetes API just like built-in resources. CRDs are the foundation of the Operator pattern.
CRD schemas are defined using OpenAPI v3 schema validation, which the API server uses to validate and reject invalid custom resource instances at admission time. Versioning (v1, v1beta1, v1alpha1) allows CRDs to evolve over time with conversion webhooks handling transformation between versions. CRDs can also define additional printer columns (shown by kubectl get), status subresources (for separate status updates), and scale subresources (enabling HPA support).
Installing a CRD cluster-scoped: CRD objects themselves are cluster-scoped, but instances can be either namespace-scoped or cluster-scoped depending on the CRD's scope field. Deleting a CRD deletes all instances of that resource type cluster-wide — a destructive operation that should be preceded by backing up all CR instances.
Example
# List all CRDs installed in the cluster
kubectl get crds
# Describe a CRD to see its schema
kubectl describe crd postgresclusters.databases.example.com
# List all instances of a custom resource
kubectl get postgresclusters --all-namespaces
# View a custom resource in detail
kubectl get postgrescluster my-db -n production -o yamlCost & Waste Implications
Each custom resource instance is stored in etcd. Clusters with many operators and many CR instances can experience etcd storage pressure, degrading API server performance. More directly, CRD instances created by operators (certificates, database clusters, Kafka topics) often represent real cloud resources (disks, load balancers, cloud databases) that continue billing even after the application using them is torn down.
How KorPro Helps
KorPro tracks custom resource instances alongside built-in Kubernetes resources, identifying orphaned CRD instances that represent undeleted cloud resources and estimating their ongoing cost.
Scan Your Cluster FreeRelated Terms
Kubernetes Operator
OperationsA custom controller that encodes operational knowledge for a specific application, extending Kubernetes with domain-specific automation.
Read definitionControl Plane
Core ConceptsThe set of components that store cluster state, schedule workloads, and run controllers to maintain desired state.
Read definitionHelm
OperationsThe Kubernetes package manager that bundles resource manifests into versioned, configurable charts installable with a single command.
Read definitionOrphaned Resource
FinOpsA Kubernetes resource that is no longer referenced by any active workload but continues to exist in the cluster, often incurring cost.
Read definitionStop Wasting Money on Orphaned Kubernetes Resources
KorPro connects to your clusters across GCP, AWS, and Azure — no agents, no installation — and surfaces every orphaned resource with its monthly cost estimate.