Are config maps are really needed? (for the case)

General Discussions
1

Hi. I’m generating all my kube resources configs from another config system, so I don’t maintain kube resources directly.

I’m thinking about whether I should use config maps for keeping env data and then map them to deployments or just embed env values them into generated deployment config, anyway they are generated each time I do changes, so I just don’t see any advantages of having additional entity which I don’t see the actual value of.

If using config map for example, if some value is changed and even if multiple pods depend on it, I just update it my config system, and then update the state of all config maps on the cluster. Then I should still touch pods to make them see the changes.

If I don’t use config maps I just update/apply config for deployment with new env values and pod is restarted.

So I don’t see the actual value of involving of config maps in my setup.

Any thoughts about such case?

2

If you can handle rollbacks, etc, correctly, I think you are fine.

If that setup doesn’t handle rollbacks correctly, or you need files instead of env vars, etc. then configmaps will have value for your setup too.

If that is not the case, I think you are fine not using them.

3

I agree with @rata

4

Thanks, its a good point about rollbacks.

5

I use a configuration server like consul to manage my applications configuration. I found it too problematic to depend on kubernetes objects to handle this and really, it is kinda out of scope to require that kubernetes configures your application for non-bootup type things.

I use Spring Boot a lot and it has tight integration with configuration management as a service.