在 Kubernetes 集群中，Service 后端的 Endpoint 数量会随着业务规模快速增长。当 Endpoint 从几十个增加到上万个时，转发规则的查找方式直接决定了请求延迟和吞吐上限。IPVS 作为 Linux 内核提供的四层负载均衡模块，把端点管理放在内核态完成，并通过哈希表实现近似常数时间的查找，这是它在大规模端点场景下相比 iptables 和用户态代理的核心优势。
IPVS 在内核数据路径上如何实现快速查找
IPVS 的工作位置在 Netfilter 框架中，它会在数据包进入转发路径后、到达上层协议栈之前完成虚拟服务到真实端点的映射。虚拟服务由协议、IP 地址和端口三元组唯一确定，后端端点则记录目标 IP、端口和转发模式。IPVS 把这些关系组织成哈希表，查找时先计算虚拟服务的哈希值，再根据调度算法选中一个端点，整个过程不依赖规则数量，时间复杂度近似 O(1)。
相比之下，iptables 的 NAT 规则是一条条线性匹配的。以 kube-proxy 的 iptables 模式为例，当 Service 后端有 N 个 Endpoint 时，内核需要遍历多条 PREROUTING、OUTPUT 和 POSTROUTING 链上的规则，直到命中一条 DNAT 或 MASQUERADE 规则。N 越大，每个新建连接消耗的 CPU 就越多。实测中，规则数从 1000 增长到 10000 时，iptables 模式的新建连接速率会明显下滑，而 IPVS 几乎没有变化，因为它的查找成本与规则总量解耦。
IPVS 的端点对象在内存中连续分配，访问时更容易命中 CPU 缓存。数据包只需要读取服务结构和端点结构，不像 iptables 那样需要在多个规则结构之间跳转。对于高并发短连接业务，这种数据局部性带来的收益非常可观，它减少了 CPU 缓存失效次数，也降低了内核态处理延迟。
调度算法与连接状态对万级端点的意义
IPVS 内置了多种调度算法，包括轮询 rr、加权轮询 wrr、最少连接 lc、加权最少连接 wlc、源地址哈希 sh 和目标地址哈希 dh 等。大规模端点场景下，简单轮询容易让不同处理能力的节点负载不均，而加权最少连接会根据当前活跃连接数和预设权重动态选择端点，能够有效避免慢节点堆积连接。
连接保持是另一个关键能力。IPVS 会为每个活跃连接维护一条内核态连接表，同一 TCP 连接的所有数据包都会命中同一条表项，从而持续转发到同一个后端端点，避免中途切换目标导致连接中断。连接表项在连接结束后进入空闲链表，达到超时时间才被回收，这种设计既保证了连接一致性，又减少了频繁分配内存的开销。
以下配置展示了如何用 ipvsadm 创建一个加权轮询的虚拟服务，并添加两个权重不同的端点。权重越高，分配到的流量比例越大。
# 添加虚拟服务，使用加权轮询调度算法 ipvsadm -A -t 192.168.10.10:80 -s wrr # 添加两个真实端点，权重分别为 1 和 2 ipvsadm -a -t 192.168.10.10:80 -r 10.0.1.10:8080 -m -w 1 ipvsadm -a -t 192.168.10.10:80 -r 10.0.1.11:8080 -m -w 2 # 查看当前规则与连接统计 ipvsadm -L -n --stats
在大规模部署中，权重通常根据节点的 CPU 核数、内存容量或历史负载动态调整。例如 8 核节点和 4 核节点同时作为端点时，可以分别设置权重 8 和 4，让流量分配更贴合硬件能力。配合监控系统定期采集节点指标，还能够自动更新 ipvsadm 规则，避免人工维护几万个端点时出现误差。
与 iptables 和用户态代理的性能差异
用户态代理需要在用户空间和内核空间之间复制数据，每个请求都要经历 socket 读写、上下文切换和协议栈处理。IPVS 只在内核中修改 IP 头和 TCP 端口，数据面不经过用户态，因此吞吐更高、延迟更低。即便与同样运行在内核态的 iptables 相比，IPVS 的哈希查找也远比线性规则匹配高效。
iptables 的 DNAT 依赖连接跟踪 conntrack 来记录地址转换关系。大规模连接数下，conntrack 表会占用大量内存，并且每条新连接都需要创建跟踪项，带来额外的 CPU 开销。IPVS 可以选择不依赖 conntrack，或者仅在需要时启用，从而大幅减少连接跟踪带来的压力。可以通过内核参数关闭 IPVS 服务上的 conntrack 绑定，进一步提升转发效率。
下表从几个核心维度对比了两者在万级端点场景下的表现。
| 对比维度 | iptables | IPVS |
|---|---|---|
| 规则查找方式 | 线性遍历规则链 | 哈希表近似 O(1) 查找 |
| 数据路径 | 内核态 NAT | 内核态四层转发 |
| 连接跟踪依赖 | 强依赖 conntrack | 可选，可按需关闭 |
| 调度算法 | 仅随机或轮询模拟 | 支持 wrr、lc、wlc、sh 等 |
| 大规模规则性能 | 随规则数增长明显下降 | 增长平缓，CPU 占用稳定 |
从表格可以看出，IPVS 的优势并不是某项单一技术，而是查找结构、数据路径和连接管理共同作用的结果。这也是为什么在高密度 Service 环境下，很多团队会把 kube-proxy 从 iptables 模式切换到 IPVS 模式。
大规模端点场景下的配置与调优实践
要在 Linux 上启用 IPVS，需要先加载必要的内核模块。对于 Kubernetes 集群，可以确保 ip_vs、ip_vs_rr、ip_vs_wrr、ip_vs_sh 和 nf_conntrack 模块已经加载，然后重启 kube-proxy 并指定 IPVS 模式。加载模块的操作通常写入节点初始化脚本，避免节点重启后失效。
# 加载 IPVS 相关内核模块 modprobe ip_vs modprobe ip_vs_rr modprobe ip_vs_wrr modprobe ip_vs_sh modprobe nf_conntrack # 检查模块加载状态 lsmod | grep ip_vs
对于大规模端点，建议关闭 IPVS 与 conntrack 的绑定，并为连接过期和空闲连接回收调整参数。这样可以在连接数达到几十万甚至上百万时减少内存占用，同时避免 conntrack 表成为瓶颈。
# 关闭 IPVS 的 conntrack 关联 net.ipv4.vs.conntrack = 0 # 及时回收无目标端点的连接 net.ipv4.vs.expire_nodest_conn = 1 # 及时回收无可用端点的连接模板 net.ipv4.vs.expire_quiescent_template = 1
配置完成后，可以通过 ipvsadm -L -n --stats 观察每个虚拟服务的连接数、报文数和字节数，重点关注是否存在连接堆积或调度不均的情况。如果使用 keepalived 管理虚拟服务，还可以把健康检查与权重调整联动，自动摘除不健康的端点，让大规模集群在端点频繁扩缩容时保持稳定。
综合来看，IPVS 在内核态哈希查找、多调度算法、低资源占用和连接管理方面都更适合大规模端点场景。对于运行着数万个 Service 和 Endpoint 的生产集群，切换到 IPVS 通常能显著降低 kube-proxy 的 CPU 使用率，并减少转发规则重建时对节点性能的冲击。实践中还应结合内核版本、网络插件和具体业务模型，持续观察调度指标，才能把 IPVS 的性能优势充分发挥出来。