kubectl Treats Custom Resources Like Native Ones

WHY IT EXISTS: Kubernetes needs a way to manage new, non-standard types of resources introduced by operators and other extensions. To maintain a consistent user experience, the standard command-line tool, kubectl, must be able to interact with these new resources without being recompiled.

THE MENTAL MODEL: Think of Custom Resources as plugins for the Kubernetes API. Once a Custom Resource Definition (CRD) is registered, kubectl treats the new resource type (like a Prometheus or a CronTab) just as it treats built-in resources like Pod or Deployment. The verbs are the same: get, describe, edit, apply, delete.

HOW IT WORKS: When you run a command like kubectl get myresource, kubectl first queries the Kubernetes API server to discover available resource types. If a CRD for myresource exists, the API server confirms it's a valid type. kubectl then proceeds to list, create, or modify objects of that type by sending standard API requests. The API server, in turn, forwards these requests to the custom controller or operator responsible for managing that resource. You don't need to install a special kubectl plugin for every CRD.

WHEN TO USE IT: Use standard kubectl commands whenever you need to inspect or manipulate a Custom Resource installed in your cluster. This is the primary, intended way to perform manual operations on CRs, such as checking the status of a database managed by an operator or manually deleting a specific instance.

WHEN NOT TO USE IT: Avoid manually editing (kubectl edit) Custom Resources managed by a GitOps tool like Argo CD or Flux, as your changes will be overwritten. For complex, multi-object operations, it's better to use the tool that manages the CR (like Helm or a specific operator CLI) rather than manipulating individual resources with kubectl.

ONE CANONICAL EXAMPLE: If you install the Prometheus Operator, it creates a CRD for a Prometheus resource. To see all Prometheus server instances it manages, you don't need a special command. You simply run kubectl get prometheuses -n monitoring. To inspect the details of one, you'd use kubectl describe prometheus main -n monitoring.