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 , MeshService , MeshServiceSubset |
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 ofMeshService
,MeshServiceSubset
,MeshExtenalService
name
: The service nametags
: Service tags. These must be specified if thekind
isMeshServiceSubset
.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 thebackendRefs
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-system
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: backend-v0_kuma-demo_svc
weight: 90
- kind: MeshService
name: backend-v1_kuma-demo_svc
weight: 10
apiVersion: kuma.io/v1alpha1
kind: MeshTCPRoute
metadata:
name: tcp-route-1
namespace: kuma-system
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-system
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
apiVersion: kuma.io/v1alpha1
kind: MeshTCPRoute
metadata:
name: tcp-route-1
namespace: kuma-system
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:
MeshTCPRoute:
# [...]
targetRef:
kind: MeshSubset
tags:
app: frontend
to:
- targetRef:
kind: MeshService
name: backend
namespace: kuma-demo
_port: 3001
sectionName: http
rules:
- default:
backendRefs:
- kind: MeshService
name: other-tcp-backend
MeshHTTPRoute:
# [...]
targetRef:
kind: MeshSubset
tags:
app: frontend
to:
- targetRef:
kind: MeshService
name: backend
namespace: kuma-demo
_port: 3001
sectionName: http
rules:
- matches:
- path:
type: PathPrefix
value: "/"
default:
backendRefs:
- kind: MeshService
name: other-http-backend
Depending on the backend
’s protocol:
MeshHTTPRoute
will be applied ifhttp
,http2
, orgrpc
are specifiedMeshTCPRoute
will be applied iftcp
orkafka
is specified, or when nothing is specified