MeshTCPRoute

This policy uses a new policy matching algorithm. Do not combine with TrafficRoute except for the default route-all route, which should be kept.

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

targetRefAllowed kinds
targetRef.kindMesh, MeshSubset, MeshService, MeshServiceSubset
to[].targetRef.kindMeshService
targetRefAllowed kinds
targetRef.kindMesh, MeshGateway, MeshGateway with listener tags
to[].targetRef.kindMesh
targetRefAllowed kinds
targetRef.kindMesh, MeshSubset, MeshService, MeshServiceSubset
to[].targetRef.kindMeshService

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:

  1. spec:
  2. targetRef: # top-level targetRef selects a group of proxies to configure
  3. kind: Mesh|MeshSubset|MeshService|MeshServiceSubset
  4. to:
  5. - targetRef: # targetRef selects a destination (outbound listener)
  6. kind: MeshService
  7. name: backend
  8. rules:
  9. - default: # configuration applied for the matched TCP traffic
  10. 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: Either MeshService or MeshServiceSubset
    • 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.

Interactions with MeshHTTPRoute

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

Examples

Traffic split

You can use MeshTCPRoute to split TCP traffic between services with different tags and implement A/B testing or canary deployments.

Here’s an example of a MeshTCPRoute that splits the traffic from frontend_kuma-demo_svc_8080 to backend_kuma-demo_svc_3001 between versions:

  1. apiVersion: kuma.io/v1alpha1
  2. kind: MeshTCPRoute
  3. metadata:
  4. name: tcp-route-1
  5. namespace: kuma-system
  6. labels:
  7. kuma.io/mesh: default
  8. spec:
  9. targetRef:
  10. kind: MeshService
  11. name: frontend_kuma-demo_svc_8080
  12. to:
  13. - targetRef:
  14. kind: MeshService
  15. name: backend_kuma-demo_svc_3001
  16. rules:
  17. - default:
  18. backendRefs:
  19. - kind: MeshServiceSubset
  20. name: backend_kuma-demo_svc_3001
  21. tags:
  22. version: "v0"
  23. weight: 90
  24. - kind: MeshServiceSubset
  25. name: backend_kuma-demo_svc_3001
  26. tags:
  27. version: "v1"
  28. weight: 10

You can apply the configuration with kubectl apply -f [..].

  1. type: MeshTCPRoute
  2. name: tcp-route-1
  3. mesh: default
  4. spec:
  5. targetRef:
  6. kind: MeshService
  7. name: frontend_kuma-demo_svc_8080
  8. to:
  9. - targetRef:
  10. kind: MeshService
  11. name: backend_kuma-demo_svc_3001
  12. rules:
  13. - default:
  14. backendRefs:
  15. - kind: MeshServiceSubset
  16. name: backend_kuma-demo_svc_3001
  17. tags:
  18. version: "v0"
  19. weight: 90
  20. - kind: MeshServiceSubset
  21. name: backend_kuma-demo_svc_3001
  22. tags:
  23. version: "v1"
  24. weight: 10

You can apply the configuration with kumactl apply -f [..] or use the HTTP API.

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:

  1. apiVersion: kuma.io/v1alpha1
  2. kind: MeshTCPRoute
  3. metadata:
  4. name: tcp-route-1
  5. namespace: kuma-system
  6. labels:
  7. kuma.io/mesh: default
  8. spec:
  9. targetRef:
  10. kind: MeshService
  11. name: frontend_kuma-demo_svc_8080
  12. to:
  13. - targetRef:
  14. kind: MeshService
  15. name: backend_kuma-demo_svc_3001
  16. rules:
  17. - default:
  18. backendRefs:
  19. - kind: MeshService
  20. name: external-backend

You can apply the configuration with kubectl apply -f [..].

  1. type: MeshTCPRoute
  2. name: tcp-route-1
  3. mesh: default
  4. spec:
  5. targetRef:
  6. kind: MeshService
  7. name: frontend_kuma-demo_svc_8080
  8. to:
  9. - targetRef:
  10. kind: MeshService
  11. name: backend_kuma-demo_svc_3001
  12. rules:
  13. - default:
  14. backendRefs:
  15. - kind: MeshService
  16. name: external-backend

You can apply the configuration with kumactl apply -f [..] or use the HTTP API.

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:

MeshTCPRoute:

  1. # [...]
  2. targetRef:
  3. kind: MeshService
  4. name: frontend
  5. to:
  6. - targetRef:
  7. kind: MeshService
  8. name: backend
  9. rules:
  10. - default:
  11. backendRefs:
  12. - kind: MeshService
  13. name: other-tcp-backend

MeshHTTPRoute:

  1. # [...]
  2. targetRef:
  3. kind: MeshService
  4. name: frontend
  5. to:
  6. - targetRef:
  7. kind: MeshService
  8. name: backend
  9. rules:
  10. - matches:
  11. - path:
  12. type: PathPrefix
  13. value: "/"
  14. default:
  15. backendRefs:
  16. - kind: MeshService
  17. name: other-http-backend

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