Summary
A CRD (Custom Resource Definition) is a Kubernetes extension mechanism that allows operators and platform teams to introduce new resource types into the Kubernetes API, enabling domain-specific abstractions to be managed natively by Kubernetes.
What is a CRD?
Kubernetes ships with built-in resource types such as Pods, Deployments, and Services. A Custom Resource Definition allows teams to define entirely new resource types that Kubernetes treats with the same lifecycle management as built-in resources — create, read, update, delete, and watch.
CRDs are the foundation for the Kubernetes Operator pattern. Once a CRD is registered, a controller (operator) can watch for instances of that custom resource and reconcile the desired state — for example, provisioning a database cluster when a Database custom resource is created.
CRDs are widely used in platform engineering to expose higher-level abstractions to developers. Instead of dealing with raw Kubernetes primitives, a developer might create an Application or Environment resource that a platform-level operator then translates into the appropriate underlying infrastructure.
Why is a CRD relevant?
- Extensibility: CRDs allow any team to extend Kubernetes with domain-specific APIs without modifying the core codebase
- Operator pattern: CRDs are the building block for Kubernetes Operators that automate complex stateful application management
- Platform abstractions: Platform engineering teams use CRDs to expose developer-friendly APIs on top of Kubernetes