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

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

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.

FieldDescription
routeTables(repeated common.gloo.solo.io.ObjectSelector)

Delegate to the route tables that match the given selectors. Selected route tables are ordered by creation time stamp in ascending order. Route tables are selected from both the tables defined within the current workspace and any tables imported into the workspace.
allowedRoutes(repeated common.gloo.solo.io.RouteFilter)

Optional: Restrict delegation to the route tables that match the set of route filter criteria specified. If omitted, any route can be referenced by this route table.
sortMethod(DelegateAction.SortMethod)

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

DirectResponseAction

Respond directly to the client from the proxy.

FieldDescription
status(uint32)

The HTTP response status code to return.

Configuration constraints:
  • This field is required.
  • The value must be 200 - 599, inclusive.
body(string)

The content of the response body. If omitted, no body is included in the generated response.

Configuration constraints: Must be less than 1MB in size.

ForwardToAction

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

FieldDescription
destinations(repeated common.gloo.solo.io.DestinationReference)

Define the upstream destination to route the request to. Some destinations require additional configuration for the route. For example, to forward requests to a CloudProvider for an AWS Lambda, you must also set a function. HTTP routes support all destinations types. TCP routes support only Kubernetes services and Gloo VirtualDestinations.

Configuration constraints:
  • If defaultDestination is empty, you must specify at least one destination in this field.
  • You can optionally specify a destination weight to indicate the proportion of traffic to forward to this destination. Weights across all destinations must sum to 100. If the sum is less than 100, the remainder is distributed across destinations that do not specify a weight, with a minimum of 1 weight per destination. Destination weight examples:
    • Valid example: Port 80 specifies a weight of 50, port 81 a weight of 25, and port 82 a weight of 25. All weights equal 100. 50% of traffic is forwarded to port 80, 25% to 81, and 25% to 82.
    • Valid example: Port 80 specifies a weight of 50, port 81 a weight of 25, and port 82 does not specify a weight. All weights equal 75, and the remaining 25% is assigned to port 82.
    • Invalid example: Port 80 specifies a weight of 50, port 81 a weight of 50, and port 82 a weight of 25. All weights equal 125.
    • Invalid example: Port 80 specifies a weight of 50, port 81 a weight of 50, and port 82 does not specify a weight. All weights equal 100, but no remainder exists for port 82.
pathRewrite(string)

Replace the path specified in the matcher with this value before forwarding the request to the upstream destination. When a prefix matcher is used, only the prefix portion of the path is rewritten. When an exact matcher is used, the whole path is replaced. Rewriting the path when a regex matcher is used is currently unsupported. Note that path rewrites are available for HTTP routes only and are not supported for TCP routes.
regexRewrite(envoy.type.matcher.v3.RegexMatchAndSubstitute)

During forwarding, portions of the path that match the pattern are rewritten, even allowing the substitution of capture groups from the pattern into the new path as specified by the rewrite substitution string. This substitution is useful to allow application paths to be rewritten in a way that is aware of segments with variable content like identifiers. Note that regex rewrites are available for RE2 syntax and HTTP routes only.

Configuration constraints: The value must follow a valid RE2 regex pattern.
hostRewrite(string)

Replace the Authority/Host header with this value before forwarding the request to the upstream destination.

Configuration constraints:
  • Supported for HTTP routes only. Unsupported for TCP routes.
  • Hostnames must be 1 - 255 characters in length.
  • Supported characters are a-z, A-Z, 0-9, -, and ..
  • Each segment separated by a period (.) must be 1 - 63 characters in length and cannot start with the - character.
autoHostRewrite(bool)

Automatically replace the Authority/Host header with the hostname of the upstream destination. Note that host rewrites are available for HTTP routes only and are not supported for TCP routes.

GraphQLAction

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.

FieldDescription
schema(core.skv2.solo.io.ClusterObjectRef)

Reference to a GraphQLSchema resource that contains the configuration for this subschema.
stitchedSchema(core.skv2.solo.io.ClusterObjectRef)

Reference to a GraphQLStitchedSchema resource that contains the configuration for this subschema.
options(GraphQLAction.Options)

