Configure EDS with file

[John Hume]

There are some examples showing EDS cluster config similar to this:

name: cluster-name
type: EDS
eds_cluster_config:
  eds_config:
    path: '.../eds.conf'

I haven't been able to find documentation of what the EDS configuration file should look like or what it does. I tried a file containing what appears to be the desired response from an EDS service—something like this:

  version_info: "0"
  resources:
  - "@type": type.googleapis.com/envoy.api.v2.ClusterLoadAssignment
    cluster_name: my_cluster
    endpoints:
    - locality: { region: some_region }
      lb_endpoints:
        - endpoint: { address: { socket_address: { address: my-hostname.example.com, port_value: 443}}}
          metadata: {}

Envoy starts up with that in place (whereas it crashes if the file contains just a yaml ClusterLoadAssignment, i.e., cluster_name and endpoints at the top level), but it doesn't appear to work. Should something like this work? My hope was that it would behave similar to a STRICT_DNS cluster but with EDS's support for load_balancing_weight and priority, which don't seem to exist outside of EDS.

If background is helpful, I'm evaluating Envoy as an alternative to haproxy for reverse-proxying to a pool of gRPC servers.

Thanks.

[John Hume]

After finding the XDS_PROTOCOL document that confirmed the file should contain a DiscoveryResponse, I tried again with IP addresses, which worked. I went back to trying a host name and noticed an error that I'd missed earlier (because envoy still starts up):

> Filesystem config update rejected: malformed IP address: my-hostname.example.com

The documentation for core.SocketAddress suggests that a hostname should work and by default get DNS resolution. Is this not the case in the context of a ClusterLoadAssignment?

[Harvey Tuch]

Here's an EDS filesystem example from our test configs: https://github.com/envoyproxy/envoy/blob/master/test/config/integration/server_xds.eds.yaml

The behavior you describe is what is expected (see https://github.com/envoyproxy/envoy/blob/e1231e1b36b4ddbad19899f63c2bac9f948b33b0/test/common/upstream/eds_test.cc#L611 for test coverage of this).

You need to use LOGICAL_DNS or STRICT_DNS in CDS to get DNS resolution. We should probably do a doc update to make this clearer.

--
You received this message because you are subscribed to the Google Groups "envoy-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to envoy-users...@googlegroups.com.
To post to this group, send email to envoy...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/envoy-users/b7d2b37b-8cbf-4d66-85d9-e0e99f50cd41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John D. Hume]

On Fri, Mar 30, 2018 at 3:34 PM Harvey Tuch <ht...@google.com> wrote:

You need to use LOGICAL_DNS or STRICT_DNS in CDS to get DNS resolution. We should probably do a doc update to make this clearer.

Thanks for the quick reply.

As I interpret your response, DNS resolution is only supported for LOGICAL_DNS and STRICT_DNS-type clusters, so an EDS ClusterLoadAssignment must contain IP addresses. Is DNS resolution for hostnames in ClusterLoadAssignments something that might be supported in the future? The behavior could be similar to STRICT_DNS, where multiple A records would result in the source LbEndpoint expanding to multiple within the lb_endpoints collection.

Do I understand correctly that only EDS clusters support weighting of hosts within the cluster and the priority notion that provides fail-over to backup hosts when primary hosts are unhealthy, so this type of weighting and fail-over is unavailable to LOGICAL_DNS or STRICT_DNS clusters?

[Matt Klein]

Is DNS resolution for hostnames in ClusterLoadAssignments something that might be supported in the future?

Very unlikely. We assume that EDS has already resolved all hosts to IP addresses.

 Do I understand correctly that only EDS clusters support weighting of hosts within the cluster and the priority notion that provides fail-over to backup hosts when primary hosts are unhealthy, so this type of weighting and fail-over is unavailable to LOGICAL_DNS or STRICT_DNS clusters?

Correct. DNS itself has no way to express this. If we can find resources to implement SRV support it's possible we could make this information available somehow via DNS also. 

--

You received this message because you are subscribed to the Google Groups "envoy-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to envoy-users+unsubscribe@googlegroups.com.

To post to this group, send email to envoy...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/envoy-users/CAKK7-VJD_9ebQT3pzMqcyOLKV9VeeZy7%2B%3DbbQwo6Dp48Qp%2BaAg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Matt Klein

Software Engineer

mkl...@lyft.com

https://calendly.com/mattklein123