Spring Cloud Config Server 与 Cloud kubernetes 的 ConfigMaps
Spring Cloud Config Server vs ConfigMaps for cloud kubernetes
我们想构建一个利用 Spring 云配置服务器的集中式切换服务器，但我读到 blog/article 暗示 Spring 云配置不适合 Kubernetes 云环境（没有给出任何理由）。相反，建议为此使用 Spring Kubernetes ConfigMaps。
有人能解释一下为什么 Spring 不建议将 Cloud Config Server 用于 Kubernetes 环境吗？使用 Spring Kubernetes ConfigMaps 相对于 Spring Cloud Config Server 的优势，如果有的话？
这里有一些想法，一种可能有助于决定的比较：
一般来说，IMO 两者都可以工作。也许您的同事可以就此提供更多见解（我不是在开玩笑）：如果在您的特定环境中有一些特殊的东西阻止 Spring 云配置被视为一个选项怎么办。
一旦 spring 云配置中的 属性 发生变化，可能可以重新加载具有 @Refresh 范围的 bean，而无需重新加载应用程序上下文。如果您使用 spring，您可能会从中受益的一种解决方案。
一般SpringCloud Config可以管理secrets（密码之类的东西），ConfigMaps不能，这种情况下你应该使用kubernetes的Secrets。
另一方面，Spring Cloud Config - 需要专门的服务。 ConfigMaps 在 kubernetes 中是 "native"。
当应用程序（业务）微服务启动时，它首先联系 spring 云配置服务，如果它不可用，应用程序将无法正确启动（技术上它会回退到其他spring boot 支持的配置方式，如 application.properties 等）如果你有数百个微服务和数百个微服务实例，Cloud Config 必须始终可用，因此你可能需要这些的复制品，这当然是完全可行的。
Spring 如果您的所有微服务都使用 Java / Spring，Cloud Config 效果最佳。 ConfigMaps 是一种通用机制。话虽如此，spring 云配置公开了 REST 接口，因此您可以集成。
Spring Cloud Config 需要一些可以位于文件系统或 git 存储库中的文件。所以 "toggle" 实际上意味着 git 提交和推送。 Kubernetes 通常用于 "post-compile" 环境，因此 git 甚至可能在那里不可用。
DevOps 的人可能更习惯使用 Kubernetes 工具，因为它是一个 "general purpose" 解决方案。
根据您的 CI 过程，一些见解可能来自 CI 人（关于配置、应该应用于 CI 工具的环境变量，等）这因应用程序而异，因此我相信您也应该与他们交谈。
我们想构建一个利用 Spring 云配置服务器的集中式切换服务器，但我读到 blog/article 暗示 Spring 云配置不适合 Kubernetes 云环境（没有给出任何理由）。相反，建议为此使用 Spring Kubernetes ConfigMaps。
有人能解释一下为什么 Spring 不建议将 Cloud Config Server 用于 Kubernetes 环境吗？使用 Spring Kubernetes ConfigMaps 相对于 Spring Cloud Config Server 的优势，如果有的话？
这里有一些想法，一种可能有助于决定的比较：
一般来说，IMO 两者都可以工作。也许您的同事可以就此提供更多见解（我不是在开玩笑）：如果在您的特定环境中有一些特殊的东西阻止 Spring 云配置被视为一个选项怎么办。
一旦 spring 云配置中的 属性 发生变化，可能可以重新加载具有
@Refresh范围的 bean，而无需重新加载应用程序上下文。如果您使用 spring，您可能会从中受益的一种解决方案。一般SpringCloud Config可以管理secrets（密码之类的东西），ConfigMaps不能，这种情况下你应该使用kubernetes的Secrets。
另一方面，Spring Cloud Config - 需要专门的服务。 ConfigMaps 在 kubernetes 中是 "native"。
当应用程序（业务）微服务启动时，它首先联系 spring 云配置服务，如果它不可用，应用程序将无法正确启动（技术上它会回退到其他spring boot 支持的配置方式，如
application.properties等）如果你有数百个微服务和数百个微服务实例，Cloud Config 必须始终可用，因此你可能需要这些的复制品，这当然是完全可行的。Spring 如果您的所有微服务都使用 Java / Spring，Cloud Config 效果最佳。 ConfigMaps 是一种通用机制。话虽如此，spring 云配置公开了 REST 接口，因此您可以集成。
Spring Cloud Config 需要一些可以位于文件系统或 git 存储库中的文件。所以 "toggle" 实际上意味着 git 提交和推送。 Kubernetes 通常用于 "post-compile" 环境，因此 git 甚至可能在那里不可用。
DevOps 的人可能更习惯使用 Kubernetes 工具，因为它是一个 "general purpose" 解决方案。
根据您的 CI 过程，一些见解可能来自 CI 人（关于配置、应该应用于 CI 工具的环境变量，等）这因应用程序而异，因此我相信您也应该与他们交谈。