Options that apply to this GraphQL Schema.

GraphQLAction.Options

FieldDescription
logSensitiveInfo(google.protobuf.BoolValue)

Include information about request/response in the envoy debug logs. This is helpful for debugging GraphQL. Defaults to false.

HTTPRoute

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.

FieldDescription
name(string)

Unique name of the route within the route table. This name is used to identify the route in metrics collection.

Configuration constraints:
  • If the value begins with the prefix insecure-, this prefix is trimmed.
  • The value must be unique to other routes that are listed in the http section of this route table. If it is not unique, it is renamed to duplicate-<previous-name>-<increment>, such as duplicate-myname-1.
labels(repeated HTTPRoute.LabelsEntry)

Labels for the route, which you can use to apply policies that support routeSelectors.
For enhanced security, include the special label gateway.gloo.solo.io/require_auth=true on the route. To activate this security feature, enable the gatewayDefaultDenyAllHTTPRequests feature flag for your Gloo installation. When both the label and feature flag are in place, Gloo requires an authentication policy, such as ExtAuthPolicy or JWTPolicy, to be applied to the route. If the authentication policy is removed or has an error, Gloo rejects all requests to the route.
For more information about the value format, see Syntax and character set in the Kubernetes docs.

Configuration constraints:
  • Key constraints:
    • Cannot be empty
    • Must have two segments separated by a slash (/)
    • First segment constraints:
      • Cannot be empty
      • Max length of 253 characters
      • Supported characters include a-z, A-Z, 0-9, -, and .
    • Second segment constraints:
      • Cannot be empty
      • Max length of 63 characters
      • Must begin and end with an alphanumeric character (a-z, A-Z, or 0-9)
      • Supported characters include a-z, A-Z, 0-9, -, _, and .
  • Value constraints:
    • Can be empty
    • Max length of 63 characters
    • Unless empty, must begin and end with an alphanumeric character (a-z, A-Z, or 0-9)
    • Supported characters include a-z, A-Z, 0-9, -, _, and .
matchers(repeated common.gloo.solo.io.HTTPRequestMatcher)

Request matchers that this route matches on. If none are specified, the route matches any HTTP traffic. For delegated child route tables, this route matches only traffic that includes both the parent and child’s matchers. If these matchers conflict, the delegating route on the parent table is replaced with a directResponse that indicates the misconfiguration.
forwardTo(ForwardToAction)

Forward traffic to one or more destination services.
delegate(DelegateAction)

Delegate routing decisions to one or more HTTP route tables.
redirect(RedirectAction)

Return a redirect response to the downstream client.
directResponse(DirectResponseAction)

Respond directly to the client from the proxy.
graphql(GraphQLAction)

Handle the HTTP request as a GraphQL request, including query validation and execution of the GraphQL request.

HTTPRoute.LabelsEntry

FieldDescription
key(string)

value(string)

RedirectAction

Return a redirect response to the downstream client.

FieldDescription
hostRedirect(string)

The host portion of the URL is swapped with this value.

Configuration constraints:
  • Hostnames must be 1 - 255 characters in length
  • Supported characters are a-z, A-Z, 0-9, -, and ..
  • Each segment separated by a period (.) must be 1 - 63 characters in length and cannot start with the - character.
pathRedirect(string)

The entire path portion of the URL is overwritten with this value.
responseCode(RedirectAction.RedirectResponseCode)

The HTTP status code to use in the redirect response. The default response code is MOVED_PERMANENTLY (301).

RouteTableReport

The resources that the applied route table selects.

FieldDescription
workspaces(repeated RouteTableReport.WorkspacesEntry)

A list of workspaces in which the route table can be applied.
appliedRoutePolicies(repeated RouteTableReport.AppliedRoutePoliciesEntry)

A map of policy GVK to policy references for all policies that are applied on this resource.
parentRouteTables(repeated common.gloo.solo.io.ObjectReference)

A list of the parents route tables for this route table, if it is a delegated route table.
ownerWorkspace(string)

The name of the workspace that owns the route table.
allowedVirtualGateways(repeated common.gloo.solo.io.ObjectReference)

