Consul can only translate the gateway registration information into Envoy configuration, so any sidecars that send upstream traffic through a gateway must be Envoy.
I’m interested in whether “native” applications can participate with mesh gateways and, more broadly, to what extent “native” applications differ from the first-class citizens in a Connect mesh that use Envoy sidecar proxies.
Concrete questions:
Can a “native” application that’s a client of an upstream service contact such a service in a different data center by way of a mesh gateway? Would it need to do anything special to have its connections and traffic find such a distant target?
Can a “native” application that’s a server receive traffic from downstream clients in different data centers by way of a mesh gateway?
We are considering when we’re willing to tolerate using sidecar proxies, and in many cases would prefer to write our applications as “native” Connect participants. What can’t we do in that model that we could otherwise do with proxies?
@lkysow, is this something you can speak to? If not, who would you recommend I ask about this? I can take it to a mailing list if there’s one you have in mind.
Fundamentally there is no technical reason which prevents native applications from being able to utilize mesh gateways.
At the moment Consul’s Go API client/SDK does not support returning information which would direct a client to utilize a mesh gateway to connect to an endpoint in a remote DC.
Yes, to my knowledge this should just work. The mesh gateway should Connect to the native app the same as it would a sidecar proxy.
Thank you, @blake. That you wrote “at the moment” suggests that we could teach this capability to the Go SDK. Is this feasible? Do you know if anyone is planning on implementing it?
Also, with the current lack, what would happen if such an SDK client looked up a service in a different data center? Would it find no IP addresses (or DNS names) available?
Yes, it should be possible to add support for gateways to the Go SDK. We’re exploring this, but currently don’t have a timeline for when this might be available.
For cross-DC lookups, the DNS (Connect-capable service lookups) or HTTP (GET /catalog/connect/:service) service discovery interfaces would return the IP address of the service’s connect proxy in the remote data center. What would be missing form that output is the info regarding how to actually route to those services through the mesh gateways. This is the gap that needs to be addressed.
I hope this clarifies the state of things. Let me know if you have any additional questions.
How does Consul (or Connect) retrieve the extra information fed into Envoy, in order to allow it to forward through the outbound mesh gateway? Is that where the Catalog API comes into play?
We would need to modify the SDK to watch for changes in the Discovery Chain API for a given service (GET /v1/discovery-chain/:service), and perform service discovery based on returned resolution info – adding additoinal logic which takes into account various levels of mesh gateway configuration.
We don’t really have this process documented (outside of code) today. You could potentially look at the xDS configuration that Consul injects into Envoy to get an understanding of what Envoy is doing to enable this.
If you’d like, I’d be happy to connect offline to walk you through some of this at a high level. Let me know if that would be of interest to you.