gRPC客户端直连K8s Headless Service需显式配置DNS解析与负载均衡：Go须用dns:///前缀+round_robin策略，Java需启用grpclb，Python需禁用TLS验证；Headless仅返回多IP，不自动负载均衡；connection refused常因resolver未生效；必须配gRPC健康探针而非TCP探针。
gRPC客户端怎么连上K8s里的Headless Service
直接用Service DNS名（比如 my-svc.my-namespace.svc.cluster.local）当gRPC目标地址，大概率连不上——gRPC默认不解析SRV记录，也不自动轮询Pod IP，它会把整个DNS名当成单一后端，然后卡在连接阶段或只打到一个Pod。
必须显式启用DNS解析并配合正确的resolver和load balancing策略。不同语言SDK行为差异大，Go和Java默认行为就完全不同。
- Go客户端需用
grpc.WithTransportCredentials(insecure.NewCredentials())+grpc.WithResolvers(dns.NewBuilder())，且目标地址写成dns:///my-svc.my-namespace.svc.cluster.local:8080（注意开头dns:///和三个斜杠） - Java（netty）要设JVM参数
-Dio.grpc.internal.DnsNameResolverProvider.enable_grpclb=true，否则忽略A记录返回的多个IP - Python客户端（
grpcio1.40+）默认支持DNS A记录，但必须禁用TLS验证（或配好证书），否则会因SNI不匹配失败
为什么Headless Service返回的A记录没被gRPC均匀使用
不是DNS没返回多个IP，而是gRPC底层连接池没按预期做负载均衡。Headless Service确实会返回所有Pod的A记录，但gRPC的默认Balancer（如Go的 pick_first）只选第一个IP建连，后续请求全复用这条连接。
真正起作用的是Balancer配置，不是Service类型本身。Headless只是“让DNS返回多个IP”，不等于“自动负载均衡”。
- Go里必须显式传
grpc.WithDefaultServiceConfig(`{"loadBalancingConfig": [{"round_robin": {}}]}`) - Java需在channel builder里调用
.defaultLoadBalancingPolicy("round_robin") - 若服务端启用了gRPC健康检查（
health.proto），部分客户端会因健康状态未同步导致跳过某些Pod，建议先关掉健康检查验证基础连通性
Connection refused错误到底出在哪儿
看到 connection refused，第一反应常是网络策略或端口错，但在Headless场景下，更可能是gRPC resolver没生效，导致客户端试图连一个根本不存在的地址——比如DNS解析超时后fallback到字面量地址 my-svc.my-namespace.svc.cluster.local:8080，而kube-proxy根本不处理这种非ClusterIP流量。
查证顺序应该是：先确认DNS是否真返回了Pod IP（nslookup my-svc.my-namespace.svc.cluster.local），再确认客户端日志里有没有 resolved address list 这类关键词，最后看gRPC是否真的尝试连接那些IP。
- 在Pod里执行
nslookup必须返回至少两个Pod IP，否则是Service或Endpoint没对齐 - Go客户端加
grpc.WithBlock()和grpc.WithTimeout(5*time.Second)能让初始化失败立刻暴露，避免静默卡住 - 如果用Istio，Envoy默认拦截所有outbound流量，可能干扰DNS解析路径，此时需检查
Sidecar资源是否放行了kube-dns/CoreDNS的UDP 53端口
gRPC over HTTP/2在K8s里要不要配readiness probe
要，而且probe必须走gRPC健康检查，不能用HTTP GET。K8s原生readiness probe只支持HTTP/TCP，TCP探针只能判断端口通不通，无法确认gRPC服务已加载完所有proto、完成服务注册、准备好接收流式请求。
没配好probe会导致新Pod刚启动就被打入流量，而gRPC Server还没完全就绪，结果就是大量 UNAVAILABLE 或 DEADLINE_EXCEEDED 错误。
- 用
grpc-health-probe工具（官方推荐）写进readinessProbe.exec.command，命令形如["/bin/grpc_health_probe", "-addr=:8080", "-rpc-timeout=5s"] - 确保服务端实现了
health.Check方法，且初始状态返回SERVING，否则probe永远失败 - 不要把
initialDelaySeconds设太小——gRPC Server启动+proto注册+监听器绑定通常比HTTP服务慢，3–5秒更稳妥
Headless Service本身不解决gRPC的服务发现语义问题，它只是把DNS变成“能返回多个IP”的开关。真正的发现逻辑、重试、负载策略、健康感知，全得靠客户端自己配对、验证、调优。漏掉任意一环，都可能表现为偶发性超时或单点打满。
