Envoy: SRV service discovery support

[mattklein123]

Support SRV queries (used by Consul DNS, etc.) so that DNS can return IP/port combinations.

SRV is not supported by getaddrinfo_a so need to integrate with DNS library to make the query directly.

[mattklein123]

Note, a PR was started in https://github.com/lyft/envoy/pull/517 but it looks like it's not going to get finished. If anyone wants to pick it up please chime in here. cc @0x1997

[ludov04]

Any update on this?
The new service discovery feature on AWS ECS make use of SRV records. If envoy would support this, this would greatly simplify the use of envoy on ECS, no need no manage a consul cluster anymore.

Thanks :)!

[ChrisLahaye]

Any update on this?
The new service discovery feature on AWS ECS make use of SRV records. If envoy would support this, this would greatly simplify the use of envoy on ECS, no need no manage a consul cluster anymore.

Thanks :)!

Are you still using Consul as alternative?

[davidcpell]

@ludov04 @ChrisLahaye I'd also be interested to know!

[venilnoronha]

/assign @venilnoronha

[grayaii]

I think this was supposed to be in 1.11.0 release.
1.11.1 just got released and it looks like this has been pushed to 1.12.0.

[twreid]

Is there any progress on this? We are using ECS service Discovery and it uses SRV records.

[twreid]

I actually did some digging and looks like a library c-ares is used for dns resolution and looking at it they do support SRV records. Unless I'm missing something.

[ChrisLahaye]

@twreid could you please let me know when you find a solution. We would also like to use envoy with SRV-based service discovery.

[ieugen]

I'm also looking into using SRV for service discovery with envoy.

[descalzi]

Same here, I need ip/port (SRV records) from Consul. Thanks!

[FallenWarrior2k]

Any particular reason you want to use SRV records for that?

Don't get me wrong, I definitely want to see support for SRV records myself, but Consul and Envoy have a native integration already, so I'm wondering what your reason is for not using that.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, 30 November 2020 18:43, Martin [e-mail] wrote:

Same here, I need ip/port (SRV records) from Consul. Thanks!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[descalzi]

Just because I think I'll be able to get the records on SRV (and non-Consul services) before I can get the necesary changes in my Consul agent for the whole sidecar thing needed ... :)

[twreid]

For me the main reason is because my company would rather pay AWS for infrastructure than spin up a consul cluster and AWS service discovery uses SRV records.

[kylebevans]

I'm considering working on this, but I'm trying to get a bearing on what the desired direction is at this point. From poring over #517, #6379, #1477, #1835, #4290, #5186, #10361 and the code itself, it seems like the desire is to make the custom resolver interface asynchronous and then possibly hook the current dns resolver into it so that EDS clusters can use dns resolution. Am I reading that correctly? If so, do you still want to keep the custom resolver interface coupled to the dispatcher and use continuation passing/callbacks to achieve async?

The previous discussions seem to point to adding SRV support as a custom resolver once async resolvers are implemented. But I have these thoughts and questions about it:

• If I'm reading correctly, the idea was that SRV resolution would be engaged if SrvResolver was specified as the resolver in an Address message or the url was configured like this: tcp://hostname.example.com:srv. However, since SRV records begin with an underscore and A, AAAA, and CNAME records can't begin with an underscore, I kind of like just triggering SRV if the hostname begins with an underscore or SrvResolver is specified as a custom resolver. What do you think?

• I think config.endpoint.v3.LbEndpoint should also have a priority field added to map to a SRV priority and it could work the same way as a locality priority. What do you think?

• Should SRV priority and weight override configured priority and weight specified on a config.endpoint.v3.LbEndpoint? My opinion is that config should take precedence since someone setting those fields with a SRV address is probably doing it on purpose and wants to override SRV.

• There has been discussion about moving port handling into the dns interface, but the clusters still have to construct Host objects. Would it make it easier on the clusters for resolvers to just return Host objects directly? Maybe make a distinction between Address resolvers and ClusterLoadAssignment resolvers?

• 14310 talks about making DNS resolvers an extension. How does that affect the custom resolver interface and SRV resolution? I'm concerned since I'll be working in my spare time and probably won't be very fast if there is overlap.

No rush, I know the project is on break.