Your application's performance can hinge on its configuration, which, naturally, may evolve along with your needs. If your application architecture is merged with your configuration, then changing certain settings would mean having to rebuild your mirror file—an inconvenient predicament. Enter the 'ConfigMap' component. Designed to separate your application and configuration, ConfigMap effectively eliminates the need to rebuild your mirror file every time you tweak a setting.
ConfigMap works by storing key-value pairs of configuration data, which can either take the form of individual properties or entire configuration files. It's a lot like the 'Secret' component, except it's better suited to handling strings that don't contain sensitive information.
API Version Compatibility Table
Kubernetes Version
Core API Version
Creating a ConfigMap
You can enlist the help of kubectl create configmap to create a ConfigMap from a file, directory or a key-value string. Alternatively, kubectl create -f file can be used to make a ConfigMap from a file.
You can incorporate ConfigMap into your 'Pod' via three different methods, either by setting environment variables, setting container command line parameters, or by directly mounting files or directories in 'Volume'.
Note
ConfigMap must be created before a Pod can reference it
Invalid keys will be automatically ignored when using envFrom
A Pod can only use ConfigMap within the same namespace
Mount ConfigMap as File or Directory in Volume Directly
You can directly mount the created ConfigMap unto a Pod’s /etc/config directory. Here, each key-value pair would generate a file—with the key as the filename and the value as the content.
You can also mount this key, special.how, to a relative path /keys/special.level within the /etc/config directory. Any file with the same name would be directly overwritten, while all other keys are left unmounted.
Additionally, ConfigMap supports mounting multiple keys in the same directory or multiple directories. For instance, in the example below, special.how and special.type are doubly mounted to /etc/config and special.how is also mounted to /etc/config2.
# ls /etc/config/keys/special.levelspecial.type# ls /etc/config2/keys/special.level# cat /etc/config/keys/special.levelvery# cat /etc/config/keys/special.typecharm
Using Subpath to Mount ConfigMap as Individual File to Directory
In general, congfigmap will mount its content as a file after first overwriting the mounted directory. If you want to avoid overwriting files under the original folder, and just want to mount each key from configmap as a file to the directory, you can use the subpath parameter.
When a cluster includes a large number of ConfigMap and Secret, a myriad of watch events can intensely boost the load on kube-apiserver and hasten the spread of configuration errors throughout the entire cluster. In this scenario, marking ConfigMap and Secret that don't require frequent modifications as immutable: true can sidestep this issue.
Principal benefits of immutable ConfigMap include:
Safeguarding your application from the adverse effects of accidental updates.
Amping up your cluster performance by drastically curbing the pressure on kube-apiserver, as Kubernetes ceases to monitor operations on immutable ConfigMap.