Kube-Router中TCP连接在节点故障时的优雅处理方案

在Kubernetes网络环境中，使用kube-router作为网络解决方案时，我们可能会遇到一个典型的TCP连接可靠性问题：当集群中接收TCP SYN包的节点发生故障时，虽然后端Pod仍然健康运行，但已建立的TCP连接却无法自动迁移到其他节点继续工作。这种情况在使用了DSR（Direct Server Return）和Maglev哈希算法的服务中尤为明显。

问题本质分析

在标准的kube-router部署中，当客户端通过BGP宣告的anycast地址建立TCP连接时，连接会被特定的集群节点（假设为Node A）处理。Node A通过IPVS的Maglev算法选择一个后端Pod，并建立连接状态记录。此时如果Node A突然下线（如节点崩溃或BGP宣告撤销），客户端流量会被路由到其他节点（如Node B）。

问题的关键在于：

1. Node B没有原始TCP会话的状态信息
2. 按照默认的IPVS严格TCP模式，Node B会丢弃这些"陌生"的TCP包
3. 客户端需要重新建立连接，导致现有会话中断

解决方案：sloppy_tcp模式

Linux内核提供了net.ipv4.vs.sloppy_tcp参数来解决这类问题。当设置为1时，IPVS会进入"宽松"TCP模式，具有以下特性：

1. 允许节点处理不属于本地建立的TCP会话
2. 不严格检查TCP状态机完整性
3. 在节点故障转移场景下保持连接连续性

实现方式

可以通过以下命令临时启用该特性：

sysctl -w net.ipv4.vs.sloppy_tcp=1

或者永久生效：

echo "net.ipv4.vs.sloppy_tcp=1" >> /etc/sysctl.conf
sysctl -p

生产环境建议

虽然sloppy_tcp模式解决了连接迁移问题，但需要注意：

1. 这是一个节点级别的全局设置，会影响所有IPVS服务
2. 可能略微增加节点的处理开销
3. 在安全性要求极高的环境中需要评估风险

对于kube-router用户，可以考虑在以下场景启用此功能：

• 使用DSR+Maglev的服务
• 需要高可用性的长连接服务（如数据库连接）
• 能够容忍轻微的性能损耗

未来优化方向

kube-router未来版本可以考虑：

1. 自动为启用DSR+Maglev的服务设置sloppy_tcp
2. 提供细粒度的服务级别控制
3. 在文档中明确记录这一行为特性

通过合理配置sloppy_tcp参数，可以显著提升kube-router在网络故障场景下的连接恢复能力，为关键业务提供更稳定的网络服务。