为什么 Kubernetes 扩容后 Pod 会拿到重复 IP？
这不是 Go 程序写错了，而是底层 CNI 插件（比如 calico、flannel）分配 IP 时没同步好状态，或者 IPAM（IP 地址管理）后端（如 etcd）出现脑裂或写入失败。Go 应用本身不参与集群 IP 分配，但如果你在代码里硬编码了 "10.244.1.100" 这类地址，或者依赖本地 /etc/hosts 做服务发现，扩容后旧 IP 被复用就会直接撞上。
- Pod 删除后 IP 不一定立即释放，CNI 可能延迟回收
- 多个节点上的 kubelet 同时请求 IP，若 IPAM 无强一致性保障，可能发重
- Go 程序若用
net.ParseIP解析静态配置里的地址，根本不会感知到“这个 IP 已被另一个 Pod 占用”
Go 里怎么安全地获取本机 Pod 的真实网络信息？
别读 /etc/hosts，别查 os.Hostname()，更别拼接字符串构造地址。K8s 提供的标准方式是通过 Downward API 注入环境变量或挂载 downwardAPI 卷：
- 在 Pod spec 中加：
fieldRef: fieldPath: status.podIP→ 注入为环境变量MY_POD_IP - 或挂载为文件：
/etc/podinfo/ip，内容就是当前 Pod 的 IPv4 地址（纯文本，末尾无换行） - Go 里直接读：
os.ReadFile("/etc/podinfo/ip")，然后用net.ParseIP校验
示例片段：
ipData, _ := os.ReadFile("/etc/podinfo/ip")
podIP := net.ParseIP(strings.TrimSpace(string(ipData)))
if podIP == nil {
log.Fatal("failed to parse pod IP")
}
注意：不能依赖 net.InterfaceAddrs()，容器网络命名空间里看到的可能是 veth、lo 或 dummy 接口，顺序和内容不可靠。
立即学习“go语言免费学习笔记（深入）”；
如何避免 Go 服务因 IP 冲突被误杀或连错？
核心是切断对“IP 永久性”的假设。K8s 中 Pod 是可替换的，IP 是临时凭证：
- 不在日志、监控指标、trace 上硬埋
10.244.x.x，改用pod_name.namespace或pod_uid - HTTP 客户端不要用
<a href="https://www.php.cn/link/0a30984ca2e5f170d14cc06c70e087aa">https://www.php.cn/link/0a30984ca2e5f170d14cc06c70e087aa</a>直连其他 Pod，走 Service DNS：<a href="https://www.php.cn/link/9cca8d684240e24dd459f2d439fae30c">https://www.php.cn/link/9cca8d684240e24dd459f2d439fae30c</a> - 如果必须用 IP（比如 UDP 场景），配合 readiness probe + headless Service，让客户端只从
Endpoints列表里取在线地址 - 在 Go 的
http.Server启动前加健康检查：调用kube-apiserver的/api/v1/namespaces/default/pods?fieldSelector=status.phase%3DRunning（需 RBAC）确认自己没被标记为Terminating
网段规划不当会放大 IP 冲突风险
K8s 集群的 Pod CIDR（如 --pod-cidr=10.244.0.0/16）和 Node CIDR（如 10.0.0.0/24）必须互斥，且不能和物理网络重叠。常见翻车点：
- 多个集群共用同一段
10.244.0.0/16，跨集群通信时路由混乱 - Calico 的
IPPool设置了blockSize: 26，但节点数超限导致 IP block 分配失败，回退到 host-local 分配器（无全局锁，易冲突） - Go 程序里写了
net.ParseCIDR("10.244.0.0/24")做子网判断，实际集群用的是/16，结果过滤掉大量合法地址
建议：用 kubectl get nodes -o wide 看每个节点的 InternalIP，再对比 kubectl get pods -o wide 的 IP，人工扫一眼是否落在同一 /24 下——如果 Pod IP 和 Node IP 在同一个子网，基本已经埋雷。
IP 冲突不是 Go 层能修复的问题，但 Go 程序写得越“无状态”、越少依赖具体 IP，就越不容易在扩容时突然失联。真正要盯住的，是 CNI 配置、etcd 健康、以及所有把 IP 当作唯一标识的地方。
