Farewell to Iptables: The Nftables Revolution in Kubernetes Network Data Plane

In the networking world of Kubernetes, kube-proxy has long played the role of “gatekeeper,” responsible for distributing Service traffic to backend Pods. However, for years, we’ve endured the performance pain of iptables mode or been forced to migrate to the more complex IPVS mode.

Fast forward to 2026, with Kubernetes 1.33 reaching General Availability (GA) in April 2025, nftables mode is no longer an experimental option—it has become the “new standard” for production environments. In fact, with the release of v1.35 at the end of 2025, the once-reliable ipvs mode has been officially marked as Deprecated. This marks a complete “return to fundamentals” for the Linux kernel network stack in the cloud-native era.

This article will dive deep into the core significance of nftables for K8s, backed by the latest benchmark data, and review the current support status and future roadmaps of major cloud providers.

1. Why Does K8s Urgently Need nftables?

To understand the revolutionary impact of nftables, we must first revisit the pain points of iptables and IPVS.

1.1 Performance: From Linear Scanning to O(1) Lookups

• The iptables Nightmare: iptables is designed linearly. When a packet arrives, the kernel must match rules one by one. If you have 5,000 Services, each with 10 Pods, the iptables chain can be tens of thousands of rules long. This results in O(N) latency—the more Services, the slower the network. Worse, updating rules requires a full flush of the entire table, causing CPU spikes.
• The nftables Solution: nftables introduces Maps and Sets data structures.
  • Lookups: Regardless of the rule set size, matching is a hash-based O(1) operation.
  • Updates: Supports atomic incremental updates. Adding a new Pod only requires inserting a record into the Map, without re-flushing the entire rule set.

1.2 Architecture: Ending the IPVS “Stopgap”

In recent years, to avoid iptables performance issues, large clusters were forced to switch to IPVS. But IPVS is designed for load balancing and lacks firewall capabilities. Therefore, kube-proxy’s IPVS mode is actually a hybrid: “IPVS for forwarding + iptables for filtering” . This dual-stack architecture is notoriously difficult to debug, and IPVS’s connection tracking (Conntrack) logic can cause occasional packet loss under high concurrency.

nftables unifies everything. It combines the hash lookup performance of IPVS with firewall programming capabilities superior to iptables. It brings the K8s network stack back to a pure, unified, single-layer architecture.

1.3 Security and Dual-Stack: Native Support

• Atomicity: iptables updates lack transactional guarantees, potentially creating traffic black holes during the millisecond window of a rule refresh. nftables’ transactional mechanism ensures rule changes either fully succeed or fully fail, eliminating the risk of “instant network outages.”
• Unified Dual-Stack: With IPv6 becoming mainstream, nftables’ inet table allows a single rule to govern both IPv4 and IPv6 traffic, cutting operational complexity in half.

2. Performance Dominance: Nftables Benchmark Reality (2026)

According to test reports published by the Kubernetes community and the Azure AKS team in late 2025, in a massive cluster with 30,000 Services, nftables demonstrated astonishing performance dominance.

Key Data Interpretation

• P99 Latency: Under the stress of 30,000 Services, nftables’ P99 (slowest 1% of requests) latency was even faster than iptables’ P01 (fastest 1% of requests) ! This means nftables’ “worst-case scenario” outperforms iptables’ “best-case scenario.”
• CPU Offloading: Tests revealed that in large clusters, kube-proxy in iptables mode, even with no traffic, consumes significant CPU (over 35% on a single core) due to frequent full rule syncs. In nftables mode, kube-proxy’s CPU usage is nearly negligible.

3. Public Cloud Support Status and Roadmap in 2026

In 2026, nftables has become the mainstream evolution direction for managed K8s services across major cloud providers, though default policies remain conservative.

3.1 Azure AKS (Azure Kubernetes Service)

• Status: AKS was an early adopter and the most aggressive promoter of nftables. It released a preview of NFTABLES mode in November 2025.
• Roadmap: Fully GA in 2026. AKS is highly likely to make it the default in Azure Linux (Mariner) node pools in the second half of 2026.

3.2 AWS EKS (Amazon Elastic Kubernetes Service)

• Status: EKS’s latest optimized AMIs (Amazon Linux 2023/2025) fully include nftables userspace tools.
• Support: EKS officially supports enabling nftables mode in self-managed node groups via the bootstrap.sh parameter.
• Roadmap: AWS plans to make nftables the recommended default for new clusters in a late 2026 EKS release (corresponding to K8s 1.35+), gradually phasing out IPVS mode support.

3.3 Google GKE (Google Kubernetes Engine)

• Status: GKE’s strategic focus remains Dataplane V2 (eBPF/Cilium) , a higher-performance “game-changer” that completely bypasses kube-proxy.
• Roadmap: For standard clusters not using Dataplane V2, GKE will follow upstream support for nftables but won’t make it a primary selling point. If you’re pursuing peak performance on GKE, eBPF remains the top choice.

3.4 Alibaba Cloud ACK & Tencent Cloud TKE

• Status: Major domestic providers still have a large base of existing IPVS users. Alibaba Cloud Linux 3 already has a solid nftables kernel foundation, with compatibility issues resolved in 2025.
• Roadmap: Adopting a “long-term coexistence” strategy. They won’t force a default switch in the short term but will recommend nftables for high-performance computing node pools.

4. Implementation Advice: Should We Switch?

Advice for Self-Managed K8s Users

If your cluster meets these conditions, switching to nftables is strongly recommended:

1. Modern OS: Kernel version ≥ 5.13 (6.x recommended), using modern distributions like Debian 12+, Ubuntu 22.04+, or RHEL 9+.
2. Medium to Large Scale: Service count exceeds 500, or Pods change frequently.
3. Troubled by iptables: You’ve experienced CPU alerts or network jitter caused by rule refreshes.

Migration Warning: Be sure to check your CNI plugin version (e.g., Calico, Flannel). Major plugins like Calico and Flannel released versions supporting the nftables backend in 2025. If your CNI is still blindly manipulating iptables, it will cause rule conflicts. Upgrade to the latest CNI versions released in 2025/2026.

Advice for Managed Public Cloud Users

1. GKE Users: Continue using Dataplane V2 (eBPF) ; no need to worry about kube-proxy mode.
2. EKS/AKS/ACK Users:
   • New Workloads: Feel free to experiment with nftables mode in test environments. It’s more stable than IPVS and faster than iptables.
   • Existing Workloads: If your current IPVS mode is running smoothly, don’t switch just for the sake of switching. IPVS remains stable and reliable in 2026, and the performance gap is not significant in non-hyper-scale scenarios. A safer strategy is to wait for your cloud provider to officially announce nftables as the default before performing a smooth upgrade.

Conclusion

In 2026, nftables has finally removed the “performance bottleneck” label from the Linux firewall. For Kubernetes, this is not just a performance optimization; it’s a long-overdue technical debt repayment. Whether you’re an aggressive architect or a cautious operations expert, nftables is a future standard you must have in your toolbox.