Golang如何解析Headless Service的DNS服务发现机制？

本文共计1327个文字，预计阅读时间需要6分钟。

Go 程序默认不支持 Kubernetes 的 Headless Service，因此不会自动按 Pod IP 列表进行轮询或故障转移。Go 的 net.Resolver 走的是系统 DNS（如 /etc/resolv.conf），而不是 Kubernetes DNS。因此，对于 kube 的 Headless Service，需要直接使用 Kubernetes API 来获取 Pod IP。

常见错误现象：net.LookupHost("my-svc.default.svc.cluster.local") 只返回一个 IP，或者随机返回一个，不是全部 Pod IP；更糟的是，在某些环境里直接超时或报 no such host。

• 必须确保查询域名是完整 FQDN（带 .svc.cluster.local 后缀），否则可能走外部 DNS 回退
• Go 1.19+ 默认启用 go:build !golang.org/x/net/dns/dnsmessage 分支逻辑，对 SRV/A 记录的解析行为更严格，旧代码在升级后可能突然失效
• 不要依赖 net.LookupIP 的返回顺序：Kubernetes DNS 不保证顺序，且 Go 会做内部 shuffle
• 若用 http.Client 直接请求 http://my-svc/，底层仍只解析出一个 IP 并复用连接，无法实现真正的服务发现

用 net.Resolver 手动查全量 A 记录

想拿到所有 Pod IP，得绕过 net/http 的缓存和单点解析逻辑，显式调用 DNS 查询。关键不是“能不能查”，而是“查什么记录、怎么处理响应”。

示例中容易踩坑：resolver.LookupNetIP(ctx, "ip4", "my-svc.default.svc.cluster.local") 看似合理，但实际返回的可能是 CNAME 或空结果——因为 Headless Service 对应的是 A 记录集合，不是 CNAME 指向。

立即学习“go语言免费学习笔记（深入）”；

• 应该用 resolver.LookupAddr？错，那是反向查询
• 正确做法是：用 net.DefaultResolver.LookupHost，但它只返回 hostnames；要 IP 就得用 LookupIP，但必须指定网络类型为 "ip"（不是 "ip4"），否则 IPv6 环境下可能漏掉部分记录
• 返回的 []net.IP 是去重后的，但 Kubernetes 不保证每个 Pod 都有唯一 IP，尤其当使用 HostNetwork 或多网卡时，需自行校验
• 务必设 ctx 超时，CoreDNS 在 Pod 启动中或 endpoint 变更时可能短暂返回 NXDOMAIN

为什么 dns.Client + UDP 查询有时比 net.Resolver 更稳

Go 标准库的 net.Resolver 抽象层隐藏了协议细节，但在高并发或自定义 DNS 场景下反而成瓶颈：它复用系统配置、不支持 EDNS、无法控制重试策略。而 Headless Service 的 DNS 响应往往较大（几十个 Pod 就超 512 字节），UDP 截断后需降级到 TCP，标准库处理不一致。

真实场景中，net.Resolver 在容器内可能读取到被 kubelet 注入的错误 resolv.conf（比如 search 域过多导致查询放大），这时自己构造 DNS 请求更可控。

• 用 github.com/miekg/dns 构造 dns.Msg，显式发 A 记录查询，设置 Msg.RecursionDesired = true
• 收到响应后检查 Msg.Truncated，若为 true，改用 TCP 重试（dns.Client 支持 Net: "tcp"）
• 手动解析 Msg.Answer 中的 *dns.A，跳过 CNAME 和空记录，避免误把 service 名当 Pod 名
• 注意 TTL：Headless Service 的 A 记录 TTL 通常为 5 秒，别缓存太久，也别每次请求都查——可配合简单本地 LRU 缓存

Pod IP 变更后连接没断开怎么办

DNS 解析结果只是起点，Go 的 http.Transport 或自建连接池会复用底层 TCP 连接。即使你每秒都重新查 DNS，老连接仍可能打到已销毁的 Pod 上，表现为 i/o timeout 或 connection refused。

这不是 DNS 发现的问题，而是连接生命周期管理缺失。Kubernetes 不提供“连接优雅驱逐”信号，只能靠客户端自救。

• 对 HTTP：设置 http.Transport.MaxIdleConnsPerHost = 1，并开启 ForceAttemptHTTP2 = false，避免长连接滞留
• 对自定义 TCP 连接：在每次写入前加 conn.SetWriteDeadline，读取时捕获 io.EOF 和 syscall.ECONNRESET，失败后重新解析 DNS 并拨号
• 别依赖 net.DialTimeout：它只管建连，不管后续通信；真正要的是“每次请求前验证目标可达”，可用 conn.Write 前先 conn.SetWriteDeadline(time.Now().Add(100 * time.Millisecond))
• 如果用 gRPC，必须配 WithRoundRobin + 自定义 resolver.Builder，否则内置 resolver 会缓存 endpoints 长达 30 秒

Headless Service 的 DNS 响应本身没问题，问题总出在“查到了，但没用对”——尤其是连接复用、TTL 忽略、错误重试这三块，最容易在线上静默失败。