Resolve Service to Endpoints IPs

[danehans]

#16 specifies the need for a Service Resolver (SR) component that resolves IR services into platform-specific endpoints. The SR details should be captured in this issue or a linked doc.

[danehans]

The service resolver is currently the responsibility of a provider. I'm moving this issue to the backlog for now.

[danehans]

@arkodg can this issue be closed?

[arkodg]

we dont need a full fledged service resolver design & implementation, but a reconciler within provider is needed to aggregate service endpoints. should be doable for 0.3.0

[danehans]

I suggest holding this issue until #702 is merged.

[arkodg]

@zhshw can you help with this issue ?

[zhshw]

@arkodg I'm working on it...

[arkodg]

thanks @zhshw .
Outlining the pieces needed to implement this issue

• Reconciling the EndpointSlice https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/ in the provider

  gateway/internal/provider/kubernetes/controller.go

  Line 186 in 5b8b24e

  resourceTree.Services = append(resourceTree.Services, service)

• Saving it in the watchable map

  gateway/internal/gatewayapi/resource.go

  Line 24 in 5b8b24e

  type Resources struct {

• Generating the IR RouteDestinations based on the EndpointSlice info in

  gateway/internal/gatewayapi/route.go

  Line 678 in 5b8b24e

  func (t *Translator) processRouteDestination(backendRef v1beta1.BackendRef,

[zhshw]

Thanks @arkodg reply.

The endpoint is updated frequently. It should be an independent workqueue.
Endpoint-slices reduce data transmission and optimize network throughput, But there may be some problems

endpoint-slices

• Kubernetes v1.21 [stable]
• Kubernetes v1.26 [GA]

Before Kubernetes v1.26
Endpoint-slice's terminating condition was implemented on 1.21, and the proxyterminating problem 1.26 was fixed

Kubernetes >= v1.21
Use endpoint-slices stable API AND pod.API
informer [endpoint-slice v1，pod]

Kubernetes General version
Use endpoint API and pod API, but the network throughput has not been optimized. There is no problem with small-scale clusters, It is necessary to get the status of pod at the same time to determine whether to enter Terminating
informer [endpoint, pod]

Istio compatibility
For maximum compatibility, Istio support watches the pod, endpoint, endpoint-slice [v1, v1beta1], Istio allows users to choose the endpoint configuration,
informer [endpoint, pod] OR informer [endpoint-slice v1, pod] OR informer [endpoint-slice v1beta1, pod]

Improvement Goal
Design envoy-endpoint, It can support K8S versions in recent years
Update endpoints by watching for pod update. Minimum network data transmission, Medium coding cost

Node NotReady
Pod ready status will not change within 5 minutes by default, must configure healthcheck to eliminate abnormal endpoints faster

Finally, Things don't seem so simple... [Performance, Compatibility, Coding cost]

[danehans]

Since we will need an abstraction to supports multiple implementations, WDYT about starting off with endpoints instead of endpoint slices and iterating? We could introduce endpointslices thereafter.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[danehans]

@zhshw I just cleared the stale status for this issue. Are you still planning to work on this?

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days.

[arkodg]

unassigning @zhshw for now, will reassign again if interested, adding the help-wanted tag for this important feature

[arkodg]

closing in favor of #1256