資料內(nèi)容:
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.
