Environment Variables vs. Volume Mounts
Once you've created a ConfigMap or Secret, your application inside the Pod needs to access it. There are two primary mechanisms, each with distinct trade-offs:
Method 1: Environment Variables
Inject individual keys as environment variables into the container at startup — either one at a time, each pulling a specific key from a ConfigMap or Secret by reference, or all at once by referencing the whole ConfigMap and importing every key it contains.
Pros: Simple. Works with any application without code changes — every language can read environment variables.
Cons: Environment variables are set at container startup and are immutable for the life of the Pod. If you update the ConfigMap or Secret, the running Pod will not see the change until it is restarted. Also, environment variables are visible to all processes in the container and can appear in crash dumps or logs.
Method 2: Volume Mounts
Mount the ConfigMap or Secret as files into a directory inside the container — a volume backed by the ConfigMap or Secret, mounted at a chosen path. Each key in the ConfigMap or Secret becomes a file in the mounted directory. For example, app-config's LOG_LEVEL key becomes the file /etc/config/LOG_LEVEL with the value as its contents.
Pros: Kubernetes automatically updates the mounted files when the ConfigMap or Secret is changed, typically within 60 seconds — without restarting the Pod. This enables live configuration reloads.
Cons: Your application must be written to watch the config files for changes and reload itself (e.g., using inotify or a polling loop). Many legacy applications don't support this.
Choosing between them: Use environment variables for simple key-value config in applications you don't control (third-party containers). Use volume mounts for config files and for any application that supports hot-reloading, especially in production where you want to change config without a rolling restart.