KEP-4963: Kube-proxy Services Acceleration

[aroradaman]

Picking up from #4964

• One-line PR description: Service acceleration for Kube-proxy using netfilter’s flowtable infrastructure

• Issue link: Kube-proxy Services Acceleration #4963

• Other comments:

[aroradaman]

/assign @danwinship @aojea
/cc @adrianmoisey

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: aroradaman
Once this PR has been reviewed and has the lgtm label, please ask for approval from aojea and additionally assign wojtek-t 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:

• keps/prod-readiness/OWNERS
• keps/sig-network/OWNERS

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

[danwinship]

So I still have the same concern I had before: there is no reason given for limiting this to only Service traffic. Of course, the reason the earlier KEP proposed it that way is because kube-proxy was the only place where SIG Network could insert this code (even though it barely interacted with the rest of kube-proxy). But, as Calico already demonstrated, a network plugin could implement the same functionality for both Service and non-Service traffic, without needing anything from kube-proxy. (In fact, it would want to disable kube-proxy's own offloading.)

Given that we are now planning to make kindnet a SIG Network project, I think the right answer is to implement offload there. But apparently we already do implement it there, so mission accomplished?

(The other possibility is to add a "usage hint" field to Service, which kube-proxy could then take advantage of to know that certain kinds of optimizations, like offload, were useful, kubernetes/kubernetes#127259 (comment). Then it would make sense to implement offload in kube-proxy, for Services that were hinted in a way that indicated they'd benefit from it.)

[adrianmoisey]

(The other possibility is to add a "usage hint" field to Service, which kube-proxy could then take advantage of to know that certain kinds of optimizations, like offload, were useful, kubernetes/kubernetes#127259 (comment). Then it would make sense to implement offload in kube-proxy, for Services that were hinted in a way that indicated they'd benefit from it.)

I like this idea.
My concern with the current proposal, is that if I want to change how this feature works, it requires me configuring kube-proxy, something we normally don't do often.
Accessing this feature via the Services API would be nicer, and give more control.

[adrianmoisey]

I very much like the opt-in nature of this. If users ignore the feature, nothing changes.

[adrianmoisey]

Is there any need to leave space in the API to allow for configuration?
I don't know what the future holds with other expansions here, but what if other modes require settings?
For example: with LongLived, may be we need to configure how long before it takes the fast path?
Or with a reduced conntrack timeout, it may need a configuration as to how long

My question here may come with a lot of inexperience, so it may not be valid.

[aroradaman]

I thought about that while writing this, but realised it will make the Service API too complicated.

I think we can use gateway-api later to have different types of services maybe separate kinds for LondLivedService, or ShortLivedService and specs for each kind can have configurable attributes.

[aroradaman]

I will defer to @danwinship @aojea @thockin for this.