Kubernetes · Orchestration under pressure

What are CustomResourceDefinitions and how do you use them safely?

MediumcrdsapiextensibilityUpdated Oct 2026

Short answer

CRDs extend the Kubernetes API with new resource types. They need schemas, versioning and usually a controller, and a poorly designed CRD becomes a long-lived compatibility burden.

A CRD registers a new kind, group and version with the API server. Once installed, users can create and read custom resources with kubectl and RBAC like built-in objects. Structural schemas validate fields, and status subresources separate desired state from observed state.

Always define an OpenAPI schema; otherwise invalid data reaches your controller
Plan versions and conversion before shipping v1
Use the status subresource for observed state and conditions
Deleting a CRD deletes all its custom resources
CRDs are cluster-scoped API extensions, even when their instances are namespaced

yaml

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: backups.example.com
spec:
  group: example.com
  scope: Namespaced
  names:
    plural: backups
    singular: backup
    kind: Backup
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                schedule:
                  type: string

CRDs are an API contract. Once users and automation depend on a version, removing it requires a migration plan. Use conversion webhooks for structural changes, add conditions and events for observability, and keep the schema strict enough to reject nonsense but flexible enough to evolve.

Installing a CRD does not give it behaviour. Without a controller, custom resources are inert stored objects that can mislead users into thinking work is happening.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

1What happens when you delete a CRD?
2Why is a structural schema important?
3How do you evolve a CRD across versions?
4What is the status subresource for?

Say it in the interview

A CRD extends the API with a new kind, and instances are stored and validated by the API server. I always add a structural schema, plan versions, and use the status subresource for observed state. The CRD itself is just the type; behaviour comes from a controller. Because it is a public API contract, I treat versioning and deletion as long-term compatibility decisions.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Kubernetes mock interview and get scored feedback on depth, clarity and confidence.

Start a free Kubernetes interview Browse all questions

Follow-ups you should expect

Related questions

Now say it out loud.