kube-proxy 不能直接测 go 网络连通性，因其仅负责 iptables/ipvs 流量转发，不提供 http 客户端或连接诊断能力；go 程序连通性问题需分层排查 dns、service 类型、networkpolicy、pod 状态及客户端配置。
为什么 kube-proxy 不能直接用来测 Go 网络连通性
kube-proxy 是 Kubernetes 集群里做 Service 流量转发的组件，它本身不提供 HTTP 客户端、TCP 连通性探测或 Go 程序级网络诊断能力。你用它“测试负载均衡”，实际测的是 iptables/ipvs 规则是否生效、NodePort 是否可达、Endpoint 是否健康——和 Go 程序里 http.Client 能否成功 dial、是否复用连接、超时怎么设，完全是两层事。
常见错误现象：kubectl get endpoints my-svc 显示有 endpoint，但 Go 程序 http.Get("http://my-svc:80") 报 dial tcp: lookup my-svc on xxx:53: no such host，这不是 kube-proxy 的问题，是 DNS 或服务发现没配好。
- Go 程序若在集群外运行，
my-svc这种 ClusterIP 域名根本解析不了，必须用 NodePort + Node IP，或走 Ingress - 若 Go 程序在 Pod 内，要确认它所属命名空间是否能访问目标 Service（RBAC、NetworkPolicy 可能拦截）
-
kube-proxy日志里出现can't open iptables或Failed to sync ipvs rules，说明底层转发链路已断，此时连curl -v http://10.96.x.x:80都会失败
Go 程序里怎么真实模拟负载均衡行为
真正在 Go 里验证“负载均衡是否生效”，得让程序主动发起多次请求，观察后端 Pod 的日志或指标分布。别依赖 kube-proxy 自身状态，它只管转发，不管分发是否均匀。
关键点在于：Service 默认是轮询（Round Robin），但 Go 的 http.Client 默认启用连接复用（Keep-Alive），单个 TCP 连接可能复用多次请求，导致流量全打到同一个后端 Pod 上，误判“没负载均衡”。
立即学习“go语言免费学习笔记（深入）”；
- 加
Transport.MaxIdleConnsPerHost = 1强制每次请求建新连接，更贴近轮询效果 - 用
time.Sleep控制请求节奏，避免因 TCP TIME_WAIT 或内核端口耗尽干扰结果 - 后端 Pod 日志里打上
os.Getenv("HOSTNAME")，比看 CPU/内存分布更准
示例片段：
client := &http.Client{
Transport: &http.Transport{
MaxIdleConnsPerHost: 1,
DialContext: (&net.Dialer{
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
},
}遇到 i/o timeout 或 connection refused 先查哪几层
Go 报错 net/http: request canceled (Client.Timeout exceeded while awaiting headers) 或 dial tcp 10.244.x.x:8080: connect: connection refused，不是 kube-proxy 配置错了，而是请求根本没走到它那一步。
-
connection refused：目标 Pod 的容器进程没监听对应端口，或containerPort和代码 listen 端口不一致 -
i/o timeout：可能是 Service 的targetPort指向了不存在的容器端口；也可能是 NetworkPolicy 禁止了该流量；还可能是 Pod 处于CrashLoopBackOff状态但 Endpoint 还没被摘除（检查kubectl get endpoints输出的 IPs 是否与kubectl get pods -o wide一致） - 用
kubectl exec -it <pod> -- nc -zv <target-pod-ip> 8080</target-pod-ip></pod>直连测试，绕过 Service 和kube-proxy，快速定位是网络层还是服务层问题
Service 类型选 ClusterIP 还是 NodePort 对 Go 测试的影响
ClusterIP 只能在集群内部解析和访问；NodePort 则暴露在每个 Node 的固定端口上，适合从集群外用 Go 程序测。但注意：NodePort 默认范围是 30000–32767，如果你的 Go 程序 bind 了本地端口去连，别撞上这个范围，否则可能被系统拒绝。
- ClusterIP 场景下，Go 程序必须运行在 Pod 内，且 DNS 插件（CoreDNS）正常工作；
resolv.conf里要有search default.svc.cluster.local - NodePort 场景下，Go 请求地址应为
http://<node-ip>:<node-port></node-port></node-ip>，不是http://<service-name>:<node-port></node-port></service-name>——后者不会解析 - LoadBalancer 类型在本地 Minikube 或 Kind 里通常不生效，
kubectl get svc里 EXTERNAL-IP 长期显示<pending></pending>，别等
复杂点在于：哪怕所有配置都对，Kubernetes 的 EndpointSlice 同步、kube-proxy 规则刷新都有秒级延迟。刚创建 Pod，立刻跑 Go 测试，大概率失败。等 3–5 秒再试，或者加个简单重试逻辑，比反复调参数更有效。
