Custom Resources: Define and Use a CRD

Kubernetes lets you add your own resource types to its API. A CustomResourceDefinition (CRD) registers a new kind — say Widget — and from that moment the API server treats Widget like any built-in: kubectl get widgets, kubectl apply, RBAC, labels, kubectl explain, the lot. No code, no rebuild of anything.

A CRD has a few required decisions:

• group and kind — acme.example / Widget — which together name the API (acme.example/v1, kind: Widget).
• plural name — widgets — used in URLs and kubectl get widgets. The CRD's own name must be <plural>.<group>.
• scope — Namespaced (lives in a namespace, like a Pod) or Cluster (like a Node). You choose once; changing it means recreating the CRD.
• a version (v1) that is served (reachable over the API) and, for exactly one version, storage: true (the form persisted in etcd).
• a schema (openAPIV3Schema) — in apiextensions.k8s.io/v1 this is required. It's how the API server validates your resources, rejecting bad fields at admission.

This is the foundation every operator is built on: the CRD defines the nouns, a controller supplies the verbs. Here you define the noun and use it directly.

Useful aliases

In your terminal, k is aliased to kubectl and completion is configured. The jumpbox also has k9s, jq and yq installed.