A list of allowed virtual gateways that this route table can select.
delegatedToRouteTables(repeated RouteTableReport.DelegatedRouteTableReference)

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.AppliedRoutePoliciesEntry

FieldDescription
key(string)

value(common.gloo.solo.io.AppliedRoutePolicies)

RouteTableReport.DelegatedRouteTableReference

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.

FieldDescription
routeIndex(int32)

The index of the route in the parent route table that delegates to the listed route table.
routeTable(common.gloo.solo.io.ObjectReference)

The reference to the route table being delegated to by the parent route table.

RouteTableReport.WorkspacesEntry

FieldDescription
key(string)

value(common.gloo.solo.io.Report)

RouteTableSpec

Specifications for the RouteTable resource.

FieldDescription
hosts(repeated string)

Optional: One or more hosts for which this route table routes traffic. To avoid potential misconfigurations, fully qualified domain names are recommended instead of short names.

Configuration constraints:
  • For regular (non-delegated) route tables, this field is required and must specify at least one host.
  • For delegated child route tables, this field must be empty or unset.
  • Wildcards (*) are supported only for the left-most segment. Full wildcards ("*") are not supported. For example, *.foo.com, *bar.foo.com, and *-bar.foo.com are valid; bar.*.com, bar*.foo.com, bar.foo.*, and * are invalid.
  • Each hostname must follow these requirements:
    • Hostnames must be 1 - 255 characters in length.
    • The hostname cannot be an empty string.
    • Supported characters are a-z, A-Z, 0-9, -, and ..
    • Each segment separated by a period (.) must be 1 - 63 characters in length and cannot start with the - character.
    • Each segment must meet the regex ^[a-zA-Z0-9](?:[-a-zA-Z0-9]*[a-zA-Z0-9])?$.
    • The top-level domain (last segment), such as com in www.example.com, cannot be all numeric characters.
    • The top-level domain (last segment) can be empty, such as "istio.io.".
virtualGateways(repeated common.gloo.solo.io.ObjectReference)

Optional: A list of virtual gateways that serve this route table. When not specified, the route table applies either to all sidecars in the workspace or only to sidecars for selected workloads (via the workloadSelectors field) in the workspace where the route table is deployed or imported.

Examples:
  • The following applies to sidecars of all the workloads for the workspace where the route table is deployed or imported: set virtualGateways to null and workloadSelectors to [].
  • The following applies to the my-gateway virtual gateway in the gateway workspace and no sidecars: set virtualGateways.name to my-gateway, virtualGateways.namespace to gateway, and workloadSelectors to [].
  • The following applies to the my-gateway virtual gateway in the gateway workspace and sidecars of all the workloads for the workspace where the route table is deployed or imported: set virtualGateways.name to my-gateway, virtualGateways.namespace to gateway, and workloadSelectors to {}.
  • The following applies to sidecars of all the app: foo workloads for the workspace where the route table is deployed or imported: set virtualGateways to null and workloadSelectors.selector.labels to app: foo.
  • The following applies to the my-gateway virtual gateway in the gateway workspace and sidecars of all the app: foo workloads for the workspace where the route table is deployed or imported: set virtualGateways.name to my-gateway, virtualGateways.namespace to gateway, and workloadSelectors.selector.labels to app: foo.


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.
workloadSelectors(repeated common.gloo.solo.io.WorkloadSelector)

Optional: Selectors for source workloads (with sidecars) that route traffic for this route table.

Implementation notes:
  • You can specify workload selectors only for east-west routing. Workload selectors do not apply to ingress (north-south) routing.
  • If do not specify virtual gateways or workload selectors, all workloads in the workspace are selected for east-west routing by default.
  • If you specify a virtual gateway, workloads are not automatically selected for east-west routing. To make them also available for east-west routing, configure this workloadSelectors option to select the workloads that you want, such as {} for all workloads in the workspace.
  • Selecting external workloads, such as VMs, is currently not supported.
  • You can select workloads by using labels only. Selecting workloads by using other references, such as the name, namespace, cluster or workspace, is not supported.
  • Delegated child route tables inherit the workload selectors of the parent route table, such as value:foo. The delegated child route table can also have its own workload selectors, such as env:prod. These workload selectors are logically AND’d together. As a result, the child route table routes traffic only to workloads with both value:foo and env:prod labels. Note that the child route table cannot override the parent’s workload selectors, such as by setting value:bar. In that case, the child route gets an error until the conflict is resolved.

