Try to clarify the status of ipvs kube-proxy

[danwinship]

OK, so the status of the kube-proxy ipvs backend is:

• It's faster than iptables in large clusters.
• It works on older Linux distros, unlike nftables
• It doesn't implement some corner cases of Service functionality correctly, and this is not likely to ever be fixed, because most remaining fixes would require heavy rearchitecting of the code, and all of the people in SIG Network who used to care about fixing ipvs bugs have drifted away, and the SIG leads would rather push people toward nftables than try to figure out how to fix ipvs.

So this tries to explain that some. I'm not particularly attached to any of the specific text here; consider this a starting point.

Fixes #51917

/assign @lmktfy @aojea
/sig network

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign salaxander for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• content/en/docs/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[netlify]

✅ Pull request preview available for checking

Built without sensitive environment variables

Name	Link
🔨 Latest commit	6141526
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-io-main-staging/deploys/68a5daea93d57e0008fb0df6
😎 Deploy Preview	https://deploy-preview-51974--kubernetes-io-main-staging.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[lmktfy]

nit (can wait for a follow-up PR)

I'd put this note just after This proxy mode is only available on Linux nodes.

[lmktfy]

Suggested change

	functionality correctly. At some point in the future, it is expected
	to be formally deprecated as a feature.
	functionality correctly.

We could make an exception to policy, but normally we avoid statements about the future. I'm on the fence but overall I prefer not to recommend making an exception here.

If we want to guide people to nftables, a blog article about adopting it would be better (and, to be clear @danwinship - you're absolutely welcome to write one, but it's equally valid to nudge other folk towards that work). Blog articles get noticed in a way that notices buried like this one don't, and they are allowed to talk about ambitions, plans, expectations, etc.

[aojea]

There is already one https://kubernetes.io/blog/2025/02/28/nftables-kube-proxy/

[danwinship]

Oops, I had added a comment here and then forgot to publish it... Anyway, yes, if we don't want to talk about the future, then we should probably just wait until the deprecation actually officially happens, which will presumably be in 1.35. I was just pushing this now because there was some pressure toward making it clearer in the docs that ipvs is no longer fully supported. (I don't think it makes sense to say "it's not fully supported but there's no particular reason for this, nope, nothing to see here".)

[lmktfy]

Let's explain the shortcoming now and hyperlink to the blog article from earlier this year.

Blog articles carry a date and people shouldn't be surprised if they become stale; docs should be - at least for this project - timeless.

[lmktfy]

One problem with "At some point in the future, it is expected to be formally deprecated as a feature." is that at the moment we deprecate IPVS mode, the docs are relevant to people — and also wrong (they will imply the deprecation hasn't happened).

We really should avoid it.

[aojea]

/lgtm

leave to Tim and Dan to flesh out the open comment, but it looks really well explained

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: fed90206b6b602d1abba4db5b3540953f4511ff5