concept custom resource in category kubernetes
This is an excerpt from Manning's book Kubernetes in Action.
Then, when creating pods, you specify the same resource name and the requested quantity under the resources.requests field in the container spec or with --requests when using kubectl run like you did in previous examples. The Scheduler will make sure the pod is only deployed to a node that has the requested amount of the custom resource available. Every deployed pod obviously reduces the number of allocatable units of the resource.
An example of a custom resource could be the number of GPU units available on the node. Pods requiring the use of a GPU specify that in their requests. The Scheduler then makes sure the pod is only scheduled to nodes with at least one GPU still unallocated.
As the Kubernetes ecosystem evolves, you’ll see more and more high-level objects, which will be much more specialized than the resources Kubernetes supports today. Instead of dealing with Deployments, Services, ConfigMaps, and the like, you’ll create and manage objects that represent whole applications or software services. A custom controller will observe those high-level objects and create low-level objects based on them. For example, to run a messaging broker inside a Kubernetes cluster, all you’ll need to do is create an instance of a Queue resource and all the necessary Secrets, Deployments, and Services will be created by a custom Queue controller. Kubernetes already provides ways of adding custom resources like this.
To define a new resource type, all you need to do is post a CustomResourceDefinition object (CRD) to the Kubernetes API server. The CustomResourceDefinition object is the description of the custom resource type. Once the CRD is posted, users can then create instances of the custom resource by posting JSON or YAML manifests to the API server, the same as with any other Kubernetes resource.