Configuration constraints: If this field is set, workloadSelectors.kind must be set to KUBE, and workloadSelectors.selector.name, .namespace, .cluster, and .workspace must be empty.
applyToDestinations(repeated common.gloo.solo.io.DestinationSelector)

Optional: Selectors for destinations that route traffic for this route table via a producer-side policy, such as on waypoint proxies.

Implementation notes: Selecting external workloads (such as VMs), external services, or destinations with sidecars is currently not supported.

Configuration constraints:
  • If this field is set, applyToDestinations.kind must be set to KUBE.
  • For delegated child route tables, this field must be empty or unset. The values from the parent route table are always used for destination selection.
defaultDestination(common.gloo.solo.io.DestinationReference)

Optional: Routes that do not specify a destination forward traffic to this destination. This field applies only to forwardTo routes.

Configuration constraints: If you define a http.forwardTo, tcp.forwardTo, or tls.forwardTo action that does not specify at least one destination, you must set this field.
http(repeated HTTPRoute)

The HTTP routes that this route table serves. If no routes match the client request, the client receives a 404 error code. For more information on supported HTTP features, see the Routing overview concept docs.

Configuration constraints: At least one of http, tcp, or tls must be set.
tcp(repeated TCPRoute)

The TCP routes that this route table serves. TCP routes are available only for internal traffic within the cluster, not for ingress gateway traffic. For more information on supported TCP features, see the Routing overview concept docs.

Configuration constraints: At least one of http, tcp, or tls must be set.
tls(repeated TLSRoute)

The TLS routes that this route table serves. For more information on supported TLS features, see the Routing overview concept docs.

Configuration constraints: At least one of http, tcp, or tls must be set.
weight(int32)

Weight is used to sort delegated route tables by priority. Higher integer values indicate a higher priority. 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 request is sent to a service in your Gloo setup, 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.

For example, if you have two sub-tables with weights of 100 and 90, Gloo will attempt to match a request against the routes in the sub-table with the weight of 100 first. If the request does not match, Gloo then attempts to match the request against the routes in the sub-table with the weight of 90.

Note that tables of the same weight stay in the same order that you list them in the parent 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.

The default value is 0.
portalMetadata(common.gloo.solo.io.PortalMetadata)

Optional: If this route table bundles APIs that you want to expose in a developer portal, you can set portal metadata. Portal metadata is a set of key-value pairs that describe your APIs. Later, your developer portal displays this information in the end-user facing API documentation.
failureMode(RouteTableSpec.FailureMode)

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.
virtualServiceAnnotations(repeated RouteTableSpec.VirtualServiceAnnotationsEntry)

Annotations to add to the metadata of the VirtualService generated by this RouteTable.

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 VirtualService that corresponds to all child route tables.
  • Designated annotation keys that might already be in use on the VirtualService, such as “cluster.solo.io/cluster”, are not supported.

RouteTableSpec.VirtualServiceAnnotationsEntry

FieldDescription
key(string)

value(string)

RouteTableStatus

FieldDescription
common(common.gloo.solo.io.Status)

The state and workspace conditions of the applied resource.
numAppliedRoutePolicies(repeated RouteTableStatus.NumAppliedRoutePoliciesEntry)

A map of policy GVK to the number of policies that are applied on this resource, sorted by GVK.
numParentRouteTables(uint32)

The number of parent route tables for this route table, if it is a delegated route table.
ownedByWorkspace(string)

The name of the workspace that this route table belongs to.
numAllowedVirtualGateways(uint32)

The number virtual gateways that this route table can select.

RouteTableStatus.NumAppliedRoutePoliciesEntry

FieldDescription
key(string)

value(uint32)

TCPRoute

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.

FieldDescription
matchers(repeated common.gloo.solo.io.TCPRequestMatcher)

