For more information, see the following resources:

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.

Configure a basic route table for direct routing to a Kubernetes service

  1. If you have not already, create a virtual gateway in the same cluster as your 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. Ensure that the app is exposed by a Kubernetes service. In this example, the label app: single-app is used as the service selector. The service listens on port 3456 and forwards requests to port 9080.

      apiVersion: v1
    kind: Service
    metadata:
      labels:
        app: single-app
      name: single-app
      namespace: global
    spec:
      ports:
      - name: http
        port: 3456
        protocol: TCP
        targetPort: 9080
      type: ClusterIP
      
  3. Create a basic route table to route requests to your app’s service. This resource allows you to define how requests to endpoints should be routed, and is translated to the Istio VirtualService resource. In this example route table, all requests to the /single-app path are routed to the single-app service.

      kubectl apply -n global -f- <<EOF
    apiVersion: networking.gloo.solo.io/v2
    kind: RouteTable
    metadata:
      name: single-app-routes
      namespace: global
    spec:
      # Applies to any host; can indicate a specific domain
      hosts:
        - '*'
      # Selects the virtual gateway you previously created
      virtualGateways:
        - name: istio-ingressgateway
          namespace: gloo-mesh
      http:
        # Route for the single-app service
        - name: single-app
          # Prefix matching
          matchers:
          - uri:
              prefix: /single-app
          # Forwarding directive
          forwardTo:
            destinations:
              # Reference to Kubernetes service in this cluster
              - ref:
                  name: single-app
                  namespace: global
                port:
                  number: 9080
                kind: SERVICE
    EOF
      
  4. Save the external address of the ingress gateway.

      export INGRESS_GW_ADDRESS=$(kubectl get svc -n istio-system istio-ingressgateway -o jsonpath="{.status.loadBalancer.ingress[0]['hostname','ip']}")
    echo $INGRESS_GW_ADDRESS
      
  5. Test the route to your app by curling the ingress gateway address and app path. For example, the following command appends /single-app for the sample app.

      curl http://$INGRESS_GW_ADDRESS/single-app
      

Next steps

Now that you have basic routes 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.