linkerd / linkerd/linkerd2

Support EndpointSlice Synchronization for Linkerd Federated Service

Open
#14,445 11 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

area/multicluster enhancement wontfix
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.