ConfigMaps

ConfigMaps — Configuration Data

A ConfigMap stores non-sensitive configuration data as key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or configuration files in a volume.

ConfigMaps separate configuration from your container images, making your applications more portable and easier to update.

Creating ConfigMaps

# From literal values
kubectl create configmap my-config \
  --from-literal=database_host=mysql \
  --from-literal=database_port=3306

# From a file
kubectl create configmap my-config --from-file=config.properties

# From a directory (each file becomes a key)
kubectl create configmap my-config --from-file=configs/

# YAML definition
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  database_host: mysql
  database_port: "3306"
  config.properties: |
    app.name=my-app
    log.level=debug

Using ConfigMaps as Environment Variables

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: app
      image: my-app
      envFrom:
        - configMapRef:
            name: my-config
      # Or map individual keys
      env:
        - name: DB_HOST
          valueFrom:
            configMapKeyRef:
              name: my-config
              key: database_host

Using ConfigMaps as Files

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
    - name: app
      image: my-app
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: my-config

This creates files at /etc/config/database_host, /etc/config/database_port, etc. Each key becomes a filename.

ConfigMap Best Practices

Do not store secrets — ConfigMaps are not encrypted. Use Secrets for sensitive data.

Use immutable ConfigMaps — Set immutable: true to prevent accidental changes.

Keep config separate from code — Update ConfigMaps without rebuilding images.

Version your ConfigMaps — Use naming conventions like my-config-v2 to track changes.