go 中需用 net.defaultresolver.lookupip("ip", fqdn) 获取 headless service 全量 pod ip，避免 lookuphost 单 ip、lookupnetip 错误网络类型；dns 响应大时宜用 miekg/dns 手动 udp/tcp 查询并处理截断；连接层须配合短 ttl 缓存、连接池限流及写入前健康检查。
Headless Service 在 Go 中怎么触发 DNS 解析
Go 程序默认不感知 Kubernetes 的 Headless Service，它不会自动按 Pod IP 列表做轮询或故障转移——Go 的 net.Resolver 走的是系统 DNS（如 /etc/resolv.conf），而 kube-dns/CoreDNS 返回的 A 记录是否为多个 IP，取决于查询方式和 DNS 配置。
常见错误现象：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 忽略、错误重试这三块，最容易在线上静默失败。
