What is a Custom Resource Definition (CRD)?
Learn what a Kubernetes CustomResourceDefinition is, how it extends the API, and why it needs a controller to do anything.
Expected Interview Answer
A CustomResourceDefinition (CRD) is a Kubernetes API extension mechanism that lets you register a brand-new resource type — with its own schema, kind, and API group — so the cluster's API server can store, validate, and serve custom objects the same way it does built-in resources like Pods or Deployments.
Once a CRD is applied, kubectl and the API server treat instances of that new “kind” as first-class citizens: you can create, get, list, watch, and apply RBAC and validation (via OpenAPI v3 schemas) to them exactly like any native resource. On its own, a CRD only defines structure and storage — it is inert data with no behavior, similar to adding a new table to a database schema. Behavior comes from a controller (often bundled as part of an Operator) that watches instances of the custom resource and reconciles the cluster toward whatever the resource's spec describes. This CRD-plus-controller pattern is how the vast Kubernetes ecosystem extends the API without ever modifying Kubernetes core code — cert-manager's Certificate resource, Istio's VirtualService, and Prometheus Operator's ServiceMonitor are all CRDs with dedicated controllers behind them.
- Extends the Kubernetes API without forking or patching core code
- Custom objects get native kubectl, RBAC, and validation support
- Provides the schema foundation the Operator pattern builds controllers on
- Enables ecosystem tools to expose domain-specific, declarative APIs
AI Mentor Explanation
A CRD is like a league officially registering a brand-new type of official match report — say a "Wash Out Report" — that referees can now file using the league's standard system, with defined fields like reason and rescheduled date. Registering the report type does not, by itself, cause anyone to act on it; it just means the league's filing system now recognizes and validates that report format alongside existing ones like injury reports. Only when a designated official is assigned to actually read new Wash Out Reports and reschedule matches accordingly does anything happen — that reading-and-acting role is separate from the report type itself. The report format and the person who acts on it are two distinct pieces, just like a CRD and its controller.
Step-by-Step Explanation
Step 1
Author the CRD manifest
Define the new kind, API group/version, and an OpenAPI v3 schema describing valid spec fields.
Step 2
Apply it to the cluster
kubectl apply registers the new resource type with the API server, which now stores and validates it.
Step 3
Create custom resource instances
Users can now kubectl apply/get/list objects of the new kind exactly like built-in resources.
Step 4
Pair it with a controller
A controller (often part of an Operator) watches instances and reconciles the cluster to match each spec — without this, the CRD is inert.
What Interviewer Expects
- Understanding that a CRD only defines schema/storage — it has no behavior on its own
- Ability to distinguish CRD (data structure) from Operator/controller (the logic that acts on it)
- Knowledge that CRDs get native kubectl, RBAC, and OpenAPI validation support
- Awareness of real-world CRD examples, e.g. cert-manager Certificate, Istio VirtualService
Common Mistakes
- Claiming a CRD alone performs actions in the cluster
- Confusing a CRD with a ConfigMap (unstructured data) rather than a typed, validated API resource
- Forgetting that a CRD needs a controller to actually be useful
- Not mentioning schema validation as one of the CRD's core benefits
Best Answer (HR Friendly)
“A CRD lets us teach the Kubernetes API about a brand-new type of object that is not built in, like a custom database cluster resource. On its own, defining the CRD just adds the schema so Kubernetes can store and validate that object type — the actual behavior comes from a separate controller that watches those objects and does the real work, which is why CRDs are usually paired with an Operator.”
Code Example
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: postgresclusters.databases.example.com
spec:
group: databases.example.com
names:
kind: PostgresCluster
plural: postgresclusters
singular: postgrescluster
scope: Namespaced
versions:
- name: v1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
version:
type: string
replicas:
type: integerFollow-up Questions
- What happens if you create a custom resource without a controller watching its CRD?
- How does OpenAPI v3 schema validation on a CRD prevent invalid resources?
- What is the difference between a CRD's “served” and “storage” version flags?
- How would you version a CRD schema without breaking existing custom resources?
MCQ Practice
1. What does applying a CRD to a cluster actually enable?
A CRD only registers the schema and storage for a new kind — it grants no automated behavior on its own.
2. What is required to give a CRD actual operational behavior?
A CRD is inert data on its own; a controller (often shipped as an Operator) provides the logic that acts on it.
3. Which real-world example is implemented as a CRD with a dedicated controller?
cert-manager registers a Certificate CRD and runs a controller that reconciles TLS certificate issuance for it.
Flash Cards
What does a CRD define? — A new resource kind's schema and API storage — no behavior on its own.
What gives a CRD actual behavior? — A controller (often part of an Operator) that reconciles instances of it.
What validates custom resource fields? — The OpenAPI v3 schema declared in the CRD.
Example CRD in the wild? — Istio's VirtualService or cert-manager's Certificate resource.