8 Configuring applications with ConfigMaps and Secrets

Use the container’s command and args fields. They are array values that mirror Dockerfile’s ENTRYPOINT (command) and CMD (args):

• command replaces the image’s ENTRYPOINT.
• args replaces the image’s CMD.
• The final command line is command + args (concatenated).
• Example: set command: ["node","--cpu-prof","--heap-prof","app.js"] or just override args: ["--listen-port","9090"].

Define env under each container with name/value pairs. Quote anything YAML might misinterpret (numbers, true/false, yes/no, on/off, null, etc.). You can reference other manifest-defined variables using $(VAR_NAME), but only if the referenced variable appears earlier in the same env list. To keep a literal $(VAR_NAME), write $$(VAR_NAME).

Yes, but not with $(VAR_NAME). That syntax only resolves variables defined earlier in the manifest. To expand variables from the image or OS (e.g., HOSTNAME), run your command through a shell and use $VAR or ${VAR}, for example command: ["sh","-c","echo Hostname is $HOSTNAME; sleep infinity"].

A ConfigMap stores non-sensitive key–value pairs for configuration and can be consumed as environment variables or mounted as files. Create it via:

• kubectl create configmap NAME --from-literal key=value
• --from-file key=file or a whole directory
• --from-env-file file.env (key=value per line)
• From YAML (kind: ConfigMap, data: …, binaryData: …). Non‑UTF‑8 content goes in binaryData (Base64-encoded).

Keys may contain alphanumerics, dashes, underscores, and dots.

Two ways:

• Single key: env[].valueFrom.configMapKeyRef{name: CM, key: K, optional: true|false}
• All keys: envFrom[].configMapRef{name: CM, optional: …}

Notes:

• envFrom injects every entry; you can set a prefix. Keys must already be valid env var names (no key renaming).
• If the same variable is set multiple times, env (explicit entries) take precedence over envFrom; among multiple envFrom entries, later ones win.
• If optional is false (default) and the CM/key is missing, the container won’t start until it exists.

For values consumed as environment variables, running containers do not update in place. New/restarted containers will pick up the new values. Deleting a referenced ConfigMap leaves running containers unaffected, but any restart will fail to start if the reference isn’t optional. To guarantee consistency and reduce API server load, consider immutable: true on the ConfigMap; create a new CM for changes.

Both store key–value pairs, but Secrets are designed for sensitive data:

• Fields: Secrets use data (Base64) and stringData (write-only plain text). ConfigMaps use data (plain text) and binaryData (Base64).
• Secrets can have a type (e.g., Opaque, kubernetes.io/tls, dockerconfigjson, etc.).
• Kubernetes treats Secrets specially: only sent to nodes that need them and kept in memory on nodes.

Create with kubectl create secret (generic, tls, docker-registry) or from a YAML manifest.

It works, but it’s not ideal. Environment variables can leak via logs, error reports, or child processes. Prefer mounting Secrets as files via a secret volume. Remember: Base64 is encoding, not encryption; enable etcd encryption at rest, restrict access with RBAC, rotate secrets yourself (no automatic rotation), and consider external secret managers (e.g., Vault) for robust control.

Use env[].valueFrom.fieldRef.fieldPath with supported fields, for example:

• POD_NAME: metadata.name
• POD_IP: status.podIP (or podIPs)
• NODE_NAME: spec.nodeName
• NODE_IP: status.hostIP (or hostIPs)

The Downward API also supports projecting metadata into files via a downwardAPI volume (covered alongside volumes).

Use env[].valueFrom.resourceFieldRef. Examples:

• limits.cpu → MAX_CPU_CORES
• limits.memory → MAX_MEMORY_KB with divisor: 1k (or 1, 1Ki, 1Mi, etc.)

By default, the enclosing container’s resources are used; set containerName if you need another container’s values.