Kubernetes ConfigMap Builder

Build Kubernetes ConfigMaps without YAML mistakes

A ConfigMap decouples configuration from your container image so the same image can run in dev, staging, and production with different settings. This builder lets you assemble both simple environment-style key-value pairs and full multi-line config files, then emits a valid v1 ConfigMap manifest you can apply directly with kubectl.

How it works

ConfigMaps store all data under a data: map. Simple values become single-line YAML scalars, while a multi-line file (such as an nginx.conf or application.properties) must be written as a YAML block scalar so newlines are preserved. The builder uses the | block scalar indicator and indents every line, which is exactly how kubectl create configmap --from-file renders it.

Keys and values are quoted automatically when they could be misread by a YAML parser — for example a value of true, a number like 8080, or a string starting with a special character. This avoids the classic bug where enabled: true is parsed as a boolean instead of the string Kubernetes expects.

Two ways to consume a ConfigMap in a pod

As environment variables

Use envFrom to inject every key as an environment variable, or valueFrom to pull a specific key:

envFrom:
  - configMapRef:
      name: my-config

Or for a single key:

env:
  - name: LOG_LEVEL
    valueFrom:
      configMapKeyRef:
        name: my-config
        key: log.level

As mounted files (volume)

Mount the ConfigMap as a directory, where each key becomes a filename and its value becomes the file’s content:

volumes:
  - name: config-volume
    configMap:
      name: my-config
containers:
  - volumeMounts:
      - name: config-volume
        mountPath: /etc/myapp/config

This pattern is ideal for multi-line config files like nginx.conf, application.yaml, or .env files that your application reads from disk.

YAML quoting rules that catch teams out

The builder quotes values that YAML would otherwise misinterpret:

Kubernetes mostly handles these gracefully when reading from etcd, but misconfigured YAML can produce silent errors in some controllers.

Tips and notes

• Keys consumed as environment variables must be valid env-var names (letters, digits, underscores). File-style keys may contain dots, like app.properties.
• To load every key as an env var, use envFrom with a configMapRef instead of listing each valueFrom individually.
• Set immutable: true for config that never changes after deployment — it improves cluster performance and prevents accidental edits.
• ConfigMaps are namespaced, so the name only needs to be unique within its namespace.
• Never store secrets (passwords, tokens, API keys) in a ConfigMap — use a Secret object instead, which is base64-encoded and can be encrypted at rest.