核心结论（先说重点）：
legacy/nftables是 iptables 工具的两种实现后端（backend），它们属于 Linux 内核 netfilter 框架下的用户态工具接口。iptables/ipvs是 kube-proxy 的两种代理模式（proxy mode），用于实现 Kubernetes Service 的负载均衡。
legacy 和 nftables：iptables 的后端实现
从 Linux 内核 3.13+ 开始，引入了 nftables 作为新一代包过滤框架，逐步替代传统的 iptables/xtables。
但为了兼容，iptables 命令行工具现在可以运行在两种模式下：
| iptables-legacy | 使用传统的内核模块（如 iptable_filter, ip_tables 等） |
| iptables-nft | 实际底层使用 nftables 框架，但命令行接口仍叫 iptables（通过 xtables-nft 兼容层） |
- 在 kube-proxy 的
iptables模式下，它会动态生成大量 iptables 规则（比如每个 Service 对应多条规则）。这时，iptables 后端（legacy/nft）就很重要，因为规则写入和匹配行为必须一致。 - 在 kube-proxy 的
ipvs模式下，Service 转发由 IPVS 完成，几乎不依赖 iptables 做负载均衡（但仍可能用少量 iptables 规则处理 NodePort、包标记等辅助功能）
虽然 IPVS 模式减少了对 iptables 的依赖，但 Kubernetes 集群中仍然有多个组件会使用 iptables，因此 统一 iptables 后端（legacy 或 nftables）仍然是强烈推荐甚至必要的。
一、为什么即使使用 IPVS，仍需关注 iptables 后端？
1. kube-proxy 在 IPVS 模式下仍会使用 iptables
尽管 Service 的负载均衡由 IPVS 实现，但 kube-proxy 仍会创建少量 iptables 规则用于：
- 处理
NodePort和ExternalIPs的流量跳转到 IPVS - 实现
masquerade（SNAT），例如 Pod 访问外部网络时 - 支持
LoadBalancer类型 Service 的某些逻辑 - 处理
Hairpin流量或包标记（如--set-mark）