Route label inheritance

Review how you can organize routes with Kubernetes labels.

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

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

Table and route labels

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

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

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

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

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

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

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

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

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

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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

# 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

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