Request for new repository - kubernetes-sigs/endpointslice

[Lionel Jouin]

Hi everyone,

Discussed with some members of the Gateway API community, Cilium/Multi-Cluster Service (MCS), Multi-Network and sig-network during its weekly meeting on 16th January (2025), the idea is to propose a new repository (fork of https://github.com/kubernetes/endpointslice) for a generic EndpointSlice Reconciler under kubernetes-sigs (https://github.com/kubernetes-sigs/endpointslice).

This idea originated from KEP-4770, though it was later removed (still remains accessible in old commits). It aligns with the objectives of KEP-3685.

My goal is to have a reconciler library that could be sufficiently generic to be used by:

1. The Kubernetes EndpointSlice controller

2. The Kubernetes EndpointSlice Mirroring controller

3. A Gateway API EndpointSelector (See GEP-3539) EndpointSlice Controller

4. A Multi-Cluster Service (MCS, See KEP-1645) EndpointSlice Controller

5. An EndpointSlice Controller Selecting IPs in the annotations (e.g. Multus)

6. An EndpointSlice Controller Selecting IPs in the ResourceClaims of a Pod (e.g. IPs stored in the Device Status of the ResourceClaim, See KEP-4817)

To clarify, this is not an attempt to replace/modify the existing Kubernetes EndpointSlice or EndpointSlice Mirroring controllers. Instead, the goal is to provide a flexible reconciler library that these controllers (and others) could leverage.

My primary use case for this work is to support cases 5. and 6..

The work to make the EndpointSlice generic is partially done and accessible here: https://github.com/LionelJouin/EndpointSlice-Controller

I would love to hear your thoughts and any feedback you might have. If there is enough interest and support, I will open an issue on https://github.com/kubernetes/org requesting this repository.

Thank you,

Lionel

[Antonio Ojea]

Thank you for bringing this up. I think we should take a slightly different approach here. Before we create a shared library, how about we first get some working examples of these EndpointSlice controllers in action within the projects you mentioned, like Multi-Network, MCS, Multus or Gateway API?

It feels like we're opening a few repositories in this space, and honestly, a lot of them are pretty quiet. It would be super helpful to see some prototypes or even basic implementations running in a standard cluster. That way, we can get real-world feedback and see what challenges we actually need to solve.

Let's focus on getting those projects working first, and then we can better evaluate the need for a shared library. What do you think?

https://github.com/kubernetes-sigs/multi-network

https://github.com/kubernetes-sigs/multi-network-api

https://github.com/kubernetes-sigs/cni-dra-driver

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-network" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-ne...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/kubernetes-sig-network/AM7P189MB09320245C26025A86D5FED50F8D02%40AM7P189MB0932.EURP189.PROD.OUTLOOK.COM.

[Lionel Jouin]

Thank you for your feedback, this is a fair point, it sounds good to me.

---

From: Antonio Ojea <ao...@google.com>
Sent: Wednesday, March 12, 2025 11:35 AM
To: Lionel Jouin <lionel...@est.tech>
Cc: kubernetes-...@googlegroups.com <kubernetes-...@googlegroups.com>; kubernetes-si...@googlegroups.com <kubernetes-si...@googlegroups.com>
Subject: Re: [k8s-sig-net] Request for new repository - kubernetes-sigs/endpointslice

 

[Dan Winship]

On 3/12/25 06:35, 'Antonio Ojea' via kubernetes-sig-network wrote:
> Thank you for bringing this up. I think we should take a
> slightly different approach here. Before we create a shared library, how
> about we first get some working examples of these EndpointSlice
> controllers in action within the projects you mentioned, like
> Multi-Network, MCS, Multus or Gateway API?
>
> It feels like we're opening a few repositories in this space, and
> honestly, a lot of them are pretty quiet. It would be super helpful to
> see some prototypes or even basic implementations running in a standard
> cluster. That way, we can get real-world feedback and see what
> challenges we actually need to solve.

Yeah, I don't think a separate endpointslice library repo makes sense;
if we don't need the library then it shouldn't exist anywhere, and if we
do need it, it should be in "k8s.io/endpointslice". (I know people were
arguing against putting this in "k8s.io/endpointslice" before, but
that's because they didn't think we needed it.)

-- Dan

> Let's focus on getting those projects working first, and then we can
> better evaluate the need for a shared library. What do you think?
>
> https://github.com/kubernetes-sigs/multi-network
> <https://github.com/kubernetes-sigs/multi-network>

> https://github.com/kubernetes-sigs/multi-network-api
> <https://github.com/kubernetes-sigs/multi-network-api>
> https://github.com/kubernetes-sigs/cni-dra-driver

> <https://github.com/kubernetes-sigs/cni-dra-driver>
>
>
>
> On Wed, Mar 12, 2025 at 11:06 AM Lionel Jouin <lionel...@est.tech> wrote:
>
> Hi everyone,
>
> Discussed with some members of the Gateway API community,
> Cilium/Multi-Cluster Service (MCS), Multi-Network and sig-network
> during its weekly meeting on 16th January (2025), the idea is to
> propose a new repository (fork of
> https://github.com/kubernetes/endpointslice

> <https://github.com/kubernetes/endpointslice>) for a generic

> EndpointSlice Reconciler under kubernetes-sigs
> (https://github.com/kubernetes-sigs/endpointslice

> <https://github.com/kubernetes-sigs/endpointslice>).
>
> This idea originated from KEP-4770
> <https://github.com/kubernetes/enhancements/issues/4770>, though it

> was later removed (still remains accessible in old commits

> <https://github.com/kubernetes/enhancements/blob/77ffcef2914d903b3b443feeaf502888d6f706c5/keps/sig-network/4770-endpointslice-controller-flexibility/README.md#flexibility-on-the-endpointslice-reconciler-module-1>). It aligns with the objectives of KEP-3685 <https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/3685-endpointslice-reconciler-to-staging>.

>
> My goal is to have a reconciler library that could be sufficiently
> generic to be used by:
> 1. The Kubernetes EndpointSlice controller
> 2. The Kubernetes EndpointSlice Mirroring controller
> 3. A Gateway API EndpointSelector (See GEP-3539

> <https://github.com/kubernetes-sigs/gateway-api/pull/3608>)

> EndpointSlice Controller
> 4. A Multi-Cluster Service (MCS, See KEP-1645

> <https://github.com/kubernetes/enhancements/blob/master/keps/sig-multicluster/1645-multi-cluster-services-api/README.md#using-endpointslice-objects-to-track-endpoints>) EndpointSlice Controller

> 5. An EndpointSlice Controller Selecting IPs in the annotations

> (e.g. Multus <https://github.com/k8snetworkplumbingwg/multus-cni>)

> 6. An EndpointSlice Controller Selecting IPs in the ResourceClaims
> of a Pod (e.g. IPs stored in the Device Status of the ResourceClaim,
> See KEP-4817

> <https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/4817-resource-claim-device-status>)

>
> To clarify, this is not an attempt to replace/modify the existing
> Kubernetes EndpointSlice or EndpointSlice Mirroring controllers.
> Instead, the goal is to provide a flexible reconciler library that
> these controllers (and others) could leverage.
>
> My primary use case for this work is to support cases 5. and 6..
>
> The work to make the EndpointSlice generic is partially done and
> accessible here:
> https://github.com/LionelJouin/EndpointSlice-Controller
> <https://github.com/LionelJouin/EndpointSlice-Controller>
>
> I would love to hear your thoughts and any feedback you might have.
> If there is enough interest and support, I will open an issue on
> https://github.com/kubernetes/org
> <https://github.com/kubernetes/org> requesting this repository.
>
> Thank you,
> Lionel
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "kubernetes-sig-network" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to kubernetes-sig-ne...@googlegroups.com

> <mailto:kubernetes-sig-ne...@googlegroups.com>.

> To view this discussion visit

> https://groups.google.com/d/msgid/kubernetes-sig-network/AM7P189MB09320245C26025A86D5FED50F8D02%40AM7P189MB0932.EURP189.PROD.OUTLOOK.COM <https://groups.google.com/d/msgid/kubernetes-sig-network/AM7P189MB09320245C26025A86D5FED50F8D02%40AM7P189MB0932.EURP189.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "kubernetes-sig-network" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to kubernetes-sig-ne...@googlegroups.com

> <mailto:kubernetes-sig-ne...@googlegroups.com>.

> To view this discussion visit

> https://groups.google.com/d/msgid/kubernetes-sig-network/CAAdXToTbrHAHswjPnOOH9LMVv2u84knYLxzkbRVvfX174_q3HQ%40mail.gmail.com <https://groups.google.com/d/msgid/kubernetes-sig-network/CAAdXToTbrHAHswjPnOOH9LMVv2u84knYLxzkbRVvfX174_q3HQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Bowei Du]

For the health of the project and to make sure this will be maintained, it's probably the

case that (1) and (2) are a must (e.g. there is just one base library for all use cases)?

Bowei

You received this message because you are subscribed to the Google Groups "kubernetes-sig-multicluster" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-mult...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/kubernetes-sig-multicluster/AM7P189MB0932C1ACB3EF94CB623D465CF8D02%40AM7P189MB0932.EURP189.PROD.OUTLOOK.COM.