conn_reuse_mode=0导致新连接强制复用已销毁pod的旧rs，引发syn重传、p99延迟飙升；内核≥5.9应设为2，4.1–5.8需依赖kube-proxy快速剔除endpoint，
直接看现象：客户端大量短连接建连超时、SYN重传、P99延迟飙升，ipvsadm -lnc里堆满 syn_recv 状态连接，且长时间不进入 established——这大概率不是网络丢包，而是 IPVS 在 conn_reuse_mode=0 下的“连接固化”行为导致的新连接被错误转发到已销毁或不可达的后端 Pod。
确认当前 conn_reuse_mode 值
该参数决定 IPVS 如何处理客户端 IP+端口复用，是问题根源的开关：
- 登录任一节点，执行：
sysctl net.ipv4.vs.conn_reuse_mode
输出为net.ipv4.vs.conn_reuse_mode = 0即处于高风险状态（复用旧连接，不重新调度） - 检查 kube-proxy 启动日志是否显示它主动设置了该值：
kubectl logs -n kube-system -l k8s-app=kube-proxy --tail=100 | grep conn_reuse - 注意：Kubernetes v1.19+ 对内核 ≥4.1 会默认设为 0；v1.22+ 对内核 ≥5.9 不再干预，此时需手动校验系统值
验证是否因复用导致流量打到异常 RS
conn_reuse_mode=0 的核心问题是：只要客户端五元组（src_ip:src_port → dst_ip:dst_port）匹配上一条旧连接（哪怕处于 TIME_WAIT 或已删除），IPVS 就强制复用原 RealServer，无视其当前健康状态：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- 查出一个卡在 syn_recv 的连接：
ipvsadm -lnc | grep syn_recv | head -1
例如：tcp 01:23 syn_recv 10.233.64.1:41282 10.233.64.1:80 10.233.1.15:8080 - 确认
10.233.1.15:8080是否仍是该 Service 的有效 Endpoint：kubectl get endpoints <svc-name> -n <ns></ns></svc-name> - 若该 IP 已不在 Endpoint 列表中（比如对应 Pod 已 Terminating 或被驱逐），却仍有新连接被强转过去，即证实复用引发转发错位
临时规避与长期修复
不能简单调成 1——它在高并发下会触发 SYN 包丢弃（首个 SYN 被 DROP，1 秒后重传才成功），造成更严重延迟。正确路径是分场景选择：
-
内核 ≥5.9：直接启用
conn_reuse_mode=2（bit 2，兼容 DR 模式 + FIN_WAIT 处理），最稳妥：sudo sysctl -w net.ipv4.vs.conn_reuse_mode=2
并写入/etc/sysctl.d/99-k8s-ipvs.conf持久化 -
内核 4.1–5.8：保持
=0，但必须配合 kube-proxy 的健康检查 + Endpoint 自动剔除机制，确保 terminating Pod 的 endpoint 能在秒级内从 IPVS 规则中移除（检查kube-proxy --healthz-port和endpointslice更新延迟） - 内核 ：升级内核或切换回 iptables 模式（
kube-proxyConfigMap 中设mode: iptables并重启）
辅助诊断命令集
快速定位是否为该问题：
- 统计 syn_recv 连接数占比：
ipvsadm -lnc | awk '/syn_recv/{c++} END{print c+0}'（持续 >100 需警惕） - 对比同一 client IP 的连接目标是否高度集中：
ipvsadm -lnc | awk '$5 ~ /10\.233\.64\.1:80$/ {print $6}' | sort | uniq -c | sort -nr | head -5 - 检查 IPVS 后端权重是否异常（weight=0 的 RS 仍收流量）：
ipvsadm -ln --stats | grep -A5 "your-svc-vip"
