Kubernetes集群中SpringBoot微服务是否需引入服务发现客户端？

核心结论 #

不需要引入任何专门的服务发现客户端类库，就能直接使用Kubernetes原生服务发现能力。
K8s原生服务发现是下沉到集群网络层实现的，对应用零侵入，和传统Spring Cloud Eureka/Consul那套需要引入客户端SDK、手动配置注册中心、上报实例信息的模式完全不同：只要你给部署的微服务创建了对应的Service资源，集群会自动完成服务注册、域名解析、负载均衡全流程，应用侧无感知。

同集群内服务调用方法 #

调用方的SpringBoot服务不需要做任何特殊适配，不管你用RestTemplate、WebClient、OkHttp还是原生的HttpURLConnection，直接按普通HTTP请求的写法，把目标地址填成K8s为Service生成的固定域名即可，具体域名规则：

• 同命名空间调用：直接写Service名即可。比如给用户服务创建的Service叫user-service，暴露的端口是8080，那同命名空间下的服务直接请求http://user-service:8080/接口路径就能通。
• 跨命名空间调用：写全限定域名，格式是<服务名>.<服务所在命名空间>.svc.cluster.local。比如上面的user-service部署在prod命名空间，其他命名空间的服务就用http://user-service.prod.svc.cluster.local:8080/接口路径访问。
• 关于负载均衡：默认的ClusterIP类型Service自带四层负载均衡，kube-proxy会自动把发往Service的流量轮询转发到后端健康的Pod上，后端Pod扩缩容、故障漂移、重启换IP这些事，应用侧完全不用管，也不需要额外配置客户端负载均衡。

什么时候才需要引入服务发现类库 #

只有当你需要原生能力覆盖不到的高级特性时，才需要考虑引入额外类库，常见场景包括：

• 要自定义负载均衡规则，比如按请求头做灰度、同可用区优先路由
• 要在代码里直接拿到某个服务对应的所有Pod实例列表，做自定义流量分发
• 要和Spring Cloud生态的组件（比如OpenFeign、熔断、配置中心）做深度适配
  这类场景可以引入Spring Cloud Kubernetes这类适配库，但这属于可选扩展，根本不是使用K8s原生服务发现的必要条件。

几个容易踩的坑 #

• 绝对不要硬编码Pod IP调用：Pod是临时资源，重启、扩缩容、节点漂移都会更换IP，硬编码必出问题，永远走Service域名访问。
• 正常集群创建的Pod会自动注入CoreDNS的解析地址，不需要手动修改网络配置，进Pod执行cat /etc/resolv.conf就能看到nameserver已经指向了集群DNS地址。
• 如果你用的是Headless Service（配置里写了clusterIP: None），DNS解析会直接返回所有后端Pod的IP，不会自动做负载均衡，这类场景需要自己处理负载逻辑，普通业务用默认ClusterIP类型的Service完全够用。

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