Route label inheritance

One advantage of route tables is that you can manage routes in bulk through the use of labels. If you use delegated route tables, the delegated routes inherit labels from their parent route tables, even across workspaces. Review the following overview and scenarios to learn how to use labels with routes.

Overview link

Learn more about how labels work at the table-, route-, and delegation-levels.

Table and route labels link

You can label routes at two main levels, table and route.

• Table level: In the metadata.labels section of the route table resource, you can specify a label, such as env: prod. Then, all the routes in the route table get this label.

    apiVersion: networking.gloo.solo.io/v2
  kind: RouteTable
  metadata:
    name: parent
    namespace: source-apps
    labels:
      env: prod
  ...  
    

• Route level: In the spec.http section for each route, you can specify a label for the route. You can also overwrite the table-level label from the metadata.labels section by using the same label key, such as overwriting val: bar to val: foo.

    apiVersion: networking.gloo.solo.io/v2
  kind: RouteTable
  metadata:
    name: parent
    namespace: source-apps
    labels:
      env: prod
      val: bar
  spec:
    hosts:
      - www.example.com
    virtualGateways:
      - name: istio-ingressgateway
        namespace: gloo-mesh-gateways
    http:
      - name: route-a
        labels:
          val: foo
        matchers:
  ...
    

Delegation link

With route table delegation, the sub-tables can also inherit the labels from the parent route table. For more information on delegation, see the Route delegation concept docs.

• In the parent route table, you can label a delegated route in the spec.http section, such as label: foo. Then, the delegated route in the sub-table inherits this route-level label.
• In the sub-table, you can label the route either at the table-level or route-level. You can overwrite the inherited label from the parent route table by using the same label key, such as overwriting label: foo to label: bar.

The precedence for labels of delegated routes is in the following order:

1. The label of the child route (spec.http section).
2. The label of the child route’s table (metadata.labels section).
3. The label of the parent route (spec.http section).
4. The label of the parent route’s table (metadata.labels section).

Example scenarios link

Review the following scenarios that show how routes are labeled at the various table-, route-, and delegation-levels. After, you can review a sample configuration file.

1. Route labels
2. Table labels
3. Conflicting route and table labels
4. Delegation
5. Delegation with child table label
6. Delegation with child route label

Scenario 1: Route labels link

You can apply labels to specific routes.

The route has the val:foo label.

Route A ends up with the following labels:

• val:foo, specified on the route

Back to scenarios

Scenario 2: Table labels link

You can apply labels to a route table. Each route in the table inherits the label.

The route table has the env:prod label. The route has the val:foo label.

Route A ends up with the following labels:

• env:prod, inherited from the table
• val:foo, specified on the route

Back to scenarios

Scenario 3: Conflicting route and table labels link

You might want to use the same label key on the route table and the route. In this case, route labels overwrite table labels.

The route table has the env:prod and val:bar labels. The route has the val:foo label.

Route A ends up with the following labels:

• env:prod, inherited from the table
• val:foo, specified on the route, which overwrites the val:bar table label

Back to scenarios

Scenario 4: Delegation link

Delegated routes inherit the label from their parent routes.

The parent route table has the env:prod and val:bar labels. The parent route has the val:foo label. The route is delegated to a child route table that has neither table nor route labels.

Delegated route A ends up with the following labels:

• env:prod, inherited from the parent table
• val:foo, specified on the parent route, which overwrites the parent val:bar table label

Back to scenarios

Scenario 5: Delegation with child table label link

Delegated routes follow a similar pattern to non-delegated routes in that table-level labels apply to all the routes within the table. In case of a conflict with an inherited label, the child table label takes precedence.

The parent route table has the env:prod and val:bar labels. The parent route has the val:foo label. The route is delegated to a child route table. This time, the child route table has a val:baz table label that conflicts with an inherited label from the parent.

Delegated route A ends up with the following labels:

• env:prod, inherited from the parent table
• val:baz, specified on the child table, which overwrites the inherited val:foo parent route label

Back to scenarios

Scenario 6: Delegation with child route label link

Similar to the previous scenario, route labels overwrite table labels in delegated scenarios just like in non-delegated scenarios. Therefore, with delegated routes, the child’s route-level label takes ultimate precedence.

The parent route table has the env:prod and val:bar labels. The parent route has the val:foo label. The route is delegated to a child route table. This time, the child route table has both a table label and route label that conflicts with each other and an inherited label from the parent.

Delegated route A ends up with the following labels:

• env:prod, inherited from the parent table
• val:qux, specified on the child route, which overwrites the inherited val:foo parent route label as well as the child table label val:baz

Back to scenarios

Example configuration file link

Review the following example that illustrates Scenario 6: Child route labels overwrite inherited labels. Pay attention to the various places where labels are applied, and how the label precedence works.

  # Example of labels for routes
# Parent table with delegated Route A and table labels
apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: parent
  namespace: source-apps
  # Table-level labels
  labels:
    env: prod
    val: bar
spec:
  hosts:
    - www.example.com
  virtualGateways:
    - name: istio-ingressgateway
      namespace: gloo-mesh-gateways
  http:
    - name: route-a
      # Route-level label overwrites table-level "val: bar" label
      labels:
        val: foo
      # Delegate route-a to tables with label "table: child-a"
      delegate:
        routeTables:
        - labels:
            table: child-a 
---
# Child A route table
apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: child-a
  namespace: target-apps
  labels:
    # Matches label in parent route table to for delegation
    table: child-a
    # Overwrites inherited label "val: foo"
    val: baz
spec:
  http:
  # Table routes any requests to 'example.com/app-a/*'
  - name: route-a
    labels: 
      # Overwrites inherited label "val: foo" and table-level label "val: baz"
      val: qux
    matchers:
    - uri:
        prefix: /app-a
        ignoreCase: true
    forwardTo:
      destinations:
      - ref:
          name: app-a
          namespace: target-apps
        port:
          number: 10000
        kind: SERVICE
  

Next steps link

Now that you know about labels, learn how you can use labels to apply policies to routes in delegated and workspace scenarios.