Routing to external services
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 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
ExternalEndpoint custom resources.
Depending on your use case, you can choose between the following options:
- Allow specific IP or hostname: Use an
ExternalServiceresource to allow routing to a specific IP, CIDR range, or hostname. No
ExternalEndpointresource is required.
- Add an IP address or hostname to multiple external endpoints: You can use Gloo
ExternalEndpointcustom 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.
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
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.
If you installed Istio with the
ALLOW_ANY option, the services in your service mesh can route to external endpoints. You do not need to configure Gloo
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.
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.
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.