k8s中service的sessionaffinity误设为clientip、conntrack与http client超时参数不匹配、endpointslice同步延迟及readiness probe设置不当，共同导致golang应用流量不均。
Service 的 sessionAffinity 被误开导致连接粘连
很多 golang 应用在 K8s 里跑着跑着就发现某个 Pod CPU 突然飙升，其他 Pod 却空闲——八成是 sessionAffinity 意外开启了 ClientIP 模式。K8s 默认是 None，但一旦你在 Service YAML 里写了 sessionAffinity: ClientIP，kube-proxy 就会按源 IP 做哈希绑定，而 Golang 的 HTTP client 默认复用连接（http.DefaultTransport），一个 client 实例发几十个请求，全打到同一个 Pod 上。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 检查 Service YAML：确认
sessionAffinity字段没被手动设为ClientIP，或被 Helm chart / Kustomize 模板注入 - 临时验证：用
kubectl get svc -o wide看输出里有没有Session Affinity: ClientIP - 如果必须保持会话粘性，改用应用层方案（如 JWT + redis 记录路由偏好），别依赖 Service 层
Golang HTTP client 复用连接撞上 kube-proxy 的 conntrack 表老化
K8s Node 上的 conntrack 默认老化时间是 5 分钟（net.netfilter.nf_conntrack_tcp_timeout_established），而 Golang 的 http.Transport 默认 IdleConnTimeout 是 30 秒、KeepAlive 是 30 秒。两者不匹配时，client 还以为连接可用，实际 conntrack 表里这条连接已被清理，下一次请求就会触发 TCP RST 或超时重试，kube-proxy 可能把它当成新连接重新哈希，导致流量跳变甚至集中打向某 Pod。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 统一调大
http.Transport的IdleConnTimeout和KeepAlive（比如设为 240 秒），略小于 conntrack 老化时间（建议同步调大 Node 的nf_conntrack_tcp_timeout_established到 600） - 禁用长连接？别急——除非你每秒请求数极低，否则关闭
KeepAlive会导致 TLS 握手和 TCP 建连开销暴增 - 加日志：在 client 请求前记录
req.Header.Get("User-Agent")和目标 URL，配合 Pod 日志观察是否出现“同一 client IP 的请求突然分散到多个 Pod”
Endpoints 切片未及时同步，旧 Pod 还在接收流量
Golang 应用做滚动更新时，经常看到新 Pod 已 Ready，但老 Pod 的 CPU 仍在缓慢上涨。这不是负载均衡问题，而是 EndpointSlice 控制器同步延迟或 kube-proxy 没及时刷新规则。尤其当集群规模大、节点多，EndpointSlice 的 watch Event 可能堆积，或者 endpointslice.kubernetes.io/managed-by 注解被误删，导致该 Endpoints 不被管理。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 查 EndpointSlice：运行
kubectl get endpointslice -l kubernetes.io/service-name=your-svc-name，看address列是否包含已终止 Pod 的 IP - 确认 controller 状态：
kubectl get deployment -n kube-system | grep endpointslice，确保endpointslice-controller在运行且无 CrashLoopBackOff - 强制触发同步：删掉对应 EndpointSlice（它会被自动重建），比重启 kube-proxy 更安全
Readiness probe 设置太宽松，Pod 提前进入 Endpoints
这是最隐蔽也最常见的原因：Golang 应用启动后立刻返回 200，但实际 gRPC server 还没 bind port、或 DB 连接池没建满。K8s 把它加进 Endpoints，流量进来后请求卡住、超时、重试，下游看到的就是“部分 Pod 响应慢”，其实是它们根本没准备好处理请求。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- readiness probe 必须检查真实依赖：比如用
http.Get("http://localhost:8080/healthz?full=1")，内部校验 DB 连接、Redis ping、gRPC 连通性 - 避免用
exec执行ps aux | grep main这类假健康检查——进程存在 ≠ 服务就绪 - initialDelaySeconds 设为 10–30 秒，failureThreshold 至少 3，防止短暂抖动误踢 Pod
Golang 的 HTTP 客户端行为、K8s 的网络组件老化策略、Endpoint 同步机制这三者之间的时序差，才是流量不均真正的“交界故障点”。调参不能只盯一边。