IPVS to NFTables: A Migration Guide for Kubernetes v1.35

Project Calico has a unique design with a pluggable dataplane that allows users to have the freedom to choose the right networking backend for their environment. In fact Calico supports a wide range of technologies, including eBPF, iptables, IPVS, Windows HNS, and VPP, ensuring the Kubernetes community is always equipped with the latest capabilities.

In 2019, Tigera introduced support for the Linux IPVS mode into the Calico backends as an alternative to iptables. Its primary goal was to handle service creation more efficiently and offer better performance for large-scale clusters. However, the landscape has changed significantly since then and with the introduction of Kubernetes v1.35, IPVS mode is being deprecated from the kube-proxy in favor of the modern Linux standard NFTables.

Why Should You Migrate?

To understand why this shift is happening, we need to look at the evolution of the Linux networking Stack:

• Iptables: While highly reliable, iptables suffered from a Global Lock Bottleneck and O(N) complexity this means in large clusters, a simple rule update required reloading the entire ruleset, causing massive latency and high CPU usage.
• The Duct Tape (IPVS): IPVS was adopted to solve these scaling issues. It offered O(1) matching performance using hashmaps, making it much faster for services. However, it required maintaining a completely separate kernel subsystem, creating significant technical debt and a lot of work to achieve feature parity.
• The Future (NFTables): NFTables is the modern successor to both its predecessors. It combines the performance benefits of IPVS (fast, scalable packet classification) with the flexibility of iptables, all within a unified, modern kernel API. Learn more about this shift here.

Prerequisites

NFtables doesn’t have too many requirements and by now it should be covered by most Linux distributions. Here is a short list of things that you should know before attempting to migrate:

• Linux Kernel: Your Linux kernel should be compiled with nftables support.
• Kubernetes: v1.31 or higher

⚠️It is recommended to perform networking backend change during a maintenance window. ⚠️

Verify The Current Mode

To confirm if your cluster is currently in IPVS mode, check the kube-proxy logs:

kubectl logs -n kube-system daemonset/kube-proxy | grep -i ipvs

Output:

I0103 01:18:49.979100 1 server_linux.go:253] "Using ipvs Proxier"

In Kubernetes v1.35+, you will also see this deprecation log:

"The ipvs proxier is now deprecated and may be removed in a future release. Please use 'nftables' instead."

If your environment is set to IPVS then Calico automatically switches to its IPVS mode and utilizes IPVS based service creation to gain better performance.
You can verify this by using the following command:

kubectl logs -n calico-system daemonset/calico-node | grep -i ipvs

Output:

2026-01-03 03:09:52.996 [INFO][71] felix/driver.go 85: Kube-proxy in ipvs mode, enabling felix kube-proxy ipvs support.

Migrate Kube-Proxy to NFTables

As shown in the previous log emitted by kube-proxy, the upstream Kubernetes recommendation is to switch from IPVS to nftables.

Update the ConfigMap

You need to update the mode parameter in the kube-proxy ConfigMap.

kubectl edit configmap -n kube-system kube-proxy

Locate the mode configuration (usually found within the config.conf data block) and change it from ipvs to nftables:

mode: nftables

Restart Kube-Proxy

Changes to the ConfigMap do not apply automatically. You must restart the DaemonSet to pick up the changes.

kubectl rollout restart -n kube-system daemonset/kube-proxy

Verify Kube-Proxy Migration

Once the pods restart, check the logs to confirm the new mode is active:

kubectl logs -n kube-system daemonset/kube-proxy | grep -i nftables

Switch Calico to NFTables

After updating kube-proxy, you must instruct the Calico dataplane to switch to NFTables mode. This is done by patching the Tigera Operator's installation resource.

Step 1: Patch the Installation

Run the following command to update the Linux dataplane mode:

kubectl patch installation default --type=merge -p '{"spec":{"calicoNetwork":{"linuxDataplane":"Nftables"}}}'

Step 2: Verify Calico Migration

The Tigera operator will initiate a rolling restart of all calico-node pods. Once complete, verify the change in the logs:

kubectl logs -f -n calico-system daemonset/calico-node | grep -i nftables

Output:

2026-01-03 01:25:07.803 [INFO][837] felix/config_params.go 805: Parsed value for NFTablesMode: Enabled (from datastore (global))

Switch to Calico eBPF (High Performance)

If you are already performing a migration, consider skipping NFTables entirely and moving to the Calico eBPF dataplane.
The eBPF dataplane bypasses kube-proxy entirely, offering:
Lower latency than both IPVS and NFTables.

• Source IP preservation.
• Direct Server Return (DSR) capabilities.

Note: Make sure to change your kube-proxy mode to iptables before switching to eBPF.

Learn more about the Calico eBPF dataplane here.

Conclusion

By migrating away from IPVS, you eliminate the technical debt associated with a deprecated backend. Whether you choose the standard NFTables route or upgrade to the high-performance Calico eBPF dataplane, the result is a more stable, secure, and future-proof cluster ready for the next generation of Kubernetes networking.