-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP do not merge] Kube-Proxy Library: Breakout a KPNG-like interface "kube proxy lib" from #2104 #3649
Conversation
Adding details about how proxies work w/ and w/o the fullstate initial wave of fixes from dan's review updaedd diffstore explanation and typo fix, moved it updates to userstories and fixes to DiffState bundling logic removed exsiting Run() logic, Fix some spelling and typos Add section on the different types of client sinks. Signed-off-by: astoycos <astoycos@redhat.com> Add note about separate node kpng-brain and its fragility as a real feature Update README.md Refactoring Kube-Proxy, mega-commit Co-authored-by: mcluseau <mikael.cluseau@gmail.com> Co-authored-by: jayunit100 <jvyas@vmware.com> Co-authored-by: kbabben <knabben@vmware.com> Co-authored-by: rajas kakodkar <rkakodkar@vmware.com>
…paration of the APIServer uplink
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: jayunit100 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/cc |
should be approved by the remaining approvers and/or the owning SIG (or | ||
SIG Architecture for cross-cutting KEPs). | ||
--> | ||
# KEP-2104: kube-proxy library (KEP-2104, breakout) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we'll probably want a new KEP number for this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixing....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we'd need a new issue for this right @jayunit100 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ya, i guess for the last thing we do we can clean that ... lets get consensus on the impl first tho i think b4 we gift wrap that part?
|
||
#### Story 2 | ||
|
||
As a Kubernetes maintainer, I don't want to have to understand the internals of a networking backend in order to simulate or write core updates to the logic of the kube-proxy locally. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a fairly small use case. In fact, it's pretty much limited to topology-related features, where all you care about is restricting the endpoints that get used on a given node. For just about anything else, any change to the core is going to need to be matched with new code in the backends as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, updated as a svc proxy maint , pushing shortly
- Exemplify the use of such a repository in a mock "backend" which uses the repository to process and respond to changes in the Kubernetes networking state. | ||
- Define a policy around versioning and releasing of "kube-proxy-lib". | ||
- Create a CI system that runs in test-grid which tests kube-proxy-lib compatibility with the latest Kubernetes releases continuously, and which can be used to inform API changes for regressions that break "kube-proxy-lib". | ||
- Enable the eventual *replacement* of the k/k/pkg/proxy serviceChangeTracker and endpointsChangeTracker related caching structures inside of in-tree kube proxy with this generic library. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe point out that the existing code has hard-to-fix bugs. Eg, kubernetes/kubernetes#112604
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
- sending the full-state could be resource consuming on big clusters, but it should still be O(1) to | ||
the actual kernel definitions (the complexity of what the node has to handle cannot be reduced | ||
without losing functionality or correctness). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is completely unclear what this means, in the context of this KEP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
deleting
|
||
No risks, because we arent removing the in tree proxy as part of this repo, but rather, proposing a library for kube proxy extenders | ||
to use optionally. There may be risks, eventually, if we write another KEP to *replatform* sig-networks k/k/pkg/proxy implementations | ||
on top of this library, but that would be in a separate KEP. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it makes sense for that to be a separate KEP. IMO this project is only interesting for SIG Network if it is going to replace our existing shared proxy code. (Yes, the code would be useful for third parties even if SIG Network wasn't using it in the k8s core, but it wouldn't make sense for SIG Network to own the code in that case; it should just be a third-party project.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point but, in the interest of "building something that is uncontraversial as a first step", How strongly do you feel about this ? If i made this argument:
- "sig network needs b"
- "b needs a"
- thus were going to make "sig-network/a" as a stepping stone to us being able to build "sig-network/b"
- by the way "sig-network/b" is somethin lots of people want, so even if we get hit by a bus after making "b", and we never get around to "a", we still have a useful intermediate deliverable....
Is that digestible ? or does it sit funny w/ you ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I'm saying is that I don't think the library can be definitely "uncontroversial" and "a useful intermediate deliverable" unless we know that it is suited to replacing pkg/proxy
.
I'm not saying we have to deliver the library and the updated iptables proxy in the same release, I'm saying that rather than doing:
- come up with a plan for the library
- implement the library
- come up with a plan to replace
pkg/proxy
with the new library - replace
pkg/proxy
with the new library
we need to do
- come up with a plan for the library
- come up with a plan to replace
pkg/proxy
with the new library - implement the library
- replace
pkg/proxy
with the new library
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gotcha, ok updated as a risk (and updated the goals to reflect)
|
||
###### Will enabling / using this feature result in introducing new API types? | ||
|
||
Yes. There will be an in-memory API that is supported by this library, that is incremented overr time |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No. The question is about kubernetes API types, not about golang APIs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, added "No" + clarified
/assign |
Co-authored-by: Dan Winship <danwinship@redhat.com>
Co-authored-by: Dan Winship <danwinship@redhat.com>
Co-authored-by: Dan Winship <danwinship@redhat.com>
Co-authored-by: Dan Winship <danwinship@redhat.com>
/cc |
@astoycos I'd say get folks to agree on the content then fix the details like issue and kep number after... your call tho |
+1 @jayunit100 I'm running through Dan's comments that are still open and fixing some small stuff I should have a commit up by tonight then I'll keep pushing others on if the context makes sense |
feel free to YOLO push @astoycos thanks ! |
This update provides some fixes and review comment resolutions from Dan. It also clarifies where and what the proposed library would look like and the role it would initially serve for existing proxies. Also fix verification tests :) Signed-off-by: Andrew Stoycos <astoycos@redhat.com>
/assign |
Pushed some updates based on @danwinship comments and the discussion from the kpng meeting this morning |
63c5315
to
fda9787
Compare
/close Closed in favor of #3788 |
@astoycos: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Break out KEP from #2104