RouteTable

Proto: route_table.proto

Package: networking.gloo.solo.io

A RouteTable resource defines one or more hosts and a set of traffic route rules that describe how to handle traffic for these hosts. Route tables support two types of routes: HTTP and TCP.

You can delegate HTTP routes to other route tables based on one or more matching hosts and specific route paths. If your “parent” route table delegates some traffic rules to another “child” route table, the child route table must be in the same workspace or imported to the parent route table’s workspace.

You can match traffic that originates from an ingress gateway (north-south), Istio mesh gateway (east-west), or directly from the sidecars of workloads in your service mesh (east-west), depending on the configuration of the virtualGateways field.

For more information, see the Routing overview concept docs.

Examples link

The following example defines route configuration for the ‘uk.bookinfo.com’ and ’eu.bookinfo.com’ hosts. Traffic arrives at the my-gateway virtual gateway in the my-gateway-ws workspace. The route table sets up several different matchers to direct HTTP traffic.

• When the cookie in the header matches to user=dev-123, HTTP traffic is forwarded to the port 7777 of the v1 of reviews.qa service.
• When the path matches exactly to /reviews/ HTTP traffic is forwarded to port 9080 of the reviews.qa service.
• All other HTTP traffic is sent to the default destination, which is port 9080 of reviews.prod service in the bookinfo workspace.

  apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: bookinfo-root-routes
  namespace: bookinfo
spec:
  hosts:
    - 'uk.bookinfo.com'
    - 'eu.bookinfo.com'
  virtualGateways:
    - name: my-gateway
      namespace: my-gateway-ws
  defaultDestination:
    ref:
      name: reviews
      namespace: prod
    port:
      number: 9080
  http:
    - name: reviews-qa
      matchers:
        - headers:
            - name: cookie
              value: 'user=dev-123'
      forwardTo:
        destinations:
          - ref:
              name: reviews
              namespace: qa
            subset:
              version: v1
            port:
              number: 7777
    - name: reviews
      matchers:
        - name: review-prefix
          uri:
            exact: /reviews/
      forwardTo:
        destinations:
          - ref:
              name: reviews
              namespace: qa
            port:
              number: 9080
  

The following example defines route configuration for the ’example.com’ host. Traffic arrives at the istio-ingressgateway virtual gateway in the global workspace. The route table sets up one matcher to direct HTTP traffic to multiple versions of one app. For example, say each version contains the app: global-app label, and labels such as version: v1 and version: v2. The route table references both versions of the app, and specifies the version labels in the subset field of each reference. Additionally, this example specifies an optional destination 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.

  apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: global-app-routes
  namespace: global
spec:
  hosts:
    - example.com
  # Selects the virtual gateway you previously created
  virtualGateways:
    - name: istio-ingressgateway
      namespace: global
  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
            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
            port:
              number: 9080
            # Label for v2
            subset:
              version: v2
            # 25% of request traffic to /global-app
            weight: 25
  

AWS Lambda examples: For more information, see the AWS Lambda integration in the Gloo Mesh Gateway docs.

The following example defines route configuration for the ‘uk.bookinfo.com’ and ’eu.bookinfo.com’ hosts. Traffic arrives at the my-gateway virtual gateway in the my-gateway-ws workspace. The route table sends traffic to an external cloud function.

• When the HTTP route path matches the prefix /lambda, traffic is forwarded to the backing aws-provider CloudProvider.
• The associated aws-provider CloudResources resource describes an AWS Lambda service named logicalName: aws-dest.
• The "SYNC" option indicates that the AWS Lambda function is invoked synchronously, which is also the default behavior.

  apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: bookinfo-root-routes
  namespace: bookinfo
spec:
  hosts:
    - 'uk.bookinfo.com'
    - 'eu.bookinfo.com'
  virtualGateways:
    - name: my-gateway
      namespace: my-gateway-ws
  defaultDestination:
    ref:
      name: reviews
      namespace: prod
    port:
      number: 9080
  http:
    - name: lambda
      matchers:
        - uri:
            prefix: /lambda
      labels:
        route: lambda
      forwardTo:
        destinations:
          - awsLambda:
              cloudProvider:
                name: aws-provider
                namespace: bookinfo
                cluster: cluster-1
              function: aws-dest
              options:
                invocationStyle: SYNC
  

The following example defines route configuration for the ‘uk.bookinfo.com’ and ’eu.bookinfo.com’ hosts. Traffic arrives at the my-gateway virtual gateway in the my-gateway-ws workspace. The route table sends traffic to an external cloud function.

