Additional route settings

When you forward requests to a Kubernetes service, virtual destination, or external service, you can configure additional settings in your route table. Review the following sections to set a default destination, route to an application subset, assign weights to app instances, and manipulate headers on requests and responses.

Set a default destination

Set a default destination in a route table so that multiple routes can be easily assigned to that destination.

For example, you might want to designate multiple routes for one destination, for the purpose of assigning certain policies to certain routes. Instead of typing out the same destination definition in each of the routes, you can instead define the destination as the default, and leave the forwardTo directive in each route empty. Note that any routes in the route table that do not specify a destination will forward traffic to the default destination.

In this example route table, the information for the ratings destination is defined in the spec.defaultDestination field, rather than repeated in each http route. This way, the two routes can automatically reference the ratings definition.

apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: www-example-com
  namespace: bookinfo
spec:
  defaultDestination:
    port:
      number: 9080
    ref:
      name: ratings
      namespace: bookinfo
  hosts:
  - www.example.com
  http:
  - forwardTo: {}
    labels:
      "no": auth
    matchers:
    - headers:
      - name: noauth
        value: "true"
    name: ratings-ingress-no-auth
  - forwardTo: {}
    labels:
      route: ratings
    name: ratings-ingress
  virtualGateways:
  - name: north-south-gw

Weighted routing to an application subset

If you are testing multiple versions of your app within your mesh, you can route to each version by using the version numbers. Additionally, you can optionally assign weights to each version of the app to determine the load or requests that each version receives.

For example, say that your app deployment for each version contains the app: global-app label, and labels such as version: v1 and version: v2. In the route table, you add references to the both versions of the app, and specify the version labels in the subset field of each reference section.

Additionally, this example route table specifies an optional weight for each version of the app. 75% of traffic requests to the /global-app are directed to v1, and 25% of traffic requests are directed to v2. Weighted routing can be useful in scenarios such as controlled rollouts to slowly move traffic from an older to a newer version of your app.

Single-cluster routing

In the reference for each Kubernetes service, add subsets and weights.

apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: global-app-routes
  namespace: global
spec:
  hosts:
    - '*'
  # Selects the virtual gateway you previously created
  virtualGateways:
    - name: ingress-gateway
      namespace: gloo-mesh
      cluster: ${REMOTE_CLUSTER1}
  http:
    # Route for the global-app service
    - name: global-app
      # Prefix matching
      matchers:
      - uri:
          prefix: /global-app
      # Forwarding directive
      forwardTo:
        destinations:
          # Reference to Kubernetes service for version 1 of the app in this cluster
          - ref:
              name: global-app
              namespace: global
              cluster: ${REMOTE_CLUSTER1}
            port:
              number: 9080
            # Label for v1
            subset:
              version: v1
            # 75% of request traffic to /global-app
            weight: 75
          # Reference to Kubernetes service for version 2 of the app in this cluster
          - ref:
              name: global-app
              namespace: global
              cluster: ${REMOTE_CLUSTER1}
            port:
              number: 9080
            # Label for v2
            subset:
              version: v2
            # 25% of request traffic to /global-app
            weight: 25

Multi-cluster routing

For each service that your virtual destination exposes, add a reference to the virtual destination. Then, add a version subset and weight to each of the references.

apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: global-app-routes
  namespace: global
spec:
  hosts:
    - '*'
  # Selects the virtual gateway you previously created
  virtualGateways:
    - name: ingress-gateway
      namespace: gloo-mesh
      cluster: ${REMOTE_CLUSTER1}
  http:
    # Route for the global-app service
    - name: global-app
      # Prefix matching
      matchers:
      - uri:
          prefix: /global-app
      # Forwarding directive
      forwardTo:
        destinations:
          # Reference to the virtual destination that selects v1 of the global-app service
          - ref:
              name: global-app
            kind: VIRTUAL_DESTINATION
            subset:
              version: v1
            # 75% of request traffic to /global-app
            weight: 75
          # Reference to the virtual destination that selects v2 of the global-app service
          - ref:
              name: global-app
            kind: VIRTUAL_DESTINATION
            subset:
              version: v2
            # 25% of request traffic to /global-app
            weight: 25

Add or remove headers to the request or response

You can manipulate the headers on both the requests to your services and the responses from your services. In your route table, you can add the forwardTo.options.headerManipulation section to each service reference:

...
      forwardTo:
        destinations:
          - ref:
              name: global-app
              namespace: global
              cluster: ${REMOTE_CLUSTER1}
            port:
              number: 9080
        options:
          headerManipulation:
            ...

Then, specify the following fields to add or remove destination headers to the request or response: