I understand the benefit of ConfigMaps in Kubernetes, but I'm not sure why I would choose to load a ConfigMap through a volume. We already have the ConfigMap --from-file, --from-literal, and --from-env-file options available.
What's the value of the volumes option (example below)?
you're looking at different ends of the ConfigMap there. When you create a ConfigMap you can use a file or a literal as the source, and that just stores the data in Kubernetes. The data could be JSON or XML or whatever config format your app expects.
In the Pod spec you mount the ConfigMap as a volume and that makes the data you stored available as a file in the container filesystem. So if your app uses a JSON config file you can set it up to look in a specific place for that file, and have Kubernetes load the file from a ConfigMap.
That means you keep configuration out of your container image and store it in the platform, so your image and your Pod spec are the same for every environment, only the contents of the ConfigMap change.
That makes more sense to me. In the Kubernetes docs example I provided, the config ends up as 2 files like this:
So the file name becomes the key and the file contents becomes the value. I didn't see any value in this compared with using environment variables, but if you have a more complex config that could be formatted in JSON or XML, then I can see why you'd want to this. So something like this perhaps:
... where the server.json.file JSON would end up in a single config file mounted on the volume. I think I get it now. Thanks Elton!