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?
Spring Cloud Config is Spring's client/server approach for storing and serving distributed configurations across multiple applications and environments. This configuration store is ideally versioned under Git version control and can be modified at application runtime.
Spring Cloud Config provides server and client-side support for externalized configuration in a distributed system. With the Config Server you have a central place to manage external properties for applications across all environments.
Spring Cloud is a quick to start with, developer-friendly platform, whereas Kubernetes is DevOps friendly, with a steeper learning curve, but covers a wider range of microservices concerns.
Spring Cloud Kubernetes is a Kubernetes API server integration that allows for service discovery, configuration, and load balancing used by Spring Cloud; it provides Spring Cloud implementations of common interfaces that consume Kubernetes.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With