The set of request matchers for this route to match on.
forwardTo(ForwardToAction)

Forward traffic to one or more destination services. Note that some forwardTo actions, such as path or host rewrite, are not supported for TCP routes.

Configuration constraints: This field is required, and you must specify at least one destination.

TLSRoute

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.

FieldDescription
matchers(repeated common.gloo.solo.io.TLSRequestMatcher)

The set of request matchers for this route to match on.
forwardTo(TLSRoute.TLSForwardToAction)

Forward traffic to one or more destination services.

Configuration constraints: This field is required.

TLSRoute.TLSForwardToAction

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

FieldDescription
destinations(repeated common.gloo.solo.io.DestinationReference)

Define the upstream destination to route the request to.

Configuration constraints:
  • If defaultDestination is empty, you must specify at least one destination in this field.
  • You can optionally specify a destination weight to indicate the proportion of traffic to forward to this destination. Weights across all destinations must sum to 100. If the sum is less than 100, the remainder is distributed across destinations that do not specify a weight, with a minimum of 1 weight per destination. Destination weight examples:
    • Valid example: Port 80 specifies a weight of 50, port 81 a weight of 25, and port 82 a weight of 25. All weights equal 100. 50% of traffic is forwarded to port 80, 25% to 81, and 25% to 82.
    • Valid example: Port 80 specifies a weight of 50, port 81 a weight of 25, and port 82 does not specify a weight. All weights equal 75, and the remaining 25% is assigned to port 82.
    • Invalid example: Port 80 specifies a weight of 50, port 81 a weight of 50, and port 82 a weight of 25. All weights equal 125.
    • Invalid example: Port 80 specifies a weight of 50, port 81 a weight of 50, and port 82 does not specify a weight. All weights equal 100, but no remainder exists for port 82.

DelegateAction.SortMethod

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

NameNumberDescription
TABLE_WEIGHT0Routes are kept in the order that they appear relative to their tables, but tables are sorted by weight. Tables that have the same weight stay in the same order that they are listed in, which is the list order when given as a reference and by creation timestamp when selected.
ROUTE_SPECIFICITY1After processing all routes, including additional route tables delegated to, the resulting routes are sorted by specificity to reduce the chance that a more specific route will be short-circuited by a general route. Matchers with exact path matchers are considered more specific than regex path patchers, which are more specific than prefix path matchers. For prefix and exact, matchers of the same type are sorted by length of the path in descending order. For regex matchers they are all treated equal when sorted. For sort ties, table weights are used across tables & within tables user specified order is preserved. Only the most specific matcher on each route is used.
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 in case of sort ties:
  • 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

RedirectAction.RedirectResponseCode

NameNumberDescription
MOVED_PERMANENTLY0Moved Permanently HTTP Status Code - 301.
FOUND1Found HTTP Status Code - 302.
SEE_OTHER2See Other HTTP Status Code - 303.
TEMPORARY_REDIRECT3Temporary Redirect HTTP Status Code - 307.
PERMANENT_REDIRECT4Permanent Redirect HTTP Status Code - 308.

RouteTableSpec.FailureMode

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.

NameNumberDescription
ROUTE_REPLACEMENT0The default behavior for handling misconfigured routes in a route table. If you attempt to apply incorrect configuration to a route, the configuration is not applied in the cluster. Instead, the misconfigured route is replaced with a 500 HTTP direct response until the error is resolved. Other, correctly configured routes in the route table continue to route as configured and accept updates to their configuration.
FREEZE_CONFIG1If you attempt to apply incorrect configuration to a route, the configuration is not accepted and the route table continues to serve the route configuration from the last accepted configuration. Other, correctly configured routes in the route table also continue to serve the last accepted configuration. Updates to correctly configured routes are ignored until the error is resolved. Note that the same behavior applies when using route delegation; any misconfigured route on the parent route table or any child route table freezes the configuration for all routes in the route table tree until the error is resolved. Keep in mind that if you change the failure mode from ROUTE_REPLACEMENT to FREEZE_CONFIG while a route is in a misconfigured state, any replaced routes will maintain their 500 HTTP direct response as that is their behavior in the last accepted configuration.