Overview

With Gloo Mesh, you can securely expose external endpoints, such as an on-prem database, to the services within your service mesh by using external endpoints and services. Similar to Similar to virtual destinations, you can choose to assign a unique internal hostname to your external endpoint that your services in the service mesh use to send requests to.

To learn how to set up routing to external services, see Route to external services.

How does it work?

When you install Istio in your cluster, your service mesh is configured with the REGISTRY_ONLY option by default. This option allows only traffic between services that are registered in the mesh. Routing traffic to services outside the mesh is prohibited. To route to a service that is located outside the mesh, you can use Gloo ExternalService and ExternalEndpoint custom resources.

Depending on your use case, you can choose between the following options:

  • Allow specific IP or hostname: Use an ExternalService resource to allow routing to a specific IP, CIDR range, or hostname. No ExternalEndpoint resource is required.
  • Add an IP address or hostname to multiple external endpoints: You can use Gloo ExternalService and ExternalEndpoint custom resources together to create internal DNS entries that behave similar to setting a CNAME or A record in your DNS provider.

Let’s consider an example where you want to connect to an on-prem database that is spread across multiple data centers. Each instance is assigned a static IP address or hostname that you can use to connect to the instance. You have the option to create a Gloo ExternalService resource and to include the IP addresses, CIDR range, or hostnames of the database instances. Services in the mesh are now allowed to route traffic to these database instances by using the IP or hostname of the database instances directly.

Using ExternalService resources is a good approach, but how do you make sure that your services in your service mesh are aware of all the external endpoints that you created and that requests to these endpoints are load balanced accordingly? Maybe, you even want requests from your service mesh to be routed to the closest external endpoint by default. You can solve these problems by using the ExternalService and ExternalEndpoint custom resources together.

In this approach, you create an ExternalEndpoint resource for each of your database instances. The resource specifies the IP address, port, hostname, and protocol that must be used to connect to the database instance. Then, you use the ExternalService resource to assign a unique internal hostname or static IP address to all of the external endpoints that you created. Creating an internal hostname acts similar to a CNAME, whereas specifying an IP address is similar to defining an A record in your DNS provider. To route to the database instances, the services in your service mesh simply send a request to the internal hostname or IP. The external service resource automatically load balances the request between the external endpoints that you defined. When combined with an outlier detection policy, the external service applies locality-based routing rules to the external endpoints.

Routing to an IP or hostname directly

The following diagram shows how you can use an external service resource to route traffic to an endpoint that is located outside your service mesh by using the endpoint’s IP address, CIDR range, or hostname.

Figure: Routing to external services based on locality
Figure: Routing to external services based on locality

Routing to external endpoints based on locality with internal hostname

The following diagram shows how the client sends a request to one of the on-prem database instances by using the database.mesh.external:80 address that was defined in the external service. You can configure the external service to consider the external endpoint’s locality before deciding what database instance receives the request by applying an outlier detection policy to it. Because the cluster and the on-prem data center are both located in Dallas, the request is routed to the database B instance in Dallas.

Figure: Routing to external services based on locality
Figure: Routing to external services based on locality

Routing to external endpoints in a failover scenario

In this diagram, database instance B became unavailable and cannot respond to any requests. Because an outlier detection and a failover policy are applied to the external service resource, Gloo is aware that the database instance is unresponsive. The request is automatically routed to database instance A.

Figure: Routing to external services in a failover scenario
Figure: Routing to external services in a failover scenario

Applying overlapping external service configuration

In some cases, you might have overlapping configuration across multiple external service resources. Gloo Mesh validates the addresses that you specify in each external service, and does not translate an external service that defines the same address as an external service that already exists in your Gloo Mesh environment. However, you can apply external services that define the same address in different workspaces, if the workspaces do not import or export the external service resources between them. For example, you might represent the same database with the same address by applying an external service in a staging workspace and by applying an external service in a prod workspace. Because you do not import or export the external service resources between these two workspaces, the external service resources can be safely applied.