Kuma Star

MeshTCPRoute

This policy uses new policy matching algorithm. It’s recommended to migrate from TrafficRoute. See “Interactions with TrafficRoute” section for more information.

The MeshTCPRoute policy allows you to alter and redirect TCP requests depending on where the request is coming from and where it’s going to.

TargetRef support matrix

targetRef Allowed kinds
targetRef.kind Mesh, MeshSubset
to[].targetRef.kind MeshService

For more information, see the matching docs.

Configuration

Unlike other outbound policies, MeshTCPRoute doesn’t contain default directly in the to array. The default section is nested inside rules, so the policy structure looks like the following:

spec:
  targetRef: # top-level targetRef selects a group of proxies to configure
    kind: Mesh|MeshSubset|MeshService|MeshServiceSubset 
  to:
    - targetRef: # targetRef selects a destination (outbound listener)
        kind: MeshService
        name: backend
      rules:
        - default: # configuration applied for the matched TCP traffic
            backendRefs: [...]

Default configuration

The following describes the default configuration settings of the MeshTCPRoute policy:

  • backendRefs: (Optional) List of destinations for the request to be redirected to
    • kind: One of MeshService, MeshServiceSubset, MeshExtenalService
    • name: The service name
    • tags: Service tags. These must be specified if the kind is MeshServiceSubset.
    • weight: When a request matches the route, the choice of an upstream cluster is determined by its weight. Total weight is a sum of all weights in the backendRefs list.

Gateways

In order to route TCP traffic for a MeshGateway, you need to target the MeshGateway in spec.targetRef and set spec.to[].targetRef.kind: Mesh.

Interactions with MeshHTTPRoute

MeshHTTPRoute takes priority over MeshTCPRoute when both are defined for the same service, and the matching MeshTCPRoute is ignored.

Interactions with TrafficRoute

MeshTCPRoute takes priority over TrafficRoute when a proxy is targeted by both policies.

All legacy policies like Retry, TrafficLog, Timeout etc. only match on routes defined by TrafficRoute. All new recommended policies like MeshRetry, MeshAccessLog, MeshTimeout etc. match on routes defined by MeshTCPRoute and TrafficRoute.

If you don’t use legacy policies, it’s recommended to remove any existing TrafficRoute. Otherwise, it’s recommended to migrate to new policies and then removing TrafficRoute.

Examples

Traffic split

We can use MeshTCPRoute to split an TCP traffic between different MeshServices implementing A/B testing or canary deployments. If we want to split traffic between v1 and v2 versions of the same service, first we have to create MeshServices backend-v1 and backend-v2 that select backend application instances according to the version.

apiVersion: kuma.io/v1alpha1
kind: MeshTCPRoute
metadata:
  name: tcp-route-1
  namespace: kuma-demo
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: MeshSubset
    tags:
      app: frontend
  to:
  - targetRef:
      kind: MeshService
      name: backend_kuma-demo_svc_3001
    rules:
    - default:
        backendRefs:
        - kind: MeshServiceSubset
          name: backend_kuma-demo_svc_3001
          weight: 90
          tags:
            version: v0
        - kind: MeshServiceSubset
          name: backend_kuma-demo_svc_3001
          weight: 10
          tags:
            version: v1

apiVersion: kuma.io/v1alpha1
kind: MeshTCPRoute
metadata:
  name: tcp-route-1
  namespace: kuma-demo
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: MeshSubset
    tags:
      app: frontend
  to:
  - targetRef:
      kind: MeshService
      name: backend
      namespace: kuma-demo
      sectionName: http
    rules:
    - default:
        backendRefs:
        - kind: MeshService
          name: backend-v0
          namespace: kuma-demo
          port: 3001
          weight: 90
        - kind: MeshService
          name: backend-v1
          namespace: kuma-demo
          port: 3001
          weight: 10

Traffic redirection

You can use MeshTCPRoute to redirect outgoing traffic from one service to another.

Here’s an example of a MeshTCPRoute that redirects outgoing traffic originating at frontend_kuma-demo_svc_8080 from backend_kuma-demo_svc_3001 to external-backend:

apiVersion: kuma.io/v1alpha1
kind: MeshTCPRoute
metadata:
  name: tcp-route-1
  namespace: kuma-demo
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: MeshSubset
    tags:
      app: frontend
  to:
  - targetRef:
      kind: MeshService
      name: backend_kuma-demo_svc_3001
    rules:
    - default:
        backendRefs:
        - kind: MeshService
          name: external-backend_kuma-demo_svc_8080

apiVersion: kuma.io/v1alpha1
kind: MeshTCPRoute
metadata:
  name: tcp-route-1
  namespace: kuma-demo
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: MeshSubset
    tags:
      app: frontend
  to:
  - targetRef:
      kind: MeshService
      name: backend
      namespace: kuma-demo
      sectionName: http
    rules:
    - default:
        backendRefs:
        - kind: MeshService
          name: external-backend
          namespace: kuma-demo
          port: 8080

Route policies with different types targeting the same destination

If multiple route policies with different types (MeshTCPRoute and MeshHTTPRoute for example) target the same destination, only a single route type with the highest specificity will be applied.

In this example, both MeshTCPRoute and MeshHTTPRoute target the same destination:

apiVersion: kuma.io/v1alpha1
kind: MeshHTTPRoute
metadata:
  name: simple-http
  namespace: kuma-demo
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: MeshSubset
    tags:
      app: frontend
  to:
  - targetRef:
      kind: MeshService
      name: backend_kuma-demo_svc_3001
    rules:
    - default:
        backendRefs:
        - kind: MeshService
          name: other-tcp-backend_kuma-demo_svc_8080

apiVersion: kuma.io/v1alpha1
kind: MeshHTTPRoute
metadata:
  name: simple-http
  namespace: kuma-demo
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: MeshSubset
    tags:
      app: frontend
  to:
  - targetRef:
      kind: MeshService
      name: backend
      namespace: kuma-demo
      sectionName: http
    rules:
    - default:
        backendRefs:
        - kind: MeshService
          name: other-tcp-backend
          namespace: kuma-demo
          port: 8080

apiVersion: kuma.io/v1alpha1
kind: MeshHTTPRoute
metadata:
  name: simple-http
  namespace: kuma-demo
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: MeshSubset
    tags:
      app: frontend
  to:
  - targetRef:
      kind: MeshService
      name: backend_kuma-demo_svc_3001
    rules:
    - matches: 
      path:
        type: PathPrefix
        value: "/"
      default:
        backendRefs:
        - kind: MeshService
          name: other-http-backend_kuma-demo_svc_8080

apiVersion: kuma.io/v1alpha1
kind: MeshHTTPRoute
metadata:
  name: simple-http
  namespace: kuma-demo
  labels:
    kuma.io/mesh: default
spec:
  targetRef:
    kind: MeshSubset
    tags:
      app: frontend
  to:
  - targetRef:
      kind: MeshService
      name: backend
      namespace: kuma-demo
      sectionName: http
    rules:
    - matches: 
      path:
        type: PathPrefix
        value: "/"
      default:
        backendRefs:
        - kind: MeshService
          name: other-http-backend
          namespace: kuma-demo
          port: 8080

Depending on the backend’s protocol:

  • MeshHTTPRoute will be applied if http, http2, or grpc are specified
  • MeshTCPRoute will be applied if tcp or kafka is specified, or when nothing is specified

All policy configuration settings