Route incoming requests from the gateway to an endpoint that is located outside the cluster directly by using the external endpoint’s hostname or IP address.

Before you begin

  1. Set up Gloo Mesh Gateway in a single cluster.
  2. Follow the other guides in this routing section to plan your routing table setup. For example, you might check out the path matching guide to decide how to match the incoming requests to your service paths, the redirect guide to set up any path or host rewrites, or the sub-table delegation guide to nest and sort multiple route tables. Note: Be sure that each route for one host is unique, such as by using prefix matching to determine which requests to the host should be forwarded to which destinations.
  3. Get the external address of your ingress gateway. The steps vary depending on the type of load balancer that backs the ingress gateway.

     ```shell
     export INGRESS_GW_ADDRESS=$(kubectl get svc -n gloo-mesh-gateways istio-ingressgateway -o jsonpath="{.status.loadBalancer.ingress[0]['hostname','ip']}")
     echo $INGRESS_GW_ADDRESS
     ```
    

    Note: Depending on your environment, you might see <pending> instead of an external IP address. For example, if you are testing locally in kind or minikube, or if you have insufficient permissions in your cloud platform, you can instead port-forward the service port of the ingress gateway:

      kubectl -n gloo-mesh-gateways port-forward deploy/istio-ingressgateway-1-23 8081
      

Route to an external service directly

Create an external service to represent the service outside the mesh that you want to route to.

  1. If you have not already, create a virtual gateway in the cluster where you deployed an instance of your global app. This virtual gateway selects the default Istio ingress gateway, which routes incoming traffic (north-south) to your service mesh. For more information about setting up virtual gateways, see the gateway listener guides.

      kubectl apply -f- <<EOF
    apiVersion: networking.gloo.solo.io/v2
    kind: VirtualGateway
    metadata:
      name: istio-ingressgateway
      namespace: gloo-mesh
    spec:
      workloads:
        # Matches on 'spec.selector' labels for the ingress gateway service
        - selector:
            labels:
              istio: ingressgateway
      listeners:
        # The port the ingress gateway listens on for incoming requests to route
        - port:
            number: 80
          http: {}
    EOF
      
  2. Create an external service resource to create a service entry for www.google.com. If you want to specify an IP address or CIDR instead, replace spec.hosts with spec.addresses. Note that you cannot specify a hostname and an IP address or CIDR in the same external service resource.

      kubectl apply -f- <<EOF
    apiVersion: networking.gloo.solo.io/v2
    kind: ExternalService
    metadata:
      name: google
      namespace: bookinfo
    spec:
      hosts:
      - "www.google.com"
      ports:
      - name: http
        number: 80
        protocol: HTTP
      selector: {}
    EOF
      
  3. Create a route table to allow routing to the external service.

      kubectl apply -f- <<EOF
    apiVersion: networking.gloo.solo.io/v2
    kind: RouteTable
    metadata:
      name: rt-google
      namespace: bookinfo
    spec:
      hosts:
        - 'www.google.com'
      virtualGateways:
        - name: istio-ingressgateway
          namespace: bookinfo
          cluster: ${CLUSTER_NAME}
      http:
        # Route for google
        - name: google
          # Prefix matching
          matchers:
          - uri:
              prefix: /google
          # Forwarding directive
          forwardTo:
            destinations:
            # Reference to the external service resource exposing your external endpoints
            - ref:
                name: google
                cluster: $CLUSTER_NAME
              kind: EXTERNAL_SERVICE
            pathRewrite: /
    EOF
      
  4. Test the route to your external resource.

      curl -vik --resolve www.google.com:80:${INGRESS_GW_IP} http://www.google.com:80/google
      

    Example output:

      * Mark bundle as not supporting multiuse
    < HTTP/1.1 200 OK
    HTTP/1.1 200 OK
    < date: Tue, 16 May 2023 17:30:11 GMT
    date: Tue, 16 May 2023 17:30:11 GMT
    < expires: -1
    expires: -1
    < cache-control: private, max-age=0
    cache-control: private, max-age=0
    < content-type: text/html; charset=ISO-8859-1
    content-type: text/html; charset=ISO-8859-1
    ...
      

Create multiple external services

You can create multiple external services that share the same host but have different ports or wildcard subdomains. For example, you might have different teams own different subdomains of an external service. Or, several third-party services might be exposed on different ports of the same host.

Before you begin, create an external service that routes traffic to www.google.com.

  1. Create another external service resource for *.google.com. This way, you can reach another service exposed on the google.com host, such as images.google.com. If you want to specify an IP address or CIDR instead, replace spec.hosts with spec.addresses. Note that you cannot specify a hostname and an IP address or CIDR in the same external service resource.

      kubectl apply -f- <<EOF
    apiVersion: networking.gloo.solo.io/v2
    kind: ExternalService
    metadata:
      name: google-wildcard
      namespace: bookinfo
    spec:
      hosts:
      - "*.google.com"
      ports:
      - name: http
        number: 80
        protocol: HTTP
      selector: {}
    EOF
      
  2. Create route table to allow routing to the wildcard external service.

      kubectl apply -f- <<EOF
    apiVersion: networking.gloo.solo.io/v2
    kind: RouteTable
    metadata:
      name: rt-google-wildcard
      namespace: bookinfo
    spec:
      hosts:
        - '*.google.com'
      virtualGateways:
        - name: istio-ingressgateway
          namespace: bookinfo
          cluster: ${CLUSTER_NAME}
      http:
        # Route for google
        - name: google
          # Prefix matching
          matchers:
          - uri:
              prefix: /google
          # Forwarding directive
          forwardTo:
            destinations:
            # Reference to the external service resource exposing your external endpoints
            - ref:
                name: google-wildcard
                cluster: $CLUSTER_NAME
              kind: EXTERNAL_SERVICE
            pathRewrite: /
    EOF
      
  3. Test the route to your external resource.

      curl -vik --resolve www.images.google.com:80:${INGRESS_GW_IP} http://www.images.google.com:80/google
      

    Example output:

      * Mark bundle as not supporting multiuse
    < HTTP/1.1 200 OK
    HTTP/1.1 200 OK
    < date: Tue, 16 May 2023 17:30:11 GMT
    date: Tue, 16 May 2023 17:30:11 GMT
    < expires: -1
    expires: -1
    < cache-control: private, max-age=0
    cache-control: private, max-age=0
    < content-type: text/html; charset=ISO-8859-1
    content-type: text/html; charset=ISO-8859-1
    ...
      

Cleanup

You can optionally remove the resources that you set up as part of this guide.
  kubectl delete routetable rt-google -n bookinfo
kubectl delete externalservice google -n bookinfo
kubectl delete routetable rt-google-wildcard -n bookinfo
kubectl delete externalservice google-wildcard -n bookinfo
  

Next steps

Now that you have routes for external services set up, you can explore more advanced networking scenarios.

  • Other routing actions: For HTTP routes, you can set up other actions besides forwarding requests. For example, you might check out the prefix matching guide to decide how to match the incoming requests to your service paths, the redirect guide to set up any path or prefix rewrites, or the sub-table delegation guide to nest and sort multiple route tables.
  • Additional route settings: Configure additional route settings, such as weighted routing to version subsets or adding and removing headers.
  • Policies: For more control over traffic behavior, apply traffic management, security, or resiliency policies to your service or route, such as for outlier detection, failover, fault injection, or keep alive connections.