add EndpointSlice consumer helper functions

[danwinship]

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 a Get on that service, you get all of the endpoints across all three slices, and if 1 of the slices gets updated, you get an Updated event 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 Get would return a []*discoveryv1.EndpointSlice rather 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 fake EndpointSlice objects 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 different Ports, 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 EndpointSliceCache may 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/endpointslice would be an obvious place? (It's currently only EndpointSlice controller code, but it could have EndpointSlice consumers too?) If not there, then maybe k8s.io/component-helpers.

/sig network
/priority important-longterm
/triage accepted
/cc @robscott

[robscott]

@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-a

With 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.

[nishchay-veer]

Hey @danwinship I'm interested in working on EndpointSlice helpers would like to work on this