Dora NodaIf your clusters run kube-proxy in IPVS mode, Kubernetes just started a clock you cannot snooze. Version 1.37 introduces the KubeProxyIPVS feature gate, the second stage of a five-step removal plan that ends with the IPVS codebase deleted entirely in v1.43. IPVS still works today. It just has an expiration date now, and the replacement — nftables mode, GA since v1.33 — is faster by every published measurement.
Here is the part that matters most: nothing breaks today, everything breaks eventually, and the fix is a one-line config change you should validate long before v1.40 makes it urgent. This post gives you the full staged timeline, what each gate actually does to a running fleet, and a concrete migration recipe for self-hosted clusters where no managed vendor will paper over the change for you.
The timeline: five stages, three releases that matter
The removal follows KEP-5495, and the Kubernetes documentation states the plan plainly: IPVS support "will be disabled by default from Kubernetes v1.40 (you can re-enable it with the KubeProxyIPVS feature gate)" and "will be fully removed in Kubernetes v1.43." Here is each stage with the one action it demands:
| Stage | Release | What happens | Your action |
|---|---|---|---|
| 1 | v1.35 | IPVS formally deprecated; docs updated, deprecation warnings appear | Inventory which clusters run mode: ipvs |
| 2 | v1.37 (Garhwal, GA August 2026) | KubeProxyIPVS feature gate introduced; IPVS still works but logs a deprecation warning on kube-proxy startup | Plan the migration; test nftables mode on a non-production cluster |
| 3 | v1.40 | IPVS disabled by default; only runs if you explicitly enable the gate | Be off IPVS already, or pin the gate as a documented stopgap |
| 4 | v1.43 | IPVS codebase fully removed; the gate and the mode no longer exist | No escape hatch left — migration must be done |
| 5 | v1.46 | Feature gate itself cleaned up | Nothing to do; the tombstone is removed |
Two clarifications keep teams from misreading this table. First, v1.37 changes nothing about runtime behavior — a cluster on IPVS mode upgrades to v1.37 and keeps routing packets exactly as before, just louder in the logs. Second, only IPVS is deprecated. The classic iptables mode remains fully supported, so clusters on older kernels that cannot run nftables still have a supported fallback.
The generous runway is the point. Three minor releases between "gate exists" and "code deleted" is Kubernetes giving large fleets time to migrate deliberately instead of during an incident.
Why IPVS is dying: the honest engineering reason
IPVS mode was introduced back in Kubernetes 1.11 to solve a real problem: iptables scales as O(n), so every service update on a large cluster rewrote a linear rule chain and latency climbed with service count. IPVS, the Linux kernel's Layer-4 load balancer, offered O(1) hash-table lookups and real scheduling algorithms. Datadog engineers even became upstream IPVS contributors to make it production-worthy. For years, "thousands of services" was the standard reason to choose IPVS.
The problem, as the deprecation rationale puts it, is that the kernel IPVS API alone cannot implement Kubernetes Services. IPVS mode always leaned on iptables and ipset under the hood — NodePort and LoadBalancer NAT handling, parts of the traffic path, still went through iptables rules. Operators who picked IPVS thinking they had left iptables behind were running both stacks, with the operational surface of both and the failure modes of their interaction.
That half-dependency is also why IPVS never fully covered the Services API edge cases, and why the project ended up maintaining three backends (iptables, IPVS, nftables) for one job. Three backends means every new service feature gets implemented and tested three times. The project chose to consolidate on nftables, the modern Linux packet-filtering framework that supersedes both iptables and IPVS, and cut the backend that was neither the default nor the future.
What breaks (or doesn't) at each gate
Walk through the stages from the perspective of a cluster still on mode: ipvs:
v1.35 — warnings only. Deprecation notices in documentation and logs. kubeadm gained an explicit warning when your KubeProxyConfiguration sets mode: ipvs, recommending nftables (GA since v1.33) or legacy iptables on older kernels. Nothing changes at runtime.
v1.37 — the gate appears, behavior unchanged. The KubeProxyIPVS feature gate is introduced and kube-proxy in IPVS mode logs a deprecation warning at startup. If you grep your fleet's kube-proxy ConfigMaps for mode:, every hit is now a dated entry on a removal schedule. This is the release to do the migration with zero time pressure.
v1.40 — default-off. A cluster upgrading to v1.40 with mode: ipvs and no gate override loses its service proxy backend. The documented escape hatch is enabling the KubeProxyIPVS gate explicitly — but treat that as a bridge for one straggler cluster, not a strategy. Every release you spend on the gate is a release closer to v1.43 with the same migration still ahead of you.
v1.43 — removal. The IPVS proxier code leaves the tree. Setting mode: ipvs stops being a deprecated option and becomes an invalid one. There is no gate to flip because there is nothing left behind it.
v1.46 — cleanup. The now-meaningless feature gate is removed. Invisible to anyone who migrated on time.
The failure mode to internalize: this is not a graceful degradation. A kube-proxy that cannot load its configured backend does not route service traffic. Missing the v1.40 gate is an outage-shaped event for affected clusters, which is exactly why the timeline deserves a calendar entry now rather than a post-mortem later.
The migration recipe: detect, switch, validate
For most clusters the migration is small. Here is the full sequence.
1. Detect. Find every cluster still on IPVS:
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'Any output reading mode: ipvs is a migration candidate. Run this across every cluster in the fleet, not just production — staging clusters pinned to IPVS will bite you at upgrade time just the same.
2. Check prerequisites. nftables mode needs a kernel version of 5.13 or newer on every node. Most distributions shipping in the last few years qualify, but verify older bare-metal images explicitly — a node image frozen in 2021 is exactly the kind of thing that turns a one-line change into a reimage project. Also confirm your CNI plugin and NetworkPolicy implementation support nftables mode; the KEP notes that some plugins needed updates, so check your CNI's compatibility matrix rather than assuming.
3. Switch. Update the kube-proxy ConfigMap to mode: nftables and restart the DaemonSet:
kubectl -n kube-system edit configmap kube-proxy # set mode: nftables
kubectl -n kube-system rollout restart daemonset/kube-proxyIf any node pool runs a kernel too old for nftables, mode: iptables is the supported fallback — still maintained, just not the future default. The only wrong answer is staying on IPVS.
4. Validate. After the rollout, confirm service traffic end to end: ClusterIP resolution from a test pod, NodePort reachability from outside, and LoadBalancer health checks if applicable. Watch kube-proxy logs for errors during the first full resync, and compare service-update latency before and after — most teams see it drop, which brings us to why.
Why nftables: the numbers behind "the eventual default"
nftables replaces linear rule chains with set and map lookups — roughly O(1) instead of O(n). The same 10,000-service cluster that generates hundreds of thousands of iptables rules collapses to a handful of nftables sets, and rule updates become incremental instead of full-ruleset rewrites.
Published measurements make the gap concrete:
- In Azure's AKS testing, nftables' average (p50) first-packet latency at 5,000 and 10,000 services roughly equaled iptables' best-case (p01) latency. At 30,000 services, nftables' worst-case (p99) latency beat iptables' best case.
- kube-proxy's idle memory footprint dropped from 157.5 MiB to 46.8 MiB (about 70 percent) when switching backends, with CPU during churn falling from 179 to 133 millicores.
- Newer kernels keep widening the gap: kernel 6.12.55 cut nftables rule-synchronization time by 77 percent at 250,000 endpoints in one benchmark.
This is the answer to "why not just stay on iptables forever." You can — it remains supported. But nftables is what the performance work targets now, and every large-cluster optimization lands there first. Migrating off IPVS straight to nftables skips an intermediate hop you would only have to repeat later.
What this means for a Cluster API fleet specifically
Managed Kubernetes customers will experience this deprecation as a support email and a default that changes under them. Self-hosted fleets get no such concierge. If you run Cluster API on your own machines, every step of this migration is yours:
- Audit all clusters, not one. A fleet of ten clusters provisioned from slightly different templates can easily hide three IPVS stragglers. The ConfigMap grep above belongs in a script that runs against every management and workload cluster.
- Fix the templates, not just the clusters. Flipping a live ConfigMap migrates today's cluster; updating the
KubeProxyConfigurationin your cluster templates and node-image build ensures the next provisioned cluster is born on nftables. Otherwise you are fixing the same drift every time you scale. - Schedule against the freeze calendar, not the GA date. Kubernetes 1.37's cycle — feature freeze early July, code freeze July 22, GA August 26 — gave operators a five-week window to audit against a known-frozen breaking-change list before upgrading. Use that window for v1.40 the same way: audit during freeze, migrate before GA, upgrade without surprises.
- Budget kernel upgrades into the plan. The nftables kernel floor (5.13+) is the likeliest source of scope creep. Check node-image kernel versions before promising a one-line migration, especially on long-lived bare-metal pools.
None of this is hard. It is exactly the kind of recurring per-release maintenance that owning your control plane signs you up for — the same category as kubelet flag removals and API graduations. The operators who feel no pain from IPVS removal will be the ones who treated v1.37's warning as a work order instead of background noise.
Start now, finish by v1.40
The staged timeline is a gift: v1.37 warns, v1.40 enforces, v1.43 deletes. Migrate IPVS clusters to nftables mode during the warning stage and the whole episode costs you an afternoon of ConfigMap edits and smoke tests. Wait until the enforcement stage and it costs you a gate-pinning scramble on upgrade day. Wait until removal and it costs you an outage.
Run the ConfigMap grep across your fleet this week. If it comes back empty, you just bought certainty for free. If it doesn't, you now know exactly what to do, in what order, and how long you have.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
