Kubernetes网络故障排查：Calico升级后部分节点网络连接异常分析

问题背景

在企业级Kubernetes生产环境中，网络组件的稳定性至关重要。近期某企业在将Kubernetes控制平面升级至1.29版本，同时将Calico CNI插件升级至v3.28.2后，发现部分工作节点上的Pod出现网络连接异常。这些Pod无法ping通节点IP地址，也无法访问kube-dns服务，但节点本身可以正常查询kube-dns。重启节点可以临时解决问题，但需要找到根本原因。

故障现象深度分析

经过详细排查，发现以下关键现象：

1. 网络连通性异常：受影响的Pod无法与节点IP通信，也无法访问集群DNS服务，但节点本身可以正常解析DNS查询。

2. 组件状态正常：Calico-node Pod运行状态显示正常，日志中未发现明显错误信息。

3. 服务重启无效：尝试重启kubelet、kube-proxy、containerd等服务以及Calico-node Pod均未能解决问题。

4. 网络工具检查：执行常规网络故障排查步骤，包括刷新conntrack表、清理iptables规则等操作，问题依然存在。

5. 节点重启有效：只有完全重启受影响的节点才能暂时恢复网络功能。

根本原因探究

深入分析后发现，问题的根源在于iptables版本切换导致的规则不一致。具体表现为：

1. 历史配置遗留：系统原先使用的是iptables-legacy版本，但在升级过程中被用户移除。

2. 新规则创建位置错误：Calico组件重启后，新的网络规则被创建在了iptables-nft中。

3. 规则集分裂：系统同时存在两套不完整的规则集——旧规则残留在iptables-legacy中，新规则在iptables-nft中。

4. 流量处理异常：虽然从节点ping Pod时，tcpdump显示Pod已发送回复包，但由于iptables规则不一致，这些回复包未能正确返回到源端。

解决方案与实施步骤

针对这一复杂问题，我们采取了以下解决措施：

1. 恢复iptables-legacy：

   • 重新安装iptables-legacy工具包
   • 确保系统具备完整的iptables-legacy支持

2. 全面清理规则集：

   • 对iptables-nft进行彻底刷新
   • 同步清理iptables-legacy中的残留规则

3. 统一iptables版本：

   • 确认系统默认使用的iptables版本
   • 确保所有网络组件使用同一版本的iptables

4. 规则重建：

   • 重启Calico组件，使其在统一的iptables版本中重建完整规则集

经验总结与最佳实践

通过这次故障处理，我们总结了以下重要经验：

1. 升级前检查：在进行Kubernetes或CNI组件升级前，必须全面检查系统依赖项的状态，特别是网络工具链的版本一致性。

2. iptables管理规范：

   • 避免在生产环境中随意移除系统组件
   • 建立iptables版本变更的审批流程
   • 记录系统中使用的iptables实现版本

3. 故障排查方法论：

   • 当出现网络连通性问题时，应同时检查多个iptables实现版本
   • 使用tcpdump等工具进行端到端流量分析
   • 对比健康节点与故障节点的规则差异

4. 环境一致性保障：

   • 使用配置管理工具确保所有节点的网络配置一致
   • 建立节点网络配置的基线检查机制

结语

Kubernetes网络问题往往涉及多个层次的复杂交互。本次故障揭示了iptables实现版本不一致可能导致的隐蔽问题。通过系统化的排查方法和深入的技术分析，我们不仅解决了当前问题，还建立了更完善的网络变更管理流程，为后续的集群运维工作积累了宝贵经验。建议企业在进行类似升级时，提前制定详细的回滚方案，并在测试环境中充分验证网络组件的兼容性。