从 iptables 切换到 IPVS：为什么你的 K8s 长连接业务出现了更多的 Connect Timeout？

2026/6/2 21:55:48 33 0 0 0

在 Kubernetes 集群规模扩大、Service 数量激增时，许多团队会选择将 kube-proxy 的模式从默认的 iptables 切换为基于 IPVS 的模式。理论上，IPVS 凭借其 O(1) 复杂度的哈希表查询，在性能上应该完胜基于 O(N) 线性扫描的 iptables。

然而，在实际的生产环境中，不少团队在切换到 IPVS 后，尤其是对于高并发、长连接的业务场景（如微服务间的 gRPC 框架、高频数据库连接池），不仅没有迎来预期的性能飙升，反而频繁遭遇 connect timeout（连接超时）和长连接无故中断的问题。

这并非 IPVS 本身的设计缺陷，而是因为 IPVS 的连接跟踪与状态老化机制、内核端口复用逻辑，与传统的 iptables（基于 Netfilter conntrack）存在着巨大的差异。

一、长链接业务在 IPVS 模式下的 NAT 表现变化

要理解为什么长连接会出问题，首先需要对比 iptables 和 IPVS 在处理长连接时的底层 NAT 机制。

1. 为什么长连接在 IPVS 下容易无故“断开”？

无论是 iptables 还是 IPVS，为了让 Pod 之间通过 ClusterIP 进行通信，都需要在内核态进行 DNAT（目的地址转换）。

iptables 模式下：
iptables 完全依赖 Netfilter 的 nf_conntrack（连接跟踪表）来记录 NAT 映射关系。在 Linux 内核中，对于已经建立（ESTABLISHED）的 TCP 连接，nf_conntrack 的默认老化时间非常长（通常是 net.netfilter.nf_conntrack_tcp_timeout_established = 432000 秒，即 5 天）。这意味着，只要连接建立成功，即使应用层长时间没有数据往来，这个连接在内核的跟踪表中也会被保留极长时间，不会丢失 NAT 映射。
IPVS 模式下：
IPVS 虽然也依赖 nf_conntrack 处理一些底层的包过滤，但它**拥有自己独立的连接表（IPVS Connection Table）**来维护 VIP 到 Real Server（Pod IP）的映射。
IPVS 默认的 TCP 连接超时时间通常只有 900 秒（15分钟）（可以通过 ipvsadm -L --timeout 查看）。

这就导致了一个致命的温水煮青蛙效应：
如果你的业务采用长连接（如数据库连接池、未启用 Keepalive 的 gRPC 通道），并且在业务低峰期存在超过 15 分钟的空闲期（无任何数据交互）。

15分钟过后：IPVS 内部的连接跟踪条目已经老化并被静默删除。但此时，客户端和服务器（Pod）的套接字依然处于 ESTABLISHED 状态（因为没有任何一方发送 FIN 或 RST）。
下一次数据发送时：客户端通过原连接发送 TCP 数据包。当包到达 IPVS 节点时，IPVS 查表发现该连接已不存在，不会对其进行 DNAT 转换。
结果：这个数据包会被直接当成发送给 ClusterIP 本身的数据包处理，或者因为找不到对应的后端 Pod 而被丢弃（或者是发送 RST 包）。客户端会因此报出 connection reset by peer 或发生 TCP 重传，最终导致连接彻底中断。

二、为什么高并发下 IPVS 反而出现更多 `connect timeout`？

如果说长连接空闲中断是“温水煮青蛙”，那么在高并发、高频新建/销毁连接的场景下，IPVS 带来的 connect timeout 就是暴风雨式的灾难。其核心根源主要有以下两点：

1. `conn_reuse_mode` 引起的 SYN 包静默丢弃（Silent Drop）

这是 K8s 社区中最经典的 IPVS 坑，涉及内核参数 net.ipv4.vs.conn_reuse_mode。

背景机制：

当客户端使用短连接或高频重建长连接时，本地端口（Ephemeral Ports）在关闭后会进入 TIME_WAIT 状态。高并发下，这些端口会很快被复用。
如果客户端复用了一个处于 TIME_WAIT 状态的端口（具有相同的源 IP、源端口、目的 IP、目的端口四元组），向 IPVS 发送一个新的 SYN 包。

问题所在：

如果 conn_reuse_mode 设置为 1（在较早的内核和 kube-proxy 默认配置中）：
IPVS 发现这个四元组已经在其连接表中存在（处于旧连接的 TIME_WAIT/CLOSE 状态），它会试图复用这个已有的连接条目，而不会重新为其调度（Schedule）一个新的后端 Pod。
然而，如果此时旧连接在后端 Pod 侧已经被彻底销毁（或者该 Pod 已经重启/漂移），或者旧连接的 TCP 窗口序列号（Sequence Number）与新 SYN 包不匹配，内核就会认为这是一个无效的包，从而静默丢弃（Silent Drop）这个 SYN 包。
客户端的表现：
由于 SYN 包被静默丢弃，客户端迟迟收不到 SYN-ACK。客户端的 TCP 协议栈会触发指数退避的重传机制（1秒、3秒、7秒...）。如果客户端或应用层设置的建连超时时间（Dial Timeout）比较短（例如很多微服务框架默认设置 1s 或 3s），就会直接抛出 connect timeout。

注意：Kubernetes 社区为了解决这个问题，在 v1.22 之后的 kube-proxy 中默认将 conn_reuse_mode 设为了 0（即对于新连接总是重新调度），并在高版本内核中做了大量修复。但在一些老旧的 CentOS 7.x（内核 3.10）或未升级的集群中，该问题依然是高并发超时的第一杀手。

