envoyproxy/envoy

Locality endpoint discovery service (LEDS)

Open

#10,373 opened on Mar 12, 2020

View on GitHub
 (29 comments) (4 reactions) (1 assignee)C++ (5,373 forks)batch import
area/service discoveryarea/xdshelp wanted

Repository metrics

Stars
 (27,997 stars)
PR merge metrics
 (Avg merge 8d) (378 merged PRs in 30d)

Description

A group of us met this morning to discuss how to move the EGDS issue and PR forward:

The consensus at this point is that we would like to hold on working on and merging EGDS as currently specified and instead develop something that we are tentatively calling IEDS (Individual Endpoint Discovery Service). Note that better name suggestions are appreciated here!

The general idea of IEDS will be to allow a sub-API of EDS to provide individual endpoints within a defined locality/priority. This will avoid quite a bit of complexity around shuffling endpoints within localities/priorities. Additionally, localities/priorities rarely change in a deployment.

The high level flow of the IEDS API will be:

  1. Allow the lb_endpoints to either be specified inline as today or instead pointed at a config source that configures the IEDS endpoint https://github.com/envoyproxy/envoy/blob/e1962d76c073bb48c57acd0ff2b57390a22394b7/api/envoy/config/endpoint/v3/endpoint_components.proto#L109
  2. Determine how the IEDS resource name will be populated. Some proposals have included adding a namespace field. I'm not as clear on this part so I will defer to @htuch and @markdroth on what they want to do here. From my perspective it would be OK to have the config source specify a namespace and then have that namespace passed as the resource name in the discovery request: https://github.com/envoyproxy/envoy/blob/e1962d76c073bb48c57acd0ff2b57390a22394b7/api/envoy/service/discovery/v3/discovery.proto#L42
  3. Modify the EDS code to work properly with the sub-API in which we properly do init manager init as well as populate/update the hosts in a locality/priority. This should work correctly with delta/incremental also.

To avoid confusion, note that we are not tackling merging/patching as mentioned here: https://github.com/envoyproxy/envoy/issues/8400. That is a much larger project that should not block this effort.

cc @envoyproxy/maintainers @htuch @markdroth @snowp @wgallagher @tomwans @gengleilei @hzxuzhonghu @seflerZ @lambdai @howardjohn @ramaraochavali

Contributor guide