Delegate requests to sub-tables
Delegate 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 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 a service in your mesh sends a request to another service, the request is matched against the routes in the highest-weighted route table first. If the request doesn't match a route in the first sub-table, it is matched against the routes in the second-highest-weighted table, and so on.
-
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 thehosts
orworkloadSelectors
fields. The root route table dictates these fields instead. - In the
spec
section, add theweight
field to indicate route table priority. Higher integer values indicate a higher priority 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 astable: 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: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 'myapp.global.svc.cluster.local/myapp/.*' - matchers: - uri: prefix: /myapp ignoreCase: true forwardTo: destinations: - ref: name: myapp namespace: global cluster: ${CLUSTER_NAME} 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 'myapp.global.svc.cluster.local/myapp/.*?version=stage' - matchers: - uri: prefix: /myapp - queryParameters: - name: version value: stage forwardTo: destinations: - ref: name: myapp namespace: global cluster: ${CLUSTER_NAME} port: number: 8090 kind: SERVICE
- In the
-
Create the root route table to delegate requests based on sub-table weight. In this example root table, requests to the
myapp.global.svc.cluster.local
host are delegated to sub-tables with thetable: 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 therouteTables.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: - 'myapp.global.svc.cluster.local' http: - delegate: # Selects tables based on label routeTables: - labels: table: myapp # Delegates based on order of weights sortMethod: TABLE_WEIGHT EOF
-
Test route table delegation by accessing the host and any necessary request-matching criteria.
- For example, log in to an app in your mesh and send a request to
http://myapp:9080/myapp/foo
to verify that the request is routed to the prefix-matching route in theprefix-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 log in to an app in your service mesh and send a request tohttp://myapp:9080/myapp/foo?version=stage
to verify that the request is routed to the query parameter-matching route in thequery-parameters-match
sub-table.
- For example, log in to an app in your mesh and send a request to
Delegate to sub-tables based on route specificity
Delegate routing to sub-tables based on individual route specificity. When a service in your mesh sends a request to another service, the request is matched against all routes in each sub-table, sorted by specificity, to reduce the chance that a general route short-circuits a more specific route.
The following specificity rules apply:
- Exact path matchers are considered more specific than regex path matchers, which are more specific than prefix path matchers.
- Matchers of the same type are sorted by length of the path in descending order.
- Only the most specific matcher on each route is used.
- In the event of a sort tie, table weights are used across sub-tables, and route order is used within sub-tables.
For example, consider the following two sub-tables that are sorted by specificity and the resulting route list.
- Sub-table A, with a table weight of
1
in case of sort ties:prefix: /foo
prefix: /foo/more/specific
prefix: /foo/even/more/specific
exact: /foo/exact
exact: /foo/another/exact
regex: /foo/*
regex: /fooo/*
- Sub-table B, with a table weight of
2
:prefix: /bar
prefix: /bar/more/specific
prefix: /bar/even/more/specific
exact: /bar/exact
regex: /bar/*
The resulting routes are sorted in this order:
exact: /foo/another/exact
exact: /bar/exact
exact: /foo/exact
regex: /bar/*
regex: /foo/*
regex: /fooo/*
prefix: /bar/even/more/specific
prefix: /foo/even/more/specific
prefix: /bar/more/specific
prefix: /foo/more/specific
prefix: /bar
prefix: /foo
-
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 thehosts
orworkloadSelectors
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 astable: 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: hosts: - 'one.solo.io' virtualGateways: - name: istio-ingressgateway namespace: bookinfo cluster: ${CLUSTER_NAME} http: # Match only requests to exactly 'one.solo.io/myapp/foo' - matchers: - uri: exact: /myapp/foo forwardTo: destinations: - ref: name: myapp namespace: global cluster: ${CLUSTER_NAME} 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: hosts: - 'one.solo.io' virtualGateways: - name: istio-ingressgateway namespace: bookinfo cluster: ${CLUSTER_NAME} http: # Match any requests to 'one.solo.io/myapp/.*' - matchers: - uri: prefix: /myapp ignoreCase: true forwardTo: destinations: - ref: name: myapp namespace: global cluster: ${CLUSTER_NAME} port: number: 8090 kind: SERVICE
- In the
-
Create the root route table to delegate requests based on individual route specificity. In this example root table, requests to the
myapp.global.svc.cluster.local
host are matched against the list of all routes in sub-tables with thetable: myapp
label, sorted by specificity. The request is matched to the most specific route. Note that you can also specify the sub-table names instead of the label by using therouteTables.name
field.kubectl apply --context $REMOTE_CONTEXT1 -n global -f- <<EOF apiVersion: networking.gloo.solo.io/v2 kind: RouteTable metadata: name: delegate-specificity namespace: global spec: hosts: - 'myapp.global.svc.cluster.local' http: - delegate: # Selects tables based on label routeTables: - labels: table: myapp # Delegates based on route specificity sortMethod: ROUTE_SPECIFICITY EOF