告别 Iptables 时代：Kubernetes 网络数据平面的 Nftables 革命
在 Kubernetes 的网络世界里，kube-proxy 长期扮演着“守门人”的角色，负责将 Service 的流量分发到后端的 Pod。然而，长久以来，我们一直忍受着 iptables 模式带来的性能折磨，或被迫迁移到维护复杂的 IPVS 模式。
时间来到 2026 年，随着 Kubernetes 1.33 于 2025 年 4 月正式 GA（General Availability），nftables 模式已不再是实验性的选项，而是成为了生产环境的“新标配”。甚至在 2025 年底发布的 v1.35 中，曾经的救火队员 ipvs 模式已被正式标记为 弃用（Deprecated）。这标志着 Linux 内核网络栈在云原生时代的一次彻底“正本清源”。
本文将结合最新的基准测试数据，深入探讨 nftables 对 K8s 的核心意义，并盘点各大云厂商的支持现状与未来路线。
一、 为什么 K8s 急需 nftables？
要理解 nftables 的革命性，首先要回顾 iptables 和 IPVS 的痛点。
1. 性能：从线性扫描到 O(1) 查找
- iptables 的噩梦：iptables 的设计是线性的。每当一个数据包到达，内核必须逐条匹配规则。如果你有 5,000 个 Service，每个 Service 对应 10 个 Pod，iptables 链表可能长达数万条。这导致了 O(N) 的延迟——Service 越多，网络越慢。更糟糕的是，更新规则时，必须全量刷新整个表，导致 CPU 飙升。
- nftables 的解法：nftables 引入了 Maps (映射) 和 Sets (集合) 数据结构。
- 查找：无论规则集多大，匹配过程都是基于哈希的 O(1) 操作。
- 更新：支持原子增量更新。新增一个 Pod，只需向 Map 中插入一条记录，无需重刷整个规则集。
2. 架构：终结 IPVS 的“权宜之计”
过去几年，为了规避 iptables 的性能问题，大规模集群不得不切换到 IPVS。但 IPVS 是为了负载均衡设计的，缺乏防火墙能力。因此，kube-proxy 的 IPVS 模式实际上是 “IPVS 做转发 + iptables 做过滤” 的怪胎。这种双栈架构极难调试，且 IPVS 的连接跟踪（Conntrack）逻辑在高并发下偶发丢包。
nftables 统一了这一切。它既具备 IPVS 的哈希查找性能，又拥有比 iptables 更强的防火墙编程能力。它让 K8s 网络栈回归到了纯粹、统一的单层架构。
3. 安全与双栈：原生支持
- 原子性：iptables 更新时缺乏事务性，可能在规则刷新的毫秒级窗口内导致流量黑洞。nftables 的事务机制保证了规则变更要么全成，要么全败，消除了“瞬间断网”的隐患。
- 双栈统一：在 IPv6 普及的今天，nftables 的
inet表允许一条规则同时治理 IPv4 和 IPv6 流量，运维复杂度直接减半。
二、 性能碾压：Nftables 基准测试真相 (2026)
根据 Kubernetes 社区及 Azure AKS 团队在 2025 年底发布的测试报告，在包含 30,000 个 Service 的超大规模集群中，nftables 展现出了惊人的性能统治力。
| 指标 | iptables | IPVS | nftables | 结论 |
|---|---|---|---|---|
| 规则更新复杂度 | O(N) | O(1) | O(1) | 完胜 iptables |
| 数据包延迟 (P99) | > 5 ms | ~0.1 ms | < 0.1 ms | 比 iptables 快 50 倍+ |
| CPU 消耗 (空闲) | 低 | 略高 | 极低 | 无需维护复杂哈希表 |
| 规则同步时间 | 10s+ | < 1s | < 0.5s | 原子增量更新 |
关键数据解读
- P99 延迟：在 3 万个 Service 的压力下，nftables 的 P99（最慢的 1% 请求）延迟 竟然比 iptables 的 P01（最快的 1% 请求） 还要快！这意味着 nftables 的“最差表现”都吊打 iptables 的“最佳表现”。
- CPU 减负：测试发现，在大规模集群中，iptables 模式下的 kube-proxy 即使在没有流量时，也会因为频繁的全量同步规则而占用大量 CPU（单核 35% 以上）。而 nftables 模式下，kube-proxy 的 CPU 占用率几乎可以忽略不计。
三、 2026 年公有云支持现状与路线图
在 2026 年，nftables 已经成为各大云厂商托管 K8s 服务的主流演进方向，但默认策略依然保守。
1. Azure AKS (Azure Kubernetes Service)
- 现状：AKS 是 nftables 的早期支持者，也是最激进的推动者。在 2025 年 11 月就已发布了
NFTABLES模式的预览版（Preview）。 - 路线图：2026 年已全面 GA。AKS 极有可能在 2026 年下半年发布的 Azure Linux (Mariner) 节点池中率先将其设为默认。
2. AWS EKS (Amazon Elastic Kubernetes Service)
- 现状：EKS 在其最新的优化版 AMI（Amazon Linux 2023/2025）中已完全包含 nftables 用户态工具。
- 支持度：EKS 官方支持在自管理节点组中通过
bootstrap.sh参数开启 nftables 模式。 - 路线图：AWS 计划在 2026 年底的 EKS 新版本（对应 K8s 1.35+）中，将 nftables 设为新建集群的推荐默认值，逐步淘汰 IPVS 模式支持。
3. Google GKE (Google Kubernetes Engine)
- 现状：GKE 的战略重心始终是 Dataplane V2 (eBPF/Cilium)，这是比 nftables 更高性能的“降维打击”方案，完全绕过了 kube-proxy。
- 路线图：对于非 Dataplane V2 的标准集群，GKE 会跟进上游支持 nftables，但并不将其作为主要卖点。如果你在 GKE 上追求极致性能，eBPF 依然是首选。
4. 阿里云 ACK & 腾讯云 TKE
- 现状：国内大厂依然拥有大量存量 IPVS 用户。Alibaba Cloud Linux 3 已经具备了良好的 nftables 内核基础，并已在 2025 年解决了兼容性问题。
- 路线图：采取**“长期并存”**策略。短期内不会强制切换默认值，但会在高性能计算型节点池中推荐使用 nftables。
四、 落地建议：我们要不要切？
给自建 K8s 用户的建议
如果你的集群满足以下条件，强烈建议切换到 nftables：
- OS 较新：内核版本 ≥ 5.13（推荐 6.x），且使用 Debian 12+、Ubuntu 22.04+、RHEL 9+ 等现代发行版。
- 规模中大：Service 数量超过 500 个，或者 Pod 变动频繁。
- 深受 iptables 苦恼：经历过规则刷新导致的 CPU 告警或网络抖动。
迁移警告：请务必检查你的 CNI 插件（如 Calico, Flannel）版本。Calico 和 Flannel 等主流插件在 2025 年间均发布了支持 nftables 后端的新版本。如果 CNI 仍在盲目操作 iptables，确实会造成规则冲突。务必升级到 2025/2026 年发布的最新 CNI 版本。
给公有云托管用户的建议
- GKE 用户：继续使用 Dataplane V2 (eBPF)，无需关心 kube-proxy 模式。
- EKS/AKS/ACK 用户：
- 新业务：可以在测试环境大胆尝试 nftables 模式。它比 IPVS 更稳定，比 iptables 更快。
- 存量业务：如果现在的 IPVS 模式运行平稳，不要为了切而切。IPVS 在 2026 年依然是稳定可靠的，且性能差距在非超大规模下并不明显。等待云厂商官方宣布将 nftables 设为默认后再平滑升级是更稳妥的策略。
结语
2026 年，nftables 终于让 Linux 防火墙摘掉了“性能瓶颈”的帽子。对于 Kubernetes 而言，这不仅是一次性能优化，更是一场迟到了十年的技术还债。无论你是激进的架构师还是稳健的运维专家，nftables 都是你必须放入工具箱的未来标准。