Custom Resource Definitions

Kubernetes ships with built-in resources: Pods, Deployments, Services, ConfigMaps. These cover general-purpose workloads. But what about a PostgreSQL cluster? A Kafka topic? A TLS certificate? An ML training job? These are domain-specific concepts that don't map cleanly to generic Kubernetes resources.

Custom Resource Definitions let you teach Kubernetes new concepts. After registering a CRD for "PostgresCluster," you can create, list, update, and delete PostgresCluster objects using kubectl, just like Pods or Deployments. The Kubernetes API server stores them in etcd, validates them against your schema, and exposes them through the standard API.

CRDs are what make Kubernetes infinitely extensible. They're why Kubernetes can be a platform for running databases, service meshes, CI/CD pipelines, ML workflows, and anything else, not just containers. Every Operator starts with a CRD.

Registering a CRD:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
 name: postgresclusters.db.example.com
spec:
 group: db.example.com
 names:
 kind: PostgresCluster
 plural: postgresclusters
 shortNames: ["pgc"]
 scope: Namespaced
 versions:
 - name: v1
 served: true
 storage: true
 schema:
 openAPIV3Schema:
 type: object
 properties:
 spec:
 type: object
 properties:
 instances:
 type: integer
 version:
 type: string

After registration, you can use it like any resource:

kubectl get postgresclusters
kubectl describe pgc my-database
kubectl apply -f my-database.yaml
kubectl delete pgc my-database

CRDs vs ConfigMaps for configuration: You could store database config in a ConfigMap, but CRDs give you validation (reject invalid configs at the API level), versioning (v1, v2 with conversion), status subresource (report database health back), and RBAC (control who can create databases vs who can create ConfigMaps).