我们想利用 Spring Cloud Config Server 构建一个集中式 Toggle 服务器，但我读过一篇博客/文章，暗示 Spring Cloud Config 不适合 Kubernetes Cloud 环境(没有给出任何原因)。相反，建议使用 Spring Kubernetes ConfigMaps。
有人可以解释一下为什么不建议在 Kubernetes 环境中使用 Spring Cloud Config Server(如果有)吗？使用 Spring Kubernetes ConfigMap 相对于 Spring Cloud Config Server 有何优势(如果有)？
最佳答案
以下是一些想法，一种可能有助于做出决定的比较:
IMO 一般来说，两者都可以工作。也许你的同事可以对此提供更多见解(我不是在开玩笑):如果你的特定环境中有一些特殊的东西阻止 Spring Cloud 配置被视为一个选项，该怎么办？
一旦 Spring Cloud 配置中的属性发生更改，可以重新加载具有
@Refresh范围的潜在 bean，而无需重新加载应用程序上下文。如果您使用 spring，您可能会受益于一种解决方案。一般来说，Spring Cloud Config 可以管理 secret (密码之类的东西)，而 ConfigMaps 不能，在这种情况下您应该使用 kubernetes 的 Secret。
另一方面，Spring Cloud Config - 需要专用服务。 ConfigMaps 是 kubernetes 中的“原生”。
当应用程序(业务)微服务启动时，它首先联系 Spring Cloud 配置服务，如果它不可用，应用程序将无法正确启动(从技术上讲，它会回退到 Spring Boot 支持的其他配置方式，例如
application.properties等)如果您有数百个微服务和数百个微服务实例，则 Cloud Config 必须始终可用，因此您可能需要这些的副本，这当然是完全可行的。如果您的所有微服务都使用 Java/Spring，Spring Cloud Config 效果最佳。 ConfigMaps 是一种通用机制。话虽如此，Spring Cloud Config 公开了 REST 接口(interface)，因此您可以集成。
Spring Cloud Config 需要一些可以位于文件系统或 git 存储库上的文件。所以“切换”实际上意味着git提交和推送。 Kubernetes 通常用于“后编译”环境，因此 git 可能在那里不可用。
DevOps 人员可能更习惯使用 Kubernetes 工具，因为它是一个“通用”解决方案。
根据您的 CI 流程，一些见解可能来自 CI 人员(关于应在 CI 工具上应用的配置、环境变量等)，这因应用程序而异，因此我相信您应该谈谈对他们来说也是如此。
关于java - Spring Cloud Config Server 与云 kubernetes 的 ConfigMaps，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/59139965/