Spring Cloud Config Server 与 Cloud kubernetes 的 ConfigMaps

Question

我们想利用 Spring Cloud Config Server 构建一个 Centralized Toggle Server，但我读过一篇博客/文章暗示 Spring Cloud Config 不适合 Kubernetes Cloud 环境（没有给出任何原因）。相反，建议为此使用 Spring Kubernetes ConfigMaps。

有人可以解释为什么不建议将 Spring Cloud Config Server 用于 Kubernetes 环境（如果有）？以及使用 Spring Kubernetes ConfigMaps 而不是 Spring Cloud Config Server 的优势（如果有的话）？

Answer 1

以下是一些想法，一种可能有助于做出决定的比较：

一般来说，IMO 都可以工作。也许您的同事可以对此提供更多见解（我不是在开玩笑）：如果您的特定环境中有一些特殊的东西阻止 Spring Cloud 配置被视为一种选择，该怎么办。

1. 一旦 spring cloud 配置中的属性发生更改，@Refresh就可以重新加载具有作用域的潜在 bean，而无需重新加载应用程序上下文。如果您使用 spring，您可能会从中受益的一种解决方案。

2. 一般来说，Spring Cloud Config 可以管理秘密（比如密码），ConfigMaps 不能，在这种情况下你应该使用 kubernetes 的 Secrets。

3. 另一方面，Spring Cloud Config - 需要专门的服务。ConfigMaps 在 kubernetes 中是“原生的”。

4. 当应用程序（一个业务）微服务启动时，它首先联系spring cloud config service，如果它不可用，应用程序将无法正确启动（技术上它回退到spring boot支持的其他配置方式，比如 application.properties，等）如果您有数百个微服务和数百个微服务实例，Cloud Config 必须始终可用，因此您可能需要这些的副本，这当然是完全可行的。

5. 如果您的所有微服务都使用 Java / Spring，则 Spring Cloud Config 效果最佳。ConfigMaps 是一种通用机制。话虽如此，spring cloud config 公开了 REST 接口，因此您可以进行集成。

6. Spring Cloud Config 需要一些文件，这些文件可以位于文件系统或 git 存储库中。所以“切换”实际上意味着 git commit 和 push。Kubernetes 通常用于“后编译”环境，因此 git 甚至可能在那里不可用。

7. DevOps 人员可能更习惯于使用 Kubernetes 工具，因为它是一种“通用”解决方案。

8. 根据您的 CI 流程，一些见解可能来自 CI 人员（关于配置、环境变量应应用于 CI 工具等）。这因应用程序而异，因此我相信您也应该与他们交谈。