grpc客户端必须使用dns:///scheme并配置负载均衡器才能实现kubernetes服务发现。需配合headless service、正确dns配置、keepalive参数及istio sidecar等机制确保连接健康与负载均衡。
gRPC客户端必须用 dns:/// scheme 才能触发服务发现
默认的 grpc.Dial("service-name:port") 会直接解析成单个 IP 并建立 1-1 连接，完全绕过 Kubernetes 的 DNS 机制。哪怕后端有 5 个 Pod，客户端也只连其中一个，且连接长期不释放。
真正起作用的是带 scheme 的目标地址：dns:///service-name:port（注意三个斜杠）。这个格式会触发 gRPC 内置的 dns resolver，让客户端主动向 CoreDNS 查询 SRV 或 A 记录。
- 必须使用
grpc.WithBalancerName("round_robin")或其他 balancer，否则 resolver 返回的地址列表不会被消费 - Service 必须是
ClusterIP: None（即 headless service），否则 DNS 返回的是 ClusterIP 而非 Pod IP 列表 - CoreDNS 需启用
kubernetes插件（默认开启），且 Pod 的subdomain和hostname配置正确才能生成可解析的记录
Headless Service 是无头但不是无配置
很多人以为只要把 clusterIP: None 加上就万事大吉，其实还差关键几步。Kubernetes 不会自动为每个 Pod 分配独立 DNS 名，需要显式声明。
典型错误：只写 selector，没配 publishNotReadyAddresses: true 和 headless 对应的 serviceName。
- Pod 的
hostname必须与subdomain匹配，例如hostname: pod-1+subdomain: grpc-svc→ 解析出pod-1.grpc-svc.namespace.svc.cluster.local - Service 的
spec.publishNotReadyAddresses设为true，否则 Pod 启动中状态时 DNS 不返回其 IP - Port 名称必须是
grpc或显式指定appProtocol: "grpc"（某些 K8s 版本需此字段触发 HTTP/2 意图识别）
连接复用和健康检查必须手动干预
gRPC 的长连接特性导致两个隐性问题：旧连接不主动断开、故障 Pod 仍被选中。Kubernetes 的 readiness probe 只影响 Service endpoints，对 gRPC 客户端内部连接池无效。
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
客户端需要自己处理连接生命周期，否则一个 Pod 崩溃后，已有连接可能卡住几十秒甚至更久。
- 设置
grpc.WithKeepaliveParams(keepalive.KeepaliveParams{Time: 30 * time.Second})触发底层 TCP keepalive 探测 - 启用
grpc.WithConnectParams(grpc.ConnectParams{MinConnectTimeout: 5 * time.Second})避免首次连接卡死阻塞整个 dial - 配合
grpc.WithResolvers(kuberesolver.Builder{})（如用第三方 resolver）可监听 endpoints 变更并主动关闭失效连接
Istio Sidecar 是最省事但代价明确的方案
如果不想碰 resolver/balancer 细节，Istio 的 DestinationRule + VirtualService 能在 L7 层做真正的请求级负载均衡，且天然支持 gRPC 流控、重试、超时。
但它不是“零成本”：所有流量经 Envoy 中转，P99 延迟增加 1–3ms，内存占用翻倍，且调试链路变长。
- 必须给 Service 添加
appProtocol: "grpc"，否则 Istio 默认按 HTTP/1.1 处理，导致 header 透传失败 -
DestinationRule的trafficPolicy.loadBalancer.simple可设为LEAST_REQUEST或RANDOM，比 round_robin 更适应不均负载 - Sidecar 注入后，客户端仍要使用
dns:///地址，否则流量不走 Envoy
实际部署时，最容易被忽略的是 resolver 和 balancer 的耦合关系：没有 resolver，balancer 就是空转；没有 balancer，resolver 返回的地址列表就没人消费。这两者缺一不可，且必须在 grpc.Dial 时一次性配齐。
