Double-check the schema section in your CRD — the structure must match exactly.
apiVersion: stable.example.com/v1 kind: DatabaseBackup metadata: name: nightly-backup spec: backupSchedule: "0 2 * * *" retentionDays: 7 Apply it: g/co/crd/setup
April 14, 2026 Reading time: 5 minutes Introduction If you’ve been working with Kubernetes for a while, you’ve likely heard about Custom Resource Definitions (CRDs). They allow you to extend Kubernetes’ API and create your own resource types, just like pods or services. Double-check the schema section in your CRD —
apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: databasebackups.stable.example.com spec: group: stable.example.com versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: backupSchedule: type: string retentionDays: type: integer scope: Namespaced names: plural: databasebackups singular: databasebackup kind: DatabaseBackup shortNames: - dbb Use kubectl to apply your CRD: apiVersion: apiextensions
kubectl apply -f my-resource-crd.yaml To follow the g/co/crd/setup pattern, you could wrap this in a script or Makefile:
kubectl get crd | grep databasebackups kubectl explain databasebackup You should see your new resource type available. Now that the CRD exists, create an instance of your custom resource ( my-backup.yaml ):
Now go ahead, create your first custom resource, and extend your cluster’s API with confidence.