In the Kubernetes API, a resource is an endpoint that stores a collection of API
objects of a certain kind. For example, the built-in Pods resource contains a
collection of Pod objects.
A Custom Resource Definition (CRD) object defines a new, unique object
in the cluster and lets the Kubernetes API server handle its entire lifecycle.
Custom Resource (CR) objects are created from CRDs that have been added to
the cluster by a cluster administrator, allowing all cluster users to add the
new resource type into projects.
When a cluster administrator adds a new CRD to the cluster, the Kubernetes API
server reacts by creating a new RESTful resource path that can be accessed by
the entire cluster or a single project (namespace) and begins serving the
Cluster administrators that want to grant access to the CRD to other users can
use cluster role aggregation to grant access to users with the
view default cluster roles. Cluster role aggregation allows the insertion
of custom policy rules into these cluster roles. This behavior integrates the
new resource into the cluster’s RBAC policy as if it was a built-in resource.
Operators in particular make use of CRDs by packaging them with any required
RBAC policy and other software-specific logic.
Cluster administrators can also add CRDs manually to the cluster outside of an
Operator’s lifecycle, making them available to all users.
While only cluster administrators can create CRDs, developers can create the CR
from an existing CRD if they have read and write permission to it.