What problem are you trying to solve?
Currently, Linkerd’s federated service does not synchronize EndpointSlices across clusters.
This makes it difficult to integrate with third-party load balancers (e.g., AWS Load Balancer Controller, Envoy Gateway) that rely on endpoint-level information rather than just Service IPs.
Many implementations of the Gateway API (and similar systems) do not use the Service’s cluster IP directly. Instead, they register the endpoints from EndpointSlices into their data plane (e.g., Envoy config) to perform load balancing and routing.
How should the problem be solved?
Add an optional mechanism for synchronizing EndpointSlices in Linkerd’s federated service, enabled via a controller startup flag (or equivalent configuration).
When enabled, the controller should:
-
Sync EndpointSlices across clusters so external systems can consume real pod endpoints.
-
Preserve full EndpointSlice semantics, not just addresses:
- Populate
conditions (e.g., ready, serving, terminating) to reflect endpoint health/state.
- Carry over
hostname to aid systems that key on stable endpoint identities.
- Propagate topology information (e.g., zone/region/node, hints) to enable locality-aware routing and more advanced LB policies.
This richer synchronization broadens interoperability with third-party gateways and controllers.
Any alternatives you've considered?
How would users interact with this feature?
- By default, behavior remains unchanged (only Service IPs are effectively used).
- Users explicitly enable EndpointSlice synchronization via a controller flag (e.g.,
--enable-endpointslice-sync) or config.
- Once enabled, EndpointSlices (with conditions/hostname/topology) are synced across clusters, becoming visible to external systems without extra manual steps.
Would you like to work on this feature?
None
What problem are you trying to solve?
Currently, Linkerd’s federated service does not synchronize EndpointSlices across clusters.
This makes it difficult to integrate with third-party load balancers (e.g., AWS Load Balancer Controller, Envoy Gateway) that rely on endpoint-level information rather than just Service IPs.
Many implementations of the Gateway API (and similar systems) do not use the Service’s cluster IP directly. Instead, they register the endpoints from EndpointSlices into their data plane (e.g., Envoy config) to perform load balancing and routing.
How should the problem be solved?
Add an optional mechanism for synchronizing EndpointSlices in Linkerd’s federated service, enabled via a controller startup flag (or equivalent configuration).
When enabled, the controller should:
Sync EndpointSlices across clusters so external systems can consume real pod endpoints.
Preserve full EndpointSlice semantics, not just addresses:
conditions(e.g.,ready,serving,terminating) to reflect endpoint health/state.hostnameto aid systems that key on stable endpoint identities.This richer synchronization broadens interoperability with third-party gateways and controllers.
Any alternatives you've considered?
I implemented a custom controller that copies the Service IP into EndpointSlice endpoints as a workaround.
How would users interact with this feature?
--enable-endpointslice-sync) or config.Would you like to work on this feature?
None