kubernetesconfigPractitioner

Mastering ConfigMaps: The Key to Dynamic Kubernetes Configurations

5 min read Kubernetes DocsApr 28, 2026Reviewed for accuracy

Practitioner — Hands-on experience recommended

ConfigMaps exist to solve a fundamental problem in application deployment: the need to separate environment-specific configurations from container images. This decoupling makes your applications more portable and easier to manage across different environments. By using key-value pairs, ConfigMaps store non-confidential data that can be consumed in various ways, such as environment variables, command-line arguments, or configuration files in a volume.

When a Pod is launched, the kubelet utilizes the data from the ConfigMap. If the ConfigMap is updated, the projected keys in mounted volumes are eventually refreshed, as the kubelet checks for freshness during periodic syncs. You can also create immutable ConfigMaps starting from v1.19, which prevents changes after creation, adding an extra layer of stability for your configurations.

In production, remember that ConfigMaps do not provide secrecy or encryption; use Secrets for confidential data instead. They also have a size limitation of 1 MiB, so avoid storing large data sets. If you're mounting a ConfigMap as a subPath volume, be aware that updates won't propagate to the container. These nuances are critical for ensuring that your applications run smoothly and securely in a Kubernetes environment.

Key takeaways

→Understand that ConfigMaps store non-confidential data in key-value pairs.
→Utilize ConfigMaps to decouple environment-specific configurations from container images.
→Remember that updates to mounted ConfigMaps are eventually reflected, but subPath mounts won't receive updates.
→Use immutable ConfigMaps for configurations that should not change after creation.
→Avoid using ConfigMaps for sensitive data; opt for Secrets instead.

Why it matters

In production, effectively managing configurations with ConfigMaps can significantly enhance your application's portability and reduce deployment errors. This leads to smoother operations and quicker iterations in your development cycle.

Code examples

YAML

apiVersion:v1kind:ConfigMapmetadata:name:game-demodata:# property-like keys; each key maps to a simple valueplayer_initial_lives:"3"ui_properties_file_name:"user-interface.properties"# file-like keysgame.properties:|enemy.types=aliens,monstersplayer.maximum-lives=5user-interface.properties:|color.good=purplecolor.bad=yellowallow.textmode=true

YAML

apiVersion:v1kind:Podmetadata:name:configmap-demo-podspec:containers:-name:demoimage:alpinecommand:["sleep","3600"]env:# Define the environment variable-name:PLAYER_INITIAL_LIVES# Notice that the case is different here# from the key name in the ConfigMap.valueFrom:configMapKeyRef:name:game-demo# The ConfigMap this value comes from.key:player_initial_lives# The key to fetch.-name:UI_PROPERTIES_FILE_NAMEvalueFrom:configMapKeyRef:name:game-demokey:ui_properties_file_namevolumeMounts:-name:configmountPath:"/config"readOnly:truevolumes:# You set volumes at the Pod level, then mount them into containers inside that Pod-name:configconfigMap:# Provide the name of the ConfigMap you want to mount.name:game-demo# An array of keys from the ConfigMap to create as filesitems:-key:"game.properties"path:"game.properties"-key:"user-interface.properties"path:"user-interface.properties"

YAML

apiVersion:v1kind:Podmetadata:name:env-configmapspec:containers:-name:appcommand:["/bin/sh","-c","printenv"]image:busybox:latestenvFrom:-configMapRef:name:myconfigmap