Support EndpointSlice Synchronization for Linkerd Federated Service
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 11.5k
- Forks
- 1.4k
- Avg merge
- 3d 22h
- Merged PRs (30d)
- 53
Description
### 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?
* I implemented a **custom controller** that copies the Service IP into EndpointSlice endpoints as a workaround.
* This works to a point, but I want to **expose remote endpoints directly**.
* Linkerd’s federated service is typically used in **flat mode**, so gateways like Envoy can consume those endpoint IPs directly.
* Direct exposure would let third-party gateways (e.g., Envoy Gateway, ALB Controller) **use their full feature set**, embracing Unix-style composability and expanding Linkerd’s ecosystem.
### 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
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no files or tests; start by locating the federated-service controller and its Service synchronization entry points. Done means an optional controller setting preserves default behavior while synchronizing EndpointSlices across clusters with conditions, hostname, topology, and hints, verified through controller tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- distributed-systems, infrastructure, networking
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100