How to Use ConfigMap to Inject Configuration into Kubernetes Pods

ConfigMap is a Kubernetes API object that stores configuration data for other objects. Unlike most objects that use a spec block, ConfigMap stores key‑value pairs in a data block, and its name must be a valid DNS subdomain.

Creating a ConfigMap

You can create a ConfigMap that contains simple key‑value pairs or multi‑line file‑like values. The keys become the configuration names, and the values are the configuration content.

Referencing ConfigMap in a Pod

In a Pod definition, add a spec that references the ConfigMap. The Pod and ConfigMap must reside in the same namespace. Below is a sample Pod manifest that demonstrates both environment variable injection and volume mounting:

apiVersion: v1
kind: Pod
metadata:
  name: configmap-demo-pod
spec:
  containers:
  - name: demo
    image: game.example/demo-game
    env:
      # Environment variable from ConfigMap
      - name: PLAYER_INITIAL_LIVES
        valueFrom:
          configMapKeyRef:
            name: game-demo
            key: player_initial_lives
      - name: UI_PROPERTIES_FILE_NAME
        valueFrom:
          configMapKeyRef:
            name: game-demo
            key: ui_properties_file_name
    volumeMounts:
    - name: config
      mountPath: "/config"
      readOnly: true
  volumes:
    # Mount ConfigMap as a volume
    - name: config
      configMap:
        name: game-demo

The ConfigMap does not differentiate between single‑line values and file‑like values; the important part is how Pods consume them. By defining a volume that points to the ConfigMap, the files become available inside the container at /config, creating files such as:

/config/player_initial_lives

/config/ui_properties_file_name

/config/game.properties

/config/user-interface.properties

If you need to ensure that only files with a .properties extension appear in /config, you can use two separate ConfigMaps and reference both in the Pod spec. The first ConfigMap provides player_initial_lives and ui_properties_file_name, while the second supplies the actual .properties files.

Note: The most common use of ConfigMap is to configure containers running in a Pod within the same namespace, but ConfigMaps can also be used independently, for example by plugins or operators that adjust their behavior based on ConfigMap data.

This example demonstrates a practical way to separate configuration from application code, enabling consistent behavior across local development (e.g., DATABASE_HOST=localhost) and cloud deployments (e.g., referencing a Service endpoint).