• When the HTTP route path matches the prefix /lambda, traffic is forwarded to the delegated route table for handling requests to AWS Lambdas.
• The allowedRoutes restrict the usage of CloudProvider functionality, which routes to cloud functions backend-function-* in region us-east-2 and which assumes the dev-team-B-* IAM role in AWS to invoke the function.

  apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: bookinfo-root-routes
  namespace: bookinfo
spec:
  hosts:
    - 'uk.bookinfo.com'
    - 'eu.bookinfo.com'
  virtualGateways:
    - name: my-gateway
      namespace: my-gateway-ws
  defaultDestination:
    ref:
      name: reviews
      namespace: prod
    port:
      number: 9080
  http:
    - name: lambda
      matchers:
        - uri:
            prefix: /lambda
      labels:
        route: lambda
      delegate:
        allowedRoutes:
          - cloudProvider:
              aws:
                lambda_function:
                  - backend-function-.*
                iam_roles:
                  - dev-team-B-.*
                regions:
                  - us-east-2
        routeTables:
          - labels:
              table: lambda
  

DelegateAction link

Delegate routing decisions to one or more HTTP route tables. This can be used to delegate a subset of the route table’s traffic to another route table, which may live in an imported workspace, or to separate routing concerns between objects.

DirectResponseAction link

Respond directly to the client from the proxy.

ForwardToAction link

When a client request matches a route, Gloo forwards the request to the destination that you specify in this forwardTo action.

GraphQLAction link

Handle the HTTP request as a GraphQL request, including query validation and execution of the GraphQL request. The incoming GraphQL request must either be a GET or POST request. For more information, see Serving over HTTP in the GraphQL docs.

GraphQLAction.Options link

HTTPRoute link

Use HTTP routes to control Layer 7 application level traffic to your services. To configure HTTP routes, you pair together HTTP request matchers with certain actions. Matchers are criteria such as a route name, port, header, or method to match with an incoming request. Actions describe what to do with a matching request, such as forwardTo a destination or delegate to another route table. You can add metadata such as names and labels to your HTTP routes so that you can apply policies, track metrics, and better manage the routes.

HTTPRoute.LabelsEntry link

PortalMetadata link

With Portal installed as part of Gloo Platform, you can use route tables to bundle together individual routes into an API product. When the Portal resource selects your route table, Gloo automatically generates an OpenAPI specification for the API product, which includes all of the routes. You can use this PortalMetadata setting to customize details about your API product, such as by providing a title, description, terms of service, licensing, and lifecycle management information. After you deploy a frontend application for your portal, your end users can review the metadata in the portal to help them use your API products.

PortalMetadata.CustomMetadataEntry link

RedirectAction link

Return a redirect response to the downstream client.

RouteTableReport link

The resources that the applied route table selects.

RouteTableReport.AppliedRoutePoliciesEntry link

RouteTableReport.DelegatedRouteTableReference link

A list of routes delegated to by delegated routes in this route table. Only tracks direct delegates of this route table; delegates of delegate routes are not included.

RouteTableReport.WorkspacesEntry link

RouteTableSpec link

Specifications for the RouteTable resource.

RouteTableStatus link

RouteTableStatus.NumAppliedRoutePoliciesEntry link

TCPRoute link

Use TCP routes to control lower-level, connection-based traffic to services such as a local database. TCP routes are available only for internal traffic within the cluster, not for ingress gateway traffic. To configure TCP routes, you pair together TCP request matchers with certain actions. Matchers are criteria, such as a port, to match with an incoming request. Actions describe what to do with a matching request, such as forwardTo a destination.

TLSRoute link

Use TLS routes to route unterminated TLS traffic (TLS/HTTPS) through an ingress gateway or within the cluster, such as for pass-through SNI-routing. You must specify an SNI host in the matcher, and optionally a port on the host.

TLSRoute.TLSForwardToAction link

When a client request matches a route, Gloo forwards the request to the destination that you specify in this forwardTo action.

DelegateAction.SortMethod link

The method by which routes across delegated route tables are sorted.

RedirectAction.RedirectResponseCode link

RouteTableSpec.FailureMode link

The desired behavior when one or more routes in the route table are misconfigured.

Configuration constraints: For delegated child route tables, this field must be empty or unset. This setting is supported only for the parent route table, which controls the behavior for each child route table.