资料内容:

Custom Resources

CRs, as extensions of the Kubernetes API, contain one or more fields, like a native

resource, but are not part of a default Kubernetes deployment. CRs hold structured

data, and the API server provides a mechanism for reading and setting their fields as

you would those in a native resource, by using kubectl or another API client. Users

define a CR on a running cluster by providing a CR definition. A CRD is akin to a

schema for a CR, defining the CR’s fields and the types of values those fields contain.

CR or CongMap?

Kubernetes provides a standard resource, the ConfigMap (https://oreil.ly/ba0uh), for

making configuration data available to applications. ConfigMaps seem to overlap

with the possible uses for CRs, but the two abstractions target different cases.

ConfigMaps are best at providing a configuration to a program running in a pod on

the cluster—think of an application’s config file, like httpd.conf or MySQL’s mysql.cnf.

Applications usually want to read such configuration from within their pod, as a file

or the value of an environment variable, rather than from the Kubernetes API.