问题根源是gRPC客户端未启用DNS解析器与round_robin负载均衡策略，导致仅连接首个Pod IP。需验证Headless Service DNS返回多A记录，显式配置dns:///地址、禁用DNS缓存，并设置round_robin策略，同时排除健康检查干扰及确认连接指向真实Pod IP。
如果您观察到gRPC长连接在Kubernetes中出现负载不均衡现象，且怀疑是客户端缓存了DNS解析结果，则问题可能并非单纯源于DNS缓存，而是gRPC客户端未正确启用DNS解析器与负载均衡策略，导致其仅使用首个解析出的Pod IP建立单一长连接。以下是排查与修正此问题的具体步骤：
一、验证DNS解析是否返回多个A记录
Headless Service必须返回全部后端Pod的IP地址列表（A记录），这是客户端实现多实例连接的前提。若DNS仅返回单个IP，说明Service配置或CoreDNS行为异常。
1、进入任意Pod执行调试命令：kubectl exec -it <pod-name> -- sh
2、安装dig工具（如未预装）：apk add bind-tools 或 apt-get update && apt-get install -y dnsutils
3、查询Headless Service域名：dig +short <service-name>.<namespace>.svc.cluster.local
4、确认输出为多个IPv4地址；若仅返回一个或无响应，则需检查Service的clusterIP: None配置及CoreDNS日志。
二、强制gRPC客户端使用DNS解析器并禁用默认缓存
gRPC客户端默认不主动轮询DNS更新，且Go/Java/Python等语言SDK对DNS TTL处理逻辑不同，部分版本会将首次解析结果长期缓存于连接池中，造成“始终连同一Pod”现象。
1、Go客户端须显式传入dns.NewBuilder()并指定dns:///前缀地址：grpc.Dial("dns:///my-svc.default.svc.cluster.local:8080", grpc.WithResolvers(dns.NewBuilder()), ...)
2、Java客户端需设置JVM参数强制刷新DNS：-Dio.grpc.internal.DnsNameResolverProvider.enable_grpclb=true -Dsun.net.inetaddr.ttl=0
3、Python客户端（grpcio ≥1.40）需显式禁用系统DNS缓存：import grpc; channel = grpc.insecure_channel('dns:///my-svc.default.svc.cluster.local:8080', options=[('grpc.dns_enable_srv_queries', 0), ('grpc.dns_min_time_between_queries_ms', 1000)])
三、替换默认Balancer并启用round_robin策略
即使DNS返回多个IP，若gRPC未配置有效负载均衡器，仍会沿用pick_first策略——即仅选择首个IP建连，后续所有请求复用该连接，导致流量完全集中。
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
1、Go客户端必须添加服务配置：grpc.WithDefaultServiceConfig(`{"loadBalancingConfig": [{"round_robin": {}}]}`)
2、Java客户端需在ChannelBuilder中调用：.defaultLoadBalancingPolicy("round_robin")
3、Python客户端需在insecure_channel中传入选项：[('grpc.lb_policy_name', 'round_robin')]
四、关闭gRPC健康检查探针干扰
当服务端启用了health.proto健康检查但客户端未同步状态时，gRPC Balancer可能将部分Pod标记为不可用并跳过，造成实际可用IP数减少，间接加剧连接集中。
1、临时注释掉服务端的health.CheckService注册代码
2、在客户端初始化时移除grpc.WithHealthCheck相关配置
3、重新部署并观察负载分布是否恢复均匀；若改善明显，则需校准健康检查超时与重试策略
五、验证连接粒度是否为Pod级而非Service级
使用netstat或ss在客户端Pod内检查TCP连接目标，确认连接是否真正指向多个不同Pod IP，而非始终固定连接至ClusterIP或某单一Pod。
1、执行ss -tuln | grep :8080（假设gRPC端口为8080）
2、查看Peer Address:Port列是否包含至少两个不同IP地址
3、若仅显示一个远程IP，且该IP不属于任何已知Pod（例如是Service ClusterIP），则说明dns:///未生效，客户端仍在尝试直连Service域名字面量，此时应检查gRPC目标地址格式是否遗漏三个斜杠（即必须为 dns:/// 而非 dns:/ 或 dns://）
