Update to EndpointSlices v1

[howardjohn]

discovery.k8s.io/v1beta1 EndpointSlices are deprecated in favor of discovery.k8s.io/v1, and will no longer be served in Kubernetes v1.25.

Need to take care when we add it for backwards compat

[howardjohn]

Not stale

…

On Wed, Jul 7, 2021 at 10:04 PM Istio Policy Bot ***@***.***> wrote: 🧭 This issue or pull request has been automatically marked as stale because it has not had activity from an Istio team member since 2021-04-08. It will be closed on 2021-07-22 unless an Istio team member takes action. Please see this wiki page <https://github.com/istio/istio/wiki/Issue-and-Pull-Request-Lifecycle-Manager> for more information. Thank you for your contributions. *Created by the issue and PR lifecycle manager*. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#32056 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEYGXJMOIGAIWPASLAC4JTTWUWVRANCNFSM42TMGPUA> .

[howardjohn]

@stevenctl I think we may need to add support for v1 and v1beta1 concurrently like we did with Ingress. Otherwise we have a delicate timing problem that may not work out.

Or we just move to v1 and say ES support wasn't stable yet - if we do that I think we need to do this before we start using it by default.

[stevenctl]

To support both, we either need to:

1. maintain duplicate code; we could possibly avoid this with codegen but that's not ideal either
2. add some wrappers around EndpointSlice, EndpointPort, Endpoint to allow sharing code which could have perf implications

I think 1 will almost certainly lead to bugs creeping in. I'll try 2 and see how it affects the benchmarks.

[howardjohn]

We do (1) for ingress FWIW. But it's obviously not ideal. I would prefer to have some complexity vs user performance cost *if* its a tangible performance difference - if not then its probably a reasonable tradeoff.

…

On Tue, Oct 12, 2021 at 12:17 PM Steven Landow ***@***.***> wrote: To support both, we either need to: 1. maintain duplicate code; we could possibly avoid this with codegen but that's not ideal either 2. add some wrappers around EndpointSlice, EndpointPort, Endpoint to allow sharing code which could have perf implications I think 1 will almost certainly lead to bugs creeping in. I'll try 2 and see how it affects the benchmarks. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#32056 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEYGXPKDXJFHO7GV5AVY2DUGSCWFANCNFSM42TMGPUA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[stevenctl]

Well.. to measure this I'll need to add some kube bits to bench test.

I think I'll just fork for now and we can consolidate later.

The shared code ends up adding a lot of complexity too. Duplication is probably easier to grok.

[dgn]

shouldn't 1.12 be almost EOL by the time k8s 1.25 is released? is this really a blocker for 1.12?

[howardjohn]

@dgn I don't know why I put it as a release blocker, just dropped it. But it is good to get it in early, otherwise we end up with the 1.10 problem where users on a supported version (1.9) cannot upgrade to k8s 1.22