GKE部署Spring Boot应用读取K8s Secret遇kubernetesPidUtils重复定义问题

实现Secret读取需求的核心思路 #

你完全不用把Spring Boot改成K8s专属应用，通过Spring Cloud Kubernetes的配置加载能力，就能像读取本地application.yml属性一样读取K8s Secret。注意你ConfigMap里的配置前缀写反了，正确的应该是spring.cloud.kubernetes.secrets.name和spring.cloud.kubernetes.secrets.namespace，配置正确后，Spring会自动把Secret的键值对加载到环境变量，和本地配置合并，直接用@Value或@ConfigurationProperties就能读取，和读取本地属性无差别。

依赖选择：精简即可，无需冗余组件 #

• 不需要DiscoveryClient：如果你的应用仅需加载ConfigMap和Secret，不需要服务发现（比如调用K8s内其他服务），完全不用引入DiscoveryClient相关依赖，它是服务发现场景的组件，和配置加载无关。
• 不要用spring-cloud-kubernetes-fabric8-all：这个依赖是Fabric8全家桶，会引入大量你不需要的模块（包括导致冲突的kubernetesPidUtils）。你只需要引入最小必要依赖：
  • spring-cloud-starter-kubernetes-fabric8-config：这是专门处理ConfigMap和Secret加载的starter，已经包含spring-cloud-kubernetes-commons和核心Fabric8组件，足够满足需求。
  • 移除spring-cloud-kubernetes-autoconfig和spring-cloud-kubernetes-fabric8-all，避免依赖冗余与冲突。

解决kubernetesPidUtils重复定义问题 #

这个冲突就是因为你引入了spring-cloud-kubernetes-fabric8-all，它和其他依赖重复引入了包含kubernetesPidUtils的模块。按照上面的依赖调整，换成spring-cloud-starter-kubernetes-fabric8-config，就能自动避免重复依赖问题。另外，kubernetesPidUtils是K8s环境下生成进程ID的工具类，你仅加载配置的话完全用不到它，解决冲突后无需额外关注。

额外注意事项 #

• 确保GKE的ServiceAccount拥有对应Namespace下读取ConfigMap和Secret的权限，默认ServiceAccount权限可能不足，需要绑定view角色或自定义权限。
• 如果需要热加载配置（修改ConfigMap/Secret后无需重启应用），可以开启spring.cloud.kubernetes.config.reload.enabled=true，这是可选配置。

内容的提问来源于stack exchange，提问作者Woodsman