RKE2项目中rke2-canal Pod重启导致外部连接中断问题分析

问题背景

在RKE2集群环境中，当rke2-canal Pod进行重启时，运行在同一节点上的容器会出现短暂的外部连接中断现象。这个问题在RKE2 v1.30及以上版本中被首次报告，但后续测试发现其实在更早版本(v1.29)中就已存在。

技术现象

具体表现为：

1. 当删除或重启节点上的rke2-canal Pod时
2. 该节点上的Pod会暂时失去与集群外部服务的连接能力
3. 集群内部Pod之间的通信不受影响
4. 问题持续时间与rke2-canal Pod的重启时间一致

根本原因分析

通过深入排查发现，问题的根源在于Flannel组件对iptables规则的处理方式。具体表现为：

1. 在rke2-canal Pod停止时，Flannel会清除所有自己创建的iptables规则
2. 关键的FLANNEL-POSTRTG链中的规则会被完全移除
3. 这些规则负责处理Pod与外部网络通信时的NAT转换
4. 直到rke2-canal Pod完全重启并重新配置这些规则，外部连接才会恢复

技术细节

FLANNEL-POSTRTG链中的规则主要包含以下几类重要规则：

1. 对特定标记数据包的直接放行
2. 集群内部Pod间通信的特殊处理
3. 最重要的两条MASQUERADE规则：
   • 处理从Pod网段(10.42.0.0/16)发往非组播地址的流量
   • 处理从非Pod网段发往Pod网段的流量

这些规则的临时缺失导致Pod发出的外部请求无法正确进行NAT转换，从而造成连接中断。

解决方案

RKE2团队已经通过以下方式解决了该问题：

1. 修改了Flannel组件的行为，不再在Pod停止时清除iptables规则
2. 保持了规则的持久性，确保在组件重启期间网络功能不受影响
3. 该修复已包含在后续的Flannel版本更新中

验证方法

用户可以通过以下步骤验证修复效果：

1. 部署一个测试Pod(如multitool)
2. 在Pod中运行持续访问外部服务的测试命令
3. 手动重启节点上的rke2-canal Pod
4. 观察测试命令的输出是否出现中断

最佳实践建议

对于生产环境中的RKE2集群，建议：

1. 及时升级到包含此修复的RKE2版本
2. 对于关键业务Pod，考虑使用Pod反亲和性避免与rke2-canal Pod同节点
3. 在维护窗口期进行网络组件相关的操作
4. 监控集群网络状态，特别是NAT规则的变化

总结

这个问题展示了Kubernetes网络组件实现细节对集群稳定性的重要影响。通过理解CNI插件与底层网络规则的关系，运维人员可以更好地诊断和解决类似的网络问题。RKE2团队对此问题的快速响应和解决也体现了开源社区协作的优势。