Delegate requests to sub-tables

Delegate incoming requests through one root route table to other sub-tables.

As your Gloo Mesh environment grows in size and complexity, the number of routes configured on a given gateway might increase considerably. Or, you might have multiple ways of routing to a particular path for an app that are difficult to consistently switch between. To organize multiple routes, you can create sub-tables for individual route setups. Then, you create a root route table that delegates requests to those sub-tables based on a specified sorting method.

For more information, see the Gloo Mesh API docs for route table delegation.

Delegate to sub-tables based on weight

Delegate routing to sub-tables based on an assigned order. Individual routes are kept in the order that they appear relative to their tables, but tables are sorted by the weight that you assign to them. When an incoming request arrives at the ingress gateway, the gateway attempts to match the request against the routes in the highest-weighted route table first. If the request doesn't match a route in the first sub-table, the gateway attempts to match against the routes in the second-highest-weighted table, and so on.

  1. Follow the guides in Forward requests to a destination to set up each route table that you want to include in this sub-table set. For each route table, include the following additional settings for delegation:

    • In the spec section, do not include the hosts or virtualGateways fields. The root route table dictates these fields instead.
    • In the spec section, add the weight field that the ingress gateway uses when choosing a route table to delegate to. Higher integer values indicate a higher order in the list of sub-tables. Note that tables of the same weight stay in the same order that you list them in the root route table, which is the list order when you specify sub-tables by name, or the creation timestamp when you select sub-tables by label.
    • Optional: If you want to refer to the sub-tables by label rather than by table name, add a label in the metadata section. Be sure to use the same label for each sub-table.

    Example: Say that you are testing multiple types of request matching for myapp. You define two different route tables, one for each type of matching, and label them as table: myapp. You assign a higher weight to the table that uses prefix matching to test that matching method now, and a lower weight to the table that uses query parameters to focus on that later. Your sub-tables might look like the following configurations:

    kubectl apply --context $REMOTE_CONTEXT1 -n global -f- <<EOF
    apiVersion: networking.gloo.solo.io/v2
    kind: RouteTable
    metadata:
      name: prefix-match
      namespace: global
      # Label for the sub-table set
      labels:
        table: myapp
    spec:
      # Higher weight means first priority in the sub-table order
      weight: 100
      http:
      # Table routes any requests to 'one.solo.io/myapp/.*'
      - matchers:
        - uri:
            prefix: /myapp
            ignoreCase: true
        forwardTo:
          destinations:
          - ref:
              name: myapp
              namespace: global
              cluster: ${REMOTE_CLUSTER1}
            port:
              number: 8090
            kind: SERVICE
     ---
     apiVersion: networking.gloo.solo.io/v2
     kind: RouteTable
     metadata:
       name: query-parameters-match
       namespace: global
       # Label for the sub-table set
       labels:
         table: myapp
     spec:
       # Lower weight means second priority in the sub-table order
       weight: 90
       http:
       # Table routes any requests to 'one.solo.io/myapp/.*?version=stage'
       - matchers:
         - uri:
             prefix: /myapp
         - queryParameters:
           - name: version
             value: stage
         forwardTo:
           destinations:
           - ref:
               name: myapp
               namespace: global
               cluster: ${REMOTE_CLUSTER1}
             port:
               number: 8090
             kind: SERVICE
     EOF
    
  2. Create the root route table to delegate requests based on sub-table weight. In this example root table, the ingress gateway delegates all requests to the one.solo.io host to sub-tables with the table: myapp label, based on the order created by table weights. Note that you can also specify the sub-table names instead of the label by using the routeTables.name field.

    kubectl apply --context $REMOTE_CONTEXT1 -n global -f- <<EOF
    apiVersion: networking.gloo.solo.io/v2
    kind: RouteTable
    metadata:
      name: delegate-weight
      namespace: global
    spec:
      hosts:
        - 'one.solo.io'
      virtualGateways:
        - name: ingress-gateway
          namespace: gloo-mesh
          cluster: ${REMOTE_CLUSTER1}
      http:
      - delegate:
          # Selects tables based on label
          routeTables:
            - labels:
                table: myapp
          # Delegates based on order of weights
          sortMethod: TABLE_WEIGHT
    EOF
    
  3. Test route table delegation by accessing the host and any necessary request-matching criteria.

    • For example, curl or navigate to one.solo.io/myapp/foo to verify that the ingress gateway correctly delegates to the prefix-matching route in the prefix-match sub-table.
    • You might also change the weights for the sub-tables to test that order instead, such as putting the query-parameters-match sub-table higher in the order. Then, you can send a request to one.solo.io/myapp/foo?version=stage to verify that the ingress gateway correctly delegates to the query parameter-matching route in the query-parameters-match sub table.

Delegate to sub-tables based on route specificity

Delegate routing to sub-tables based on individual route specificity. When an incoming request to a host arrives at the ingress gateway, the gateway processes all routes in each sub-table that you select. The resulting routes are sorted by specificity to reduce the chance that a general route short-circuits a more specific route.

The following specificity rules apply:

  1. Follow the guides in Forward requests to a destination to set up each route table that you want to include in this sub-table set. For each route table, include the following additional settings for delegation:

    • In the spec section, do not include the hosts or virtualGateways fields. The root route table dictates these fields instead.
    • Optional: If you want to refer to the sub-tables by label rather than by table name, add a label in the metadata section. Be sure to use the same label for each sub-table.

    Example: Say that you are testing multiple types of request matching for myapp. You define two different route tables, one for exact and one for prefix matching, and label them as table: myapp. Your route tables might look like the following:

    apiVersion: networking.gloo.solo.io/v2
    kind: RouteTable
    metadata:
      name: exact-match
      namespace: global
      # Label for the sub-table set
      labels:
        table: myapp
    spec:
      http:
      # Match only requests to exactly 'one.solo.io/myapp/foo'
      - matchers:
        - uri:
            exact: /myapp/foo
        forwardTo:
          destinations:
          - ref:
              name: myapp
              namespace: global
              cluster: ${REMOTE_CLUSTER1}
            port:
              number: 8090
            kind: SERVICE
     ---
     apiVersion: networking.gloo.solo.io/v2
     kind: RouteTable
     metadata:
       name: prefix-match
       namespace: global
       # Label for the sub-table set
       labels:
         table: myapp
     spec:
       http:
       # Match any requests to 'one.solo.io/myapp/.*'
       - matchers:
         - uri:
             prefix: /myapp
             ignoreCase: true
         forwardTo:
           destinations:
           - ref:
               name: myapp
               namespace: global
               cluster: ${REMOTE_CLUSTER1}
             port:
               number: 8090
             kind: SERVICE
    
  2. Create the root route table to delegate requests based individual route specificity. In this example root table, the ingress gateway first processes all routes in sub-tables with the table: myapp label. Then, the gateway delegates any requests to the one.solo.io host to the most specifically matched route. Note that you can also specify the sub-table names instead of the label by using the routeTables.name field.

    kubectl apply --context $REMOTE_CONTEXT1 -n global -f- <<EOF
    apiVersion: networking.gloo.solo.io/v2
    kind: RouteTable
    metadata:
      name: delegate-weight
      namespace: global
    spec:
      hosts:
        - 'one.solo.io'
      virtualGateways:
        - name: ingress-gateway
          namespace: gloo-mesh
          cluster: ${REMOTE_CLUSTER1}
      http:
      - delegate:
          # Selects tables based on label
          routeTables:
            - labels:
                table: myapp
          # Delegates based on route specificity
          sortMethod: ROUTE_SPECIFICITY
    EOF