go程序默认不感知kubernetes headless service，必须用net.lookupip("ip", fqdn)查全量pod ip，避免lookuphost单ip或lookupnetip错误网络类型；需完整fqdn、短ttl缓存、连接池限流及健康检查。
Go 程序在 Kubernetes 集群内默认就能用 Service 域名（如 user-service.default.svc.cluster.local）发起请求，不需要额外部署 kube-dns —— 它早已由集群自动安装并运行。真正要解决的，是 Go 代码里怎么查、查什么、以及查完怎么用。
为什么 net.LookupHost 查不到 Headless Service 的所有 Pod IP
Headless Service 不生成聚合 A 记录，只让 CoreDNS 返回每个 Pod 的独立 A/AAAA 记录。而 net.LookupHost 只查 CNAME 或 hostnames，不返回 IP；它对 Headless 域名大概率返回空或 no such host。
- 必须改用
net.LookupIP，且网络类型指定为"ip"（不是"ip4"），否则 IPv6 双栈环境下会漏掉部分记录 - 域名必须是完整 FQDN：
my-svc.default.svc.cluster.local，短名my-svc依赖系统 resolver 的ndots行为，Go 的纯 Go 解析器（PreferGo: true）不支持自动补全 -
net.LookupIP返回的是去重后的[]net.IP，但 Kubernetes 不保证 Pod IP 全局唯一（如 HostNetwork 场景），需业务层校验
如何避免 DNS 缓存导致请求发到已终止的 Pod
Go 标准库的 http.Client 默认会对 DNS 结果缓存（底层复用 net.Resolver 的结果），滚动更新时容易把流量打到已销毁但缓存未过期的 Pod 上。
- 不要直接用
http.Get("http://my-svc:8080")—— 它只解析一次，后续复用连接，无法感知后端变化 - 每次请求前手动调用
net.DefaultResolver.LookupIP获取最新 IP 列表，并设置合理超时（如context.WithTimeout(ctx, 2*time.Second)） - 对每个 IP 做轻量健康检查：
net.DialTimeout("tcp", ip+":port", 500*time.Millisecond)，跳过失败项再选一个 - 缓存 DNS 查询结果最多 30 秒，避免高频查询压垮 CoreDNS
什么时候该切到 client-go 监听 Endpoints
当服务对可用性敏感（如支付、实时消息），或者你发现 DNS 解析延迟 + 缓存抖动已经影响 SLA，就该放弃轮询 DNS，改用 API 实时监听。
- 用
client-go的Watch接口监听Endpoints资源变更，比 DNS 解析快 1–3 秒，且无缓存偏差 - 注意 RBAC 权限：Pod 对应的 ServiceAccount 必须有
get/watch/list endpoints权限 - 监听字段过滤用
FieldSelector: "metadata.name=my-svc"，避免收到无关事件 - Watch 连接要加重连逻辑，断开后重新
List再Watch，防止长期失联
最常被忽略的一点：无论用 DNS 还是 client-go，都别忘了给 HTTP 客户端配好 Transport 的 MaxIdleConnsPerHost 和超时控制。否则即使 IP 列表更新了，旧连接仍可能复用并卡死在已下线的 Pod 上。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
