Routing to external services
With Gloo Gateway, you can securely expose external endpoints, such as an on-prem database, within your cluster environment by using Gloo ExternalService and ExternalEndpoint custom resources. Similar to virtual destinations, you can choose to assign a unique internal hostname or IP address to your external endpoint that Gloo Gateway or services in the cluster environment can use to send requests to.
To learn how to set up routing to external services, see Route to external services.
CloudProvider instead of an ExternalService custom resource. For more information, see AWS Lambda in the Gloo Gateway docs.How does it work?
Because external endpoints cannot be automatically discovered by Gloo Gateway, you can use Gloo ExternalService and ExternalEndpoint custom resources to expose external endpoints in your cluster.
Depending on your use case, you can choose between the following options:
- Allow specific IP address or hostname: Use an
ExternalServiceresource to allow routing to a specific IP address, CIDR range, or hostname from the gateway proxy proxy. NoExternalEndpointresource is required. - Add an IP address or hostname to multiple external endpoints: You can use Gloo
ExternalServiceandExternalEndpointcustom resources together to create internal DNS entries that behave similarly to setting up a CNAME or A record in your DNS provider. The ingress gategateway proxyway can use this IP address or internal hostname to reach all of the external endpoints.
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. When requests for these external endpoints reach the gateway proxy, the gateway can use the external service resource to connect to forward the request.
Using ExternalService resources is a good approach, but how do you make sure that your gateway is aware of all the external endpoints that you have and that requests to these endpoints are load balanced accordingly? Maybe, you even want incoming requests 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 one of the database instances, the ingress gateway simply forwards the 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.
To allow routing to an endpoint that is located outside your cluster, make sure that you allow the IP addresses, CIDR ranges, and hostnames in your company's firewall and the cluster's networking policies.
Gloo Gateway uses plaintext to route the request to your external endpoint. To secure communications with mTLS instead, consider using Gloo Mesh Enterprise alongside Gloo Gateway. With Gloo Mesh, you can onboard external endpoints, such as VMs, to an Istio service mesh and secure connections via mTLS. Additionally, you can route to external services from other apps within your service mesh.
Routing to an IP or hostname directly
The following diagram shows how you can use an ExternalService custom resource to route traffic to an external endpoint by using the endpoint's IP address, CIDR range, or hostname.
Routing to external endpoints based on locality
The following diagram shows how a client sends a request to one of the on-prem database instances by using an externally-accessible hostname, such as mydomain.com/database. Gloo Gateway then routes the request to the database.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.
Applying overlapping external service configuration
In some cases, you might have overlapping configuration across multiple external service resources. Gloo Gateway 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 Gateway 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.