add EndpointSlice consumer helper functions #124777
Comments
k8s-ci-robot
added
sig/network
|
@danwinship Agree with your ideas here, I think we essentially would just want a library that would dedupe EndpointSlices as far as possible. In most cases that's going to result in a single slice (that's largely already the case since most Services have <100 endpoints). Unfortunately as you mentioned, named ports exist, so even if we have <100 endpoints, it's possible that every endpoint/Pod is listening on a different port, and the only way to represent that is with a separate EndpointSlice for each unique Service Port -> Endpoint Port combination. Since we'd be less concerned about the most efficient form across the wire, this library could just have a single list of endpoints for each service port and embed the endpoint port alongside the endpoint information. That might look something like this: endpointsByPort:
- port:
name: http
protocol: TCP
endpoints:
- addresses:
- "10.1.2.3"
port: 80
conditions:
ready: true
hostname: pod-1
nodeName: node-1
zone: us-west2-aWith that relatively minimal change, we could fit all endpoints in a single list with this library. Unfortunately it would not allow implementations to reuse the EndpointSlice API types directly though. |
|
Hey @danwinship I'm interested in working on EndpointSlice helpers would like to work on this |
This commit adds helper functions for EndpointSlice consumers to make it easier to transition from Endpoints to EndpointSlices. The new package provides: 1. EndpointSliceConsumer - Core component that tracks EndpointSlices and provides a unified view of endpoints for a service 2. EndpointSliceInformer - Informer-like interface for EndpointSlices 3. EndpointSliceLister - Lister-like interface for EndpointSlices These helpers handle the complexity of merging multiple slices for the same service and deduplicating endpoints that might appear in multiple slices. Benefits: - Easier migration from Endpoints to EndpointSlices with familiar interfaces - Simplified handling of multiple slices without manual merging and deduplication - Improved performance by leveraging the scalability of the EndpointSlice API - Consistent view of endpoints even as they move between slices Fixes kubernetes#124777 Signed-off-by: Mad Bergo <[email protected]>
As discussed in the SIG Network meeting on May 9, we should provide "EndpointSlice helpers" to help people get away from Endpoints (without using EndpointSlices in a naive way that breaks for large services).
In particular, we want something that acts sort of like an
Informer/Lister, but where it deals with merging together multiple slices for the same service, so that, eg, if a service has 3 slices, and you do aGeton that service, you get all of the endpoints across all three slices, and if 1 of the slices gets updated, you get anUpdatedevent that includes the new combined set of endpoints, not just the endpoints for that one slice.(I'm not totally sure exactly what this API should look like. One possibility would be that
Getwould return a[]*discoveryv1.EndpointSlicerather than a single*discoveryv1.EndpointSlice. Though this would mean that when endpoints were being moved between slices, there would be temporary states where a single endpoint appeared in two different slices. Another possibility would be to have it synthesize fakeEndpointSliceobjects that just ignored the normal maximums and included all of the endpoints from across all of the slices (with the cache code dealing with de-duping). Though, actually, that doesn't work, because the different slices might have differentPorts, so you'd still need to return an array of slices. So maybe we do want the first idea, just with a prominent warning that duplicates may exist.)kube-proxy's
EndpointSliceCachemay provide a starting point, though it's too tied to other internal kube-proxy APIs to actually be useful as-is.The code should go in some staged repo. I guess maybe
k8s.io/endpointslicewould be an obvious place? (It's currently only EndpointSlice controller code, but it could have EndpointSlice consumers too?) If not there, then maybek8s.io/component-helpers./sig network
/priority important-longterm
/triage accepted
/cc @robscott
The text was updated successfully, but these errors were encountered: