iptables 和 IPVS 是 Linux 内核中两种四层（TCP/UDP）流量转发/负载均衡技术 ，均基于 netfilter 框架，iptables 是"通用防火墙工具+转发功能"，IPVS 是"专用四层负载均衡模块"
一、核心区别
| 对比维度 | iptables | IPVS（IP Virtual Server） |
|---|---|---|
| 核心定位 | 基于 netfilter 的通用防火墙工具，附带四层转发/DNAT 功能 | 基于 netfilter 的专用四层负载均衡内核模块，专注于 VIP→RIP 转发 |
| 设计目标 | 报文过滤、NAT、端口转发、简单负载均衡，功能全面 | 高性能、高并发的负载均衡，解决大规模后端节点的转发瓶颈 |
| 规则存储结构 | 线性链表（按顺序匹配规则），规则数越多，匹配效率越低（O(n) 复杂度） | 树状结构+哈希表（按 VIP/端口快速匹配），匹配效率与规则数无关（O(1) 复杂度） |
| 负载均衡算法 | 仅支持简单轮询（默认），无内置高级算法，需手动编写复杂规则实现哈希/会话保持 | 内置 10+ 算法（轮询 rr、加权轮询 wrr、源 IP 哈希 sh、最少连接 lc 等），原生支持会话保持 |
| 适用场景 | 小规模集群（节点数＜100）、简单转发/过滤需求、无性能压力的场景 | 大规模集群（节点数＞100）、高并发服务（如 K8s Service）、需要高效负载均衡的场景 |
| K8s 中的角色 | kube-proxy 的默认模式，适合小规模 K8s 集群 | kube-proxy 的推荐模式，适合大规模 K8s 集群（解决 iptables 性能瓶颈） |
| 内核依赖 | 依赖 ip_tables 内核模块，基于 netfilter 钩子点（PRE_ROUTING/OUTPUT 等） |
依赖 ip_vs 系列内核模块（ip_vs、ip_vs_rr、ip_vs_sh 等），挂载 netfilter PRE_ROUTING 钩子点 |
| 会话保持能力 | 需通过 conntrack 模块+复杂规则实现，性能开销大 |
原生支持源 IP 哈希（sh）、持久连接（persistent），性能开销低 |
| 后端健康检查 | 无原生健康检查，需手动结合 health-check 脚本或第三方工具 |
支持原生后端健康检查（如 tcp/udp 端口检测），自动剔除不可用节点 |
| 配置复杂度 | 语法复杂，负载均衡需编写多条规则（如 DNAT+SNAT+conntrack） | 语法简洁，通过 ipvsadm 工具直接绑定 VIP 与后端 RIP，配置直观 |
| 性能表现 | 规则数超 1000 条后，转发延迟显著增加，并发能力有限 | 支持 10 万+ 并发连接，转发延迟低，规则数增加不影响性能 |
二、关键差异
1. 设计理念："通用工具" vs "专用模块"
- iptables：本质是"防火墙工具"，负载均衡只是其"附加功能"（通过 DNAT 实现）。它的核心是"规则匹配"，不仅能转发流量，还能过滤报文、修改头部、做 NAT 等，功能全面但不专注。
- IPVS：从设计之初就是"为负载均衡而生"的内核模块，仅专注于"将 VIP 收到的流量高效转发到后端 RIP"，不具备防火墙过滤、报文修改等额外功能，但在负载均衡场景下更高效。
2. 性能瓶颈："线性匹配" vs "哈希查找"
- iptables：所有规则按"线性链表"存储，报文到达时需按顺序遍历所有规则，直到找到匹配项。当 K8s 集群中 Service/Pod 数量多（规则数超 1000），遍历耗时会急剧增加，导致转发延迟升高。
- IPVS：规则存储在"哈希表"中，按 VIP+端口作为哈希键，直接定位到对应的后端 RIP 列表，无需遍历所有规则。即使后端节点数达 1 万+，匹配耗时仍可忽略，性能几乎不受影响。
3. K8s 中的实际应用差异
K8s 的 kube-proxy 支持两种模式，直接体现二者差异：
- iptables 模式：kube-proxy 监控 Service/Endpoint 变化，动态生成 iptables 规则（DNAT 转发）。优点是无需额外依赖，部署简单；缺点是大规模集群（Pod 数超 1000）时，规则爆炸导致性能下降，且无原生健康检查。
- IPVS 模式 ：kube-proxy 动态生成 IPVS 规则（VIP 绑定 RIP）。优点是性能优异，支持会话保持和健康检查，适合生产环境大规模集群；缺点是需要提前加载
ip_vs系列内核模块，部署时需额外配置。
4. 健康检查："无原生支持" vs "原生集成"
- iptables ：无法直接检测后端节点是否可用，即使后端 Pod 下线，iptables 规则仍会将流量转发过去，导致请求失败。需结合
livenessProbe+第三方脚本清理无效规则，配置复杂。 - IPVS：原生支持后端健康检查（如定时检测 RIP 的端口是否存活），当后端 Pod 下线时，自动将其从 RIP 列表中剔除，流量不再转发，无需额外工具，可靠性更高。
三、适用场景选择
| 场景类型 | 推荐使用 | 不推荐使用 |
|---|---|---|
| K8s 集群规模 | 小规模（节点＜100）→ iptables；大规模（节点＞100）→ IPVS | 大规模集群用 iptables；小规模集群用 IPVS（配置冗余） |
| 业务需求 | 需防火墙过滤+转发 → iptables；仅需负载均衡+高并发 → IPVS | 高并发场景用 iptables；需复杂过滤用 IPVS |
| 运维复杂度要求 | 追求部署简单 → iptables；追求性能+可靠性 → IPVS | 无特殊过滤需求却用 iptables 扛高并发 |
总结：
iptables 是"通用防火墙+附加转发功能"，线性规则匹配，适合小规模场景；IPVS 是"专用四层负载均衡模块"，哈希匹配+原生健康检查，性能优异，适合大规模 K8s 集群等高并发场景，二者均基于 netfilter 框架，但定位和性能差异显著。