We wanted to build a Centralized Toggle Server leveraging Spring Cloud Config Server, but I've read a blog/article hinting that Spring Cloud Config is not Suited for Kubernetes Cloud environment (didn't give any reason why). Instead it is recommended to use Spring Kubernetes ConfigMaps for that.
Can some one shed the light on why Spring Cloud Config Server is not recommended for Kubernetes environment, if any? And advantages of using Spring Kubernetes ConfigMaps over Spring Cloud Config Server, if any?
Here are some thoughts, a kind of comparison that that might help to decide:
IMO both can work generally speaking. Maybe you colleague could provide more insights on this (I'm not joking): what if there is something special in your particular environment that prevents Spring Cloud config from being even considered as an option.
Once the property changes in spring cloud config, potentially beans having @Refresh scope can be reloaded without the need to re-load the application context. A kind of solution that you might benefit from if you're using spring.
In general Spring Cloud Config can manage secrets (stuff like passwords), ConfigMaps can't, you should use Secrets of kubernetes in this case.
On the other hand, Spring Cloud Config - requires a dedicated service. ConfigMaps is "native" in kubernetes.
When the application (a business) microservice starts it first contacts spring cloud config service, if its not available, the application won't start correctly (technically it falls back to other ways of configurations supported by spring boot, like application.properties, etc.) If you have hundreds of micro-services and hundreds of instances of microservice, Cloud Config has to be available all the time, so you might need a replica of those, which is perfectly doable of course.
Spring Cloud Config works best if all your microservices use Java / Spring. ConfigMaps is a general purpose mechanism. Having said that, spring cloud config exposes REST interface so you can integrate.
Spring Cloud Config requires some files that can be either on file system or on git repository. So the "toggle" actually means git commit and push. Kubernetes usually is used for "post-compile" environments so that its possible that git is not even available there.
DevOps people probably are more accustomed to use Kubernetes tools, because its a "general purpose" solution.
Depending on your CI process some insights might come from CI people (regarding the configuration, env. variables that should be applied on CI tool, etc.) This highly varies from application to application so I believe you should talk to them as well.