An initial outline of the Envoy configuration required is available at envoy.yaml

The first changes required is to add a Node. This allows the Envoy node to be identified, potentially allowing for unique configurations to be applied.

Task

Prepend the following snippet to the top of the envoy.yaml file.

node:
  id: id_1
  cluster: test

The API also has support for additional metadata, such as locality for providing region and zone-based information.

The EDS configuration is defined to allow the upstream clusters to be controlled dynamically.

Within the static configuration, this was defined as:

  clusters:
  - name: targetCluster
    connect_timeout: 0.25s
    type: STRICT_DNS
    dns_lookup_family: V4_ONLY
    lb_policy: ROUND_ROBIN
    hosts: [
      { socket_address: { address: 172.18.0.3, port_value: 80 }},
      { socket_address: { address: 172.18.0.4, port_value: 80 }}
    ]

Convert to EDS

To convert this to EDS based a eds_cluster_config is required and changing the type to EDS.

Add the following cluster to the end of the Envoy configuration.

  clusters:
  - name: targetCluster
    connect_timeout: 0.25s
    lb_policy: ROUND_ROBIN
    type: EDS
    eds_cluster_config:
      service_name: localservices
      eds_config:
        path: '/etc/envoy/eds.conf'

The values for the upstream servers, such as 172.18.0.3 and 172.18.0.4, will come from the file eds.conf.

The contents of eds.conf is a JSON definition of the same information defined within our static configuration.

Task

Create eds.conf file with the following content:

{
  "version_info": "0",
  "resources": [{
    "@type": "type.googleapis.com/envoy.api.v2.ClusterLoadAssignment",
    "cluster_name": "localservices",
    "endpoints": [{
      "lb_endpoints": [{
        "endpoint": {
          "address": {
            "socket_address": {
              "address": "172.18.0.3",
              "port_value": 80
            }
          }
        }
      }]
    }]
  }]
}

This defines a single endpoint at 172.18.0.3.

With the Envoy configuration and EDS conf defined, it's now possible to start the proxy.

Task

Launch the container with the following command:

docker run --name=proxy-eds-filebased -d \
    -p 9901:9901 \
    -p 80:10000 \
    -v /root/:/etc/envoy \
    envoyproxy/envoy:latest

Start two HTTP servers to handle the incoming requests.

docker run -d katacoda/docker-http-server; docker run -d katacoda/docker-http-server;

Based on the current EDS configuration, Envoy will send all the traffic to a single node. Try it with curl localhost

In the next step we'll update the configuration and add an additional node.

With the configuration based on EDS, when the services need to be scaled up a new endpoint can be added to the eds.conf. Envoy will then automatically include the changes.

Task

Replace the configuration with the following to add a new endpoint to the cluster.

{
  "version_info": "0",
  "resources": [{
    "@type": "type.googleapis.com/envoy.api.v2.ClusterLoadAssignment",
    "cluster_name": "localservices",
    "endpoints": [{
      "lb_endpoints": [{
        "endpoint": {
          "address": {
            "socket_address": {
              "address": "172.18.0.3",
              "port_value": 80
            }
          }
        }
      },
        {
        "endpoint": {
          "address": {
            "socket_address": {
              "address": "172.18.0.4",
              "port_value": 80
            }
          }
        }
      }]
    }]
  }]
}

Based on how Docker handles file inode tracking, sometimes the filesystem change isn't triggered and detected. Force the change with the command mv eds.conf tmp; mv tmp eds.conf

Envoy should automatically reload the configuration and add the new node into the load balancing rotation curl localhost

With EDS in place it's possible to scale up the upstream clusters. If we wanted to be able to dynamaically add new domains and clusters, the cluster discovery service (CDS) API needs to be implemented.

Based on how Docker handles fle inode tracking, sometimes the inotify filesystem change isn't triggered and detected. Force the change with the command mv cds.conf tmp; mv tmp cds.conf