问题极可能出在kube-proxy的IPVS模式转发链路中断，需依次验证mode配置、内核模块加载、Endpoints一致性、IPVS连接状态，并通过日志定位parseIP错误或“no destination available”根因。
当Kubernetes集群中Service流量突然不通、客户端访问ClusterIP超时或返回连接拒绝，而Pod本身健康且网络连通性正常时，问题极可能出在kube-proxy的IPVS模式转发链路中断。此时必须快速定位是规则未生成、后端缺失、内核模块异常，还是连接状态卡死。
确认kube-proxy是否真正运行在IPVS模式
进入任意工作节点（非master，避免干扰控制面），执行：
sudo kubectl get configmap kube-proxy -n kube-system -o yaml | grep mode
输出必须为 【mode: ipvs】；若显示iptables或为空，则配置未生效，后续所有IPVS排查均无意义。
检查当前运行中的kube-proxy容器实际参数：
kubectl get pod -n kube-system -l k8s-app=kube-proxy -o jsonpath='{.items[0].spec.containers[0].command}' | grep ipvs
应看到 --proxy-mode=ipvs 字样。若未出现，说明ConfigMap更新后未触发Pod滚动重启。
验证IPVS内核模块是否就绪
在出问题的节点上直接执行：
lsmod | grep -E '^(ip_vs|nf_conntrack)'
必须同时看到 ip_vs、ip_vs_rr（或ip_vs_wrr/ip_vs_sh）、nf_conntrack 三者加载。缺任一模块，IPVS无法建立真实服务器映射。
若缺失，立即加载：
sudo modprobe ip_vs ip_vs_rr nf_conntrack
并写入持久化配置防止重启失效：
echo -e "ip_vs\nip_vs_rr\nnf_conntrack" | sudo tee /etc/modules-load.d/ipvs.conf
【注意：仅加载ip_vs不等于IPVS可用，nf_conntrack缺失会导致连接跟踪失败，进而触发“no destination available”错误】
检查Endpoints与IPVS规则一致性
第一步：确认目标Service存在活跃Endpoint
kubectl get endpoints <service-name> -n <namespace>
输出中SUBSETS.ADDRESSES必须非空，且每个IP对应一个Running+Ready状态的Pod。
第二步：登录该Service流量必经的源节点（即发起调用的Pod所在节点），执行：
sudo ipvsadm -Ln | grep <ClusterIP>
例如查kubernetes默认Service：
sudo ipvsadm -Ln | grep 10.96.0.1
若无任何输出，说明kube-proxy根本未同步该Service规则——大概率是Endpoint为空或标签选择器不匹配。
第三步：若有规则但后端为空，查看具体条目：
sudo ipvsadm -Ln --stats | grep <ClusterIP>
若ActiveConn为0且InActConn持续增长，说明连接被创建但无法转发到后端，需立刻检查Pod就绪探针是否失败或网络策略是否拦截。
抓取IPVS连接状态诊断卡死连接
高频短连接场景下，IPVS连接表极易被TIME_WAIT和SYN_RECV填满，导致新连接无法建立。
执行：
sudo ipvsadm -lnc | head -20
重点关注以下三类异常状态：
① 大量 TCP 00:51 SYN_RECV：客户端发了SYN，但IPVS找不到后端或后端不可达，卡在此状态；
② 大量 TCP 01:30 TIME_WAIT：连接已关闭，但IPVS内核表仍锁定120秒以上，消耗哈希槽位；
③ 大量 TCP 00:00 ESTABLISHED 但 ActiveConn=0：连接已建好却无流量，通常是后端Pod监听端口错配或防火墙拦截回程包。
若发现SYN_RECV堆积，立即检查：
sudo ss -tnp | grep <ClusterIP>
确认是否有进程真正监听该VIP端口——正常情况下应无结果（VIP不绑定网卡），若有监听则说明有其他程序冲突。
强制刷新IPVS规则并观察日志
方法一：触发kube-proxy主动重载
kubectl delete pod -n kube-system -l k8s-app=kube-proxy
等待新Pod启动后，立刻在节点上执行：
sudo ipvsadm -Ln | grep <ClusterIP>
看规则是否重建、后端IP是否回归。
方法二：手动清理残留规则（仅限紧急恢复）
先备份当前规则：
sudo ipvsadm -Sn > /tmp/ipvs.rules.bak
再删除全部虚拟服务：
sudo ipvsadm -C
此时所有Service将立即不可用；等待约10秒，kube-proxy会自动重建全量规则。
方法三：实时盯住kube-proxy日志找报错源头：
kubectl logs -n kube-system -l k8s-app=kube-proxy --since=10s | grep -i -E "(error|fail|no destination|parseip)"
一旦出现 parseIP Error 或 no destination available，立即按IPv6双栈或版本兼容性方向深入。
