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
Creating new EndpointSliceProxying feature gate for kube-proxy, enabling EndpointSlice feature gate by default #86137
Creating new EndpointSliceProxying feature gate for kube-proxy, enabling EndpointSlice feature gate by default #86137
Conversation
/test pull-kubernetes-e2e-kind-ipv6 |
I haven't had a chance to review this specifically, but that matches my expectations |
bbee8b0
to
b8354a2
Compare
/retest |
2 similar comments
/retest |
/retest |
@@ -1051,6 +1051,13 @@ items: | |||
- create | |||
- patch | |||
- update | |||
- apiGroups: |
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.
Why are these changes in the same commit?
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.
Good call, I've split them into two separate commits now, thanks!
This creates a new EndpointSliceProxying feature gate to cover EndpointSlice consumption (kube-proxy) and allow the existing EndpointSlice feature gate to focus on EndpointSlice production only. Along with that addition, this enables the EndpointSlice feature gate by default, now only affecting the controller. The rationale here is that it's really difficult to guarantee all EndpointSlices are created in a cluster upgrade process before kube-proxy attempts to consume them. Although masters are generally upgraded before nodes, and in most cases, the controller would have enough time to create EndpointSlices before a new node with kube-proxy spun up, there are plenty of edge cases where that might not be the case. The primary limitation on EndpointSlice creation is the API rate limit of 20QPS. In clusters with a lot of endpoints and/or with a lot of other API requests, it could be difficult to create all the EndpointSlices before a new node with kube-proxy targeting EndpointSlices spun up. Separating this into 2 feature gates allows for a more gradual rollout with the EndpointSlice controller being enabled by default in 1.18, and EndpointSlices for kube-proxy being enabled by default in the next release.
This enables the EndpointSlice controller by default, but does not make kube-proxy a consumer of the EndpointSlice API.
b8354a2
to
469de65
Compare
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.
Thanks!
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: robscott, thockin The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest Review the full test history for this PR. Silence the bot with an |
What type of PR is this?
/kind feature
What this PR does / why we need it:
This creates a new
EndpointSliceProxying
feature gate to cover EndpointSlice consumption (kube-proxy) and allow the existing EndpointSlice feature gate to focus on EndpointSlice production only. Along with that addition, this enables the EndpointSlice feature gate by default, now only affecting the controller.The rationale here is that it's really difficult to guarantee all EndpointSlices are created in a cluster upgrade process before kube-proxy attempts to consume them. Although masters are generally upgraded before nodes, and in most cases, the controller would have enough time to create EndpointSlices before a new node with kube-proxy spun up, there are plenty of edge cases where that might not be the case. The primary limitation on EndpointSlice creation is the API rate limit of 20QPS. In clusters with a lot of endpoints and/or with a lot of other API requests, it could be difficult to create all the EndpointSlices before a new node with kube-proxy targeting EndpointSlices spun up.
Separating this into 2 feature gates allows for a more gradual rollout with the EndpointSlice controller being enabled by default in 1.18, and EndpointSlices for kube-proxy being enabled by default in the next release.
Special notes for your reviewer:
I'm not sure if the new
EndpointSliceProxying
feature gate should be alpha or beta at this point. It will not be enabled by default, but it is being split out of a feature gate that is already beta.Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
/sig network
/priority important-longterm
/cc @freehan @liggitt @thockin