Creating an instance of a custom resource

WHAT THIS TESTS Whether you understand that a custom resource is created exactly like a built-in object once its CRD is registered, and that apiVersion must reference the custom group.

A GOOD ANSWER COVERS Once the CRD is applied and established, you create an instance by writing a normal Kubernetes manifest and running kubectl apply -f manifest.yaml or kubectl create -f. The manifest needs four things: apiVersion set to the CRD's group and version, such as batch.example.com/v1 rather than just v1; kind matching the CRD's declared kind, here CronJob; a metadata block with at least a name and optionally a namespace if the CRD is namespaced; and a spec whose fields conform to the schema the CRD defines. A minimal manifest might read: apiVersion batch.example.com/v1, kind CronJob, metadata name my-job, spec with schedule set to a cron expression and an image. The API server validates the spec against the CRD's OpenAPI schema and rejects unknown or wrongly typed fields. You can then list instances with kubectl get cronjob.batch.example.com.

COMMON WRONG ANSWERS Using apiVersion v1 without the custom group, applying before the CRD is registered (which fails with no matches for kind), or assuming a controller exists to act on it when only the type is defined.

LIKELY FOLLOW-UPS How does the API server validate the spec? What happens if no controller watches it? How do short names and categories get defined?

ONE CONCRETE EXAMPLE With a CronJob CRD in group batch.example.com version v1 registered, you write a file containing apiVersion batch.example.com/v1, kind CronJob, metadata name nightly-report, and a spec with schedule "0 2 * * *" and image reporter:1.0. Running kubectl apply -f nightly.yaml creates the object, and kubectl get cronjob nightly-report confirms it, though it does nothing until a matching controller reconciles it.