Projected Volumes: Mount Config as Live Files

WHY IT EXISTS: Managing configuration via environment variables is common but has a major limitation: they are immutable for the life of a container. To change an environment variable, you must restart the Pod. Projected volumes provide a way to push configuration updates to running Pods without a restart.

THE MENTAL MODEL: Think of a projected volume as a magical, self-updating folder inside your container. You tell Kubernetes, "Take the 'database-url' key from my 'app-config' ConfigMap and make it a file named db.url inside the /etc/config folder." Kubernetes handles creating and, more importantly, updating that file for you when the ConfigMap changes.

HOW IT WORKS: In your Pod specification, you define a volume of type projected. Within this volume, you specify one or more sources, such as a configMap or a secret. For each source, you map keys from the Kubernetes object to file paths that will appear inside the volume. The kubelet on the node is responsible for fetching the data from the API server and writing it to the specified path inside the Pod's mount. When the source ConfigMap or Secret is updated, the kubelet eventually detects the change during its sync loop and updates the file on disk.

WHEN TO USE IT: Use projected volumes when your application is designed to read its configuration from files and can reload that configuration without a restart (e.g., by watching for file system changes). This is perfect for feature flags, logging levels, or connection strings that might change while an application is running. It decouples configuration updates from the Pod lifecycle.

WHEN NOT TO USE IT: If your application only reads its configuration once at startup, this provides no benefit over environment variables, as you would still need to restart the Pod to pick up changes. It is also not ideal for very large configuration files, as this can add load to the kubelet and the Kubernetes control plane.

ONE CANONICAL EXAMPLE: A web server like NGINX is often configured with a central nginx.conf file. You can store this file's content in a ConfigMap. By projecting this ConfigMap into the NGINX Pod at /etc/nginx/nginx.conf, you can update the server's behavior by simply applying a new version of the ConfigMap. With the right setup, NGINX can be signaled to reload its configuration without dropping any active connections.