2. IPVS 并未彻底解放 `nf_conntrack` 的瓶颈

很多开发者误以为“既然用了 IPVS，那 nf_conntrack 就不会成为瓶颈了”。这是一个极大的误区。

即使在 IPVS 模式下，流经 Kubernetes 节点的流量（尤其是涉及到 NodePort、SNAT/MASQUERADE 访问外部服务的流量）依然需要经过 Netfilter 的 nf_conntrack 模块进行状态跟踪。

高并发场景下，一旦：
$$\text{当前活跃连接数} + \text{TIME_WAIT 连接数} > \text{net.netfilter.nf_conntrack_max}$$
就会触发内核的 nf_conntrack: table full, dropping packet 警告。此时，内核会开始直接丢包，表现出来同样是客户端大面积的 connect timeout。

三、生产级排查与针对性调优方案

为了让 IPVS 在高并发和长连接场景下稳定运行，我们需要针对上述底层机制进行深度调优。

1. 彻底解决长连接因空闲老化断开的问题

方案 A：应用层启用 TCP Keepalive

这是最根本的解决方式。确保你的应用层客户端连接池（如 gRPC、Go net.Dialer、Java HttpClient）开启了 Keepalive，且 探测间隔必须小于 IPVS 的默认老化时间（15分钟）。建议设置为 30 秒或 60 秒。

方案 B：调大 IPVS 的 TCP 超时时间

如果无法修改所有应用的代码，可以直接调大内核 IPVS 的连接超时时间，使其逼近或等于系统的 conntrack 超时。
在 kube-proxy 的启动配置（ConfigMap/KubeProxyConfiguration）中，修改 ipvs.syncPeriod 或直接通过 ipvsadm 手动调整：

# 查看当前超时设置（通常输出格式为：TCP TCP_FIN UDP）
ipvsadm -L --timeout

# 将 TCP 空闲超时调大到 14400 秒（4小时），TCP_FIN 调到 120 秒，UDP 调到 300 秒
ipvsadm --set 14400 120 300

在 kube-proxy 配置中，建议设置：

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"
ipvs:
  tcpTimeout: 4h0m0s
  tcpFinTimeout: 2m0s

2. 彻底解决 `conn_reuse_mode` 导致的建连超时

如果你在 dmesg 或 syslog 中没有看到 conntrack 满的报错，但高并发下依然有 1s/3s 的建连超时，基本可以锁定是 conn_reuse_mode 的问题。

方案 A：关闭 `conn_reuse_mode`（适合旧内核）

在节点上直接关闭该参数：

sysctl -w net.ipv4.vs.conn_reuse_mode=0

注：在内核 4.19 左右的某些版本中，将该值设为 0 可能会引发另一个关于持久化连接的 bug。如果可以，强烈建议升级节点内核到 5.4+。

方案 B：优化 TCP 端口复用参数

开启 tcp_tw_reuse 允许在安全前提下复用 TIME_WAIT 端口，但必须同时开启 tcp_timestamps（高并发下非常关键）：

sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_timestamps=1

3. 防范 Netfilter Conntrack 爆满

既然 IPVS 无法免俗地要使用 conntrack，那么在高并发节点上，必须调大连接跟踪表：

# 调大连接跟踪表最大限制（根据物理内存大小，16G以上内存建议设为 1048576 或更高）
sysctl -w net.netfilter.nf_conntrack_max=1048576

# 调整哈希表 bucket 大小（通常为 max 的 1/4）
echo 262144 > /sys/module/nf_conntrack/parameters/hashsize

# 适当收紧 TIME_WAIT 的 conntrack 老化时间（默认 120 秒太长，可调至 30 秒）
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30

四、总结：iptables 与 IPVS 应该如何抉择？

维度	iptables 模式	IPVS 模式
小规模集群 (<100 Services)	推荐。简单可靠，无复杂的二次查表机制。	优势不明显，额外增加运维心智负担。
大规模集群 (>1000 Services)	不推荐。规则链条数呈 $O(N)$ 增长，刷规则时会造成明显的网络抖动和高 CPU 占用。	极力推荐。$O(1)$ 哈希查表，性能几乎不随 Service 数量增长而退化。
长连接空闲业务	默认支持良好（内核 conntrack 5天超长保留）。	需调优。默认 15 分钟超时，不进行 Keepalive 调优极易导致连接“静默死”。
高并发短连接复用	表现稳定，依靠 conntrack 机制处理端口复用。	需调优。必须妥善处理 `conn_reuse_mode` 引起的 SYN 丢包问题。

结论：
将 kube-proxy 切换至 IPVS，是大规模 Kubernetes 集群演进的必经之路。但 IPVS 绝不是“开箱即用”的万灵药。对于长链接与高并发业务，切换 IPVS 的同时，必须配套进行内核参数（conn_reuse_mode、tcpTimeout、nf_conntrack_max）的同步调优，才能真正释放 IPVS 的高性能优势。

内核与容器指北 Kubernetes IPVS 网络排障

从 iptables 切换到 IPVS：为什么你的 K8s 长连接业务出现了更多的 Connect Timeout？

一、 长链接业务在 IPVS 模式下的 NAT 表现变化

1. 为什么长连接在 IPVS 下容易无故“断开”？

二、 为什么高并发下 IPVS 反而出现更多 connect timeout？

1. conn_reuse_mode 引起的 SYN 包静默丢弃（Silent Drop）