ConfigMaps
1. ConfigMaps
A ConfigMap in Kubernetes is an API object that stores configuration data as key-value pairs. It provides a mechanism to decouple application configuration from Pods, which means a Pod’s specifications are stored and maintained in one place and act as a single source of truth. This prevents configuration drift. ConfigMap can be used to store configuration files, command-line arguments, environment variables, port numbers, and other configuration artifacts and make them available inside containers. This makes applications more portable and manageable without requiring them to be Kubernetes-aware. Let’s explore an example where a ConfigMap named demo is created using literal values. You can add multiple key-value pairs, such as lab.difficulty=easy, and lab.resolution=high, and even view details of configMaps using kubectl or the Google Cloud console. Another way to create a ConfigMap is by using the from-file syntax. These files contain multiple key-values. Multiple files can be added to a ConfigMap, and it’s recommended that you check these files into a source code control system to maintain their versioning and history. Names can be specified for keys. As an alternative to using the source filenames, key names can be added. This syntax is very similar to the from-file syntax, but here an additional key value is inserted to rename the key used. Let’s say we have an example where the key value Color is added for the file called color.properties, and then the key value Graphics is added for the file called ui.properties. The contents of ConfigMaps can be verified using kubectl or the Google Cloud console. ConfigMaps can also be created from a manifest. The data is the same as in the previous examples. The kubectl apply command can be added to the manifest file and it will create the ConfigMap. Pods refer to ConfigMaps in three ways: as a container environment variable, in Pod commands, or by creating a Volume. For example, let’s say we have a single ConfigMap that is used in the Pod as a container environment variable. Within an env field in the YAML file, a container environment variable can be named as VARIABLE_DEMO. The values are retrieved using configMapKeyRef. Multiple variables can be added from the same or different ConfigMaps. After the container environmental variables are defined, they can be used inside Pod manifest commands. A dollar sign $ and an opening parenthesis ( is put in front of the environment variable’s name, and a closing parenthesis ) after it. This allows configuration artifacts to be decoupled from image content to keep containerized applications portable. As a result, the kubelet has no way to reach into the Pod and modify these values later. ConfigMap data can also be added into an ephemeral Volume. For example, let’s say a Volume named config-volume is created in the Volumes section, with a ConfigMap named demo. The result is that a ConfigMap Volume is created for this Pod. This means that all the data from the ConfigMap is stored in this ConfigMap Volume as files, and then this Volume is mounted to the container by using the mountPath directory. When a ConfigMap Volume is already mounted and the source ConfigMap is changed, the projected keys are eventually updated.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.