Spring Boot 3.1.6升级后Kubernetes服务发现超时问题求助

一、排查Kubernetes API Server每2小时超时的步骤 #

• 检查API Server与etcd日志
  • 查看API Server日志：kubectl logs -n kube-system <api-server-pod-name>，筛选近2小时日志，搜索etcdserver、timeout、500关键词，定位是否存在etcd连接超时、资源不足的报错。
  • 查看etcd集群日志：kubectl logs -n kube-system <etcd-pod-name>，重点关注请求处理延迟、磁盘IO、内存占用相关内容——etcd磁盘性能不足或内存过载是超时高频诱因。
• 验证周期性负载峰值
  • 用kubectl top pod -n kube-system持续监控API Server和etcd的CPU、内存使用率，确认每2小时是否有明显负载突增，排查是否是定时任务（如集群监控、证书轮换、自定义控制器同步）导致资源耗尽。
  • 检查集群内定时操作：比如批量kubectl请求、HPA自定义周期任务、第三方工具的周期性扫描等。
• 核对Spring Cloud LoadBalancer配置
  • 检查负载均衡器缓存过期时间：spring.cloud.loadbalancer.cache.ttl，若设置为7200000毫秒（2小时），则缓存刷新时的批量Endpoints拉取可能触发API Server压力过载。
  • 匹配应用日志中超时发生的时间点与缓存过期时间，验证是否为缓存刷新导致的集中请求。
• 排查网络与节点层面问题
  • 在应用Pod内周期性执行curl -v https://10.96.0.1/api/v1/namespaces/<你的命名空间>/endpoints/TEST-SERVICE，测试API Server响应延迟，确认是否每2小时出现延迟飙升。
  • 检查Pod所在节点的网络策略、防火墙规则，以及节点是否有每2小时一次的维护、DNS刷新等操作。
• 检查etcd健康状态与资源配置
  • 执行etcdctl endpoint health（需进入etcd Pod或在具备etcdctl的环境操作），查看etcd集群是否有节点离线、同步延迟情况。
  • 检查etcd磁盘使用：df -h查看数据目录磁盘空间（使用率超85%会触发性能下降），同时验证磁盘IOPS是否达标——etcd对磁盘性能要求高，机械硬盘易引发超时。

二、无需依赖Kubernetes服务发现的Feign通信方案 #

可以通过以下几种方式实现类似Ribbon的Pod间通信，无需依赖K8s服务发现：

方案1：自定义Spring Cloud LoadBalancer服务列表 #

实现ServiceInstanceListSupplier接口，手动提供目标Pod地址列表，绕过K8s服务发现：

@Component
public class CustomTestServiceInstanceSupplier implements ServiceInstanceListSupplier {
    @Override
    public String getServiceId() {
        return "TEST-SERVICE";
    }

    @Override
    public Flux<List<ServiceInstance>> get() {
        // 可从配置文件、数据库或其他独立服务获取动态Pod列表
        List<ServiceInstance> instances = Arrays.asList(
            new DefaultServiceInstance("test-pod-1", "TEST-SERVICE", "10.0.0.1", 8080, false),
            new DefaultServiceInstance("test-pod-2", "TEST-SERVICE", "10.0.0.2", 8080, false)
        );
        return Flux.just(instances);
    }
}

在Feign接口上绑定自定义负载均衡配置：

@LoadBalancerClient(name = "TEST-SERVICE", configuration = CustomLoadBalancerConfig.class)
@FeignClient(name = "TEST-SERVICE")
public interface TestFeignClient {
    // 业务接口定义
}

在CustomLoadBalancerConfig中注册自定义的ServiceInstanceListSupplier。

方案2：Feign直接配置多目标地址（简单场景） #

直接在Feign客户端指定多个目标地址，Feign默认会轮询请求（需确保底层客户端支持，如OkHttp）：

@FeignClient(name = "TEST-SERVICE", url = "${test.service.targets}")
public interface TestFeignClient {
    // 业务接口定义
}

配置文件中用逗号分隔地址：

test.service.targets=http://10.0.0.1:8080,http://10.0.0.2:8080

方案3：集成第三方负载均衡组件 #

• Resilience4j LoadBalancer：添加依赖后配置负载均衡策略，配合自定义服务列表提供者注入Pod地址，实现独立于K8s的负载均衡。
• Netflix Eureka：部署独立的Eureka服务注册中心，让Pod注册到Eureka，Feign配合Eureka实现类似Ribbon的负载均衡逻辑，完全绕过K8s服务发现。

内容的提问来源于stack exchange，提问作者Jin's