从IPVS到IPTables：一次K8S网络故障的深度排查与模式切换实战

1. 问题初现：Calico Pod启动失败的诡异现象

那天早上刚到公司，就收到监控系统告警：K8S集群中某个节点的Calico Pod一直处于CrashLoopBackOff状态。这可不是小事，Calico作为集群的网络插件，它的异常会直接导致整个节点的网络功能瘫痪。我立刻登录集群查看具体情况：

bash复制kubectl get pods -n kube-system -o wide

果然发现node1节点上的calico-node-jv2qv容器不断重启。查看日志时发现了关键报错：

bash复制kubectl logs -f calico-node-jv2qv -n kube-system

日志显示Calico无法连接Kubernetes API Server，具体错误是访问10.233.64.1:443时出现i/o timeout。这个IP地址引起了我的注意——它是Kubernetes默认Service的ClusterIP：

bash复制kubectl get svc
NAME         TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.233.64.1   <none>        443/TCP   45h

这里出现第一个矛盾点：Master节点的Calico运行正常，只有Node节点出现问题。更奇怪的是，这个ClusterIP在Master节点可以正常访问，在Node节点却出现超时。这排除了API Server本身的问题，将矛头指向了节点间的网络通信。

2. 网络排查：从表象到本质的层层深入

2.1 基础连通性测试

我首先在问题节点上执行了最基础的网络测试：

bash复制ping 10.233.64.1

出乎意料的是ping居然通了！但当我测试端口连通性时：

bash复制telnet 10.233.64.1 443

却得到了连接超时的结果。这种"能ping通但端口不通"的现象非常反常，因为通常网络设备要么全通要么全不通。这提示我们可能遇到了特殊的网络转发问题。

2.2 IPVS规则检查

考虑到集群使用的是IPVS模式，我检查了节点的IPVS规则：

bash复制ipvsadm -Ln

输出显示10.233.64.1:443确实有转发规则，指向Master节点的真实IP 180.64.10.127:6443：

code复制TCP  10.233.64.1:443 rr
  -> 180.64.10.127:6443    Masq    1      2          0

手动测试这个真实端点：

bash复制telnet 180.64.10.127 6443

发现连接完全正常。这说明：

1. 节点间基础网络是通的
2. API Server服务是健康的
3. 问题出在IPVS的转发环节

2.3 连接状态分析

进一步检查IPVS的连接状态：

bash复制ipvsadm -lnc

发现了大量SYN_RECV状态的连接：

code复制TCP 00:51 SYN_RECV 10.233.64.1:35336 10.233.64.1:443 180.64.10.127:6443

SYN_RECV表示IPVS收到了SYN包并回复了SYN-ACK，但没有收到客户端的ACK确认。这通常意味着：

• 网络存在不对称路由
• 防火墙丢弃了ACK包
• 内核参数配置不当

3. 深入分析：IPVS转发异常的根源探究

3.1 IPVS工作原理剖析

在IPVS模式下，kube-proxy会：

1. 创建虚拟网卡kube-ipvs0
2. 将所有Service的ClusterIP绑定到该网卡
3. 设置IPVS规则将虚拟IP流量转发到实际Endpoint

bash复制ip addr show kube-ipvs0

这个设计使得ClusterIP可以像真实IP一样响应ping请求（因此之前ping通是正常的），但实际服务访问依赖IPVS的转发规则。

3.2 可能的原因排查

经过大量测试和资料查阅，我总结了几个可能导致IPVS转发失败的原因：

1. conntrack冲突：IPVS依赖conntrack模块，可能与其他网络组件冲突
2. 内核版本问题：某些内核版本的IPVS实现存在已知bug
3. 网络策略限制：Calico的网络策略可能意外拦截了IPVS流量
4. MTU不匹配：节点间MTU设置不一致导致大包被丢弃

通过逐一排查：

• 检查conntrack表未发现异常
• 内核版本为5.4，没有已知的IPVS严重bug
• 临时禁用Calico网络策略问题依旧
• MTU设置完全一致

4. 解决方案：切换IPTables模式的实战过程

4.1 模式切换操作步骤

在无法立即定位根本原因的情况下，我决定先将kube-proxy切换为IPTables模式：

1. 修改kube-proxy配置：

bash复制kubectl edit cm kube-proxy -n kube-system

将mode: ipvs改为mode: ""（空值表示使用IPTables）

2. 删除kube-proxy Pod触发重建：

bash复制kubectl delete pod -l k8s-app=kube-proxy -n kube-system

3. 清理残留的IPVS规则：

bash复制ipvsadm --clear

4.2 切换后的验证

等待组件重建完成后，验证结果：

1. Calico Pod恢复正常运行状态
2. 测试ClusterIP访问：

bash复制telnet 10.233.64.1 443

现在可以正常连接了！不过有趣的是：

bash复制ping 10.233.64.1

这次ping不通了——这正是IPTables模式与IPVS模式的区别特征。

4.3 IPTables模式下的网络行为

在IPTables模式下：

• ClusterIP不会绑定到任何网卡
• 所有转发由iptables规则直接处理
• 因此ping不通ClusterIP是正常现象
• 但服务访问通过iptables规则可以正常工作

检查iptables规则可以看到详细的转发链：

bash复制iptables-save | grep KUBE-SVC

5. 经验总结与深度思考

5.1 问题排查的方法论

这次故障排查经历让我总结出一个K8S网络问题的通用排查思路：

1. 现象确认：明确故障的具体表现和影响范围
2. 链路分解：将复杂的网络路径拆解为多个可测试的环节
3. 逐层验证：从底层网络到上层转发逐层排除
4. 对比分析：在正常和异常环境间寻找差异点
5. 安全回退：在无法快速定位时要有备选方案

5.2 IPVS与IPTables的选型建议

虽然这次我们暂时切换到了IPTables模式，但并不意味着IPVS不好。事实上，IPVS在大规模集群中有明显优势：

• 性能更高：使用哈希表存储规则，适合大量Service的场景
• 调度算法丰富：支持轮询、最少连接等多种调度策略
• 连接保持：支持持久化服务(Persistent Service)

而IPTables的优势在于：

• 稳定性更好：经过更长时间的实践检验
• 排查方便：规则更直观容易理解
• 兼容性广：对内核版本要求较低

5.3 后续优化方向

虽然问题暂时解决，但留下了几个待办事项：

1. 深入研究IPVS转发失败的根因
2. 考虑升级内核到最新稳定版再测试IPVS
3. 评估使用eBPF模式的可能性
4. 完善集群的网络监控体系

这次排查也提醒我，在生产环境使用较新的网络特性时，一定要：

• 充分测试各种边界场景
• 准备好回退方案
• 建立详细的监控指标

网络问题往往是最难排查的，但每次解决都能带来宝贵的经验。记录下整个过程，希望能帮助到遇到类似问题的同行。