According to the official documentation, we have the definition of custom resources as follow:
"A resource is an endpoint in the Kubernetes API 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 is an extension of the Kubernetes API that is not necessarily available in a default Kubernetes installation. It represents a customization of a particular Kubernetes installation. However, many core Kubernetes functions are now built using custom resources, making Kubernetes more modular.
Custom resources can appear and disappear in a running cluster through dynamic registration, and cluster admins can update custom resources independently of the cluster itself. Once a custom resource is installed, users can create and access its objects using kubectl, just as they do for built-in resources like Pods."
Declare and Create CRD
CRD is more like the class in object oriental programming, and CR is more like the instance of the class. Below is an example from official K8s documentation:
crontab-crd.yaml
apiVersion:apiextensions.k8s.io/v1beta1kind:CustomResourceDefinitionmetadata:# name must match the spec fields below, and be in the form: <plural>.<group>name:crontabs.stable.example.comspec:# group name to use for REST API: /apis/<group>/<version>group:stable.example.com# list of versions supported by this CustomResourceDefinitionversions: - name:v1# Each version can be enabled/disabled by Served flag.served:true# One and only one version must be marked as the storage version.storage:true# either Namespaced or Clusterscope:Namespacednames:# plural name to be used in the URL: /apis/<group>/<version>/<plural>plural:crontabs# singular name to be used as an alias on the CLI and for displaysingular:crontab# kind is normally the CamelCased singular type. Your resource manifests use this.kind:CronTab# shortNames allow shorter string to match your resource on the CLIshortNames: - ct
metadata.name must be match the spec fields with <plural>.<group>
spec :
group : Naming a group is the first thing you want to do when you are to implement CRD, because you do not want to overlap with existing core group. In your own API group, you could have as many resoureces as you want, and they may have the same name as may exist in other API group
versions : You could support multiple versions of custom resources you have developed. But only one must be marked as the storage version. See K8s official documentation for more details.
versions: - name:v1beta1# Each version can be enabled/disabled by Served flag.served:true# One and only one version must be marked as the storage version.storage:true - name:v1served:truestorage:false
scope : The CRD can be either namespaced or cluster-scoped. <TBA>
names : This section is very straight forward, just need to follow the naming convention
Create the CRD
kubectl apply -f crontab-crd.yaml
customresourcedefinition.apiextensions.k8s.io/crontabs.stable.example.com created
kubectl get crd crontabs.stable.example.com -o yaml
kubectl caches discovery content by default for 10 minutes, using the ~/.kube/cache/discovery directory. Also, it can take up to 10 minutes for kubectl to see a new resource, such as the CRD we defined above. However, on a cache miss—that is, when kubectl can not identify the resource name in a command—it will immediately re-discover it.
If you open another terminal and run kubectl delete ct my-new-cron-object to delete the CRD object you just created, you will see the live console output.