MeshTCPRoute (beta)
This policy uses a new policy matching algorithm and is in beta state. It shouldn’t be combined with TrafficRoute.
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 type | top level | to | from |
---|---|---|---|
Mesh | ✅ | ❌ | ❌ |
MeshSubset | ✅ | ❌ | ❌ |
MeshService | ✅ | ✅ | ❌ |
MeshServiceSubset | ✅ | ❌ | ❌ |
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 tokind
: EitherMeshService
orMeshServiceSubset
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.
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:
apiVersion: kuma.io/v1alpha1
kind: MeshTCPRoute
metadata:
name: tcp-route-1
namespace: kuma-system
labels:
kuma.io/mesh: default
spec:
targetRef:
kind: MeshService
name: frontend_kuma-demo_svc_8080
to:
- targetRef:
kind: MeshService
name: backend_kuma-demo_svc_3001
rules:
- default:
backendRefs:
- kind: MeshServiceSubset
name: backend_kuma-demo_svc_3001
tags:
version: "1.0"
weight: 90
- kind: MeshServiceSubset
name: backend_kuma-demo_svc_3001
tags:
version: "2.0"
weight: 10
You can apply the configuration with kubectl apply -f [..]
.
type: MeshTCPRoute
name: tcp-route-1
mesh: default
spec:
targetRef:
kind: MeshService
name: frontend_kuma-demo_svc_8080
to:
- targetRef:
kind: MeshService
name: backend_kuma-demo_svc_3001
rules:
- default:
backendRefs:
- kind: MeshServiceSubset
name: backend_kuma-demo_svc_3001
tags:
version: "1.0"
weight: 90
- kind: MeshServiceSubset
name: backend_kuma-demo_svc_3001
tags:
version: "2.0"
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
:
apiVersion: kuma.io/v1alpha1
kind: MeshTCPRoute
metadata:
name: tcp-route-1
namespace: kuma-system
labels:
kuma.io/mesh: default
spec:
targetRef:
kind: MeshService
name: frontend_kuma-demo_svc_8080
to:
- targetRef:
kind: MeshService
name: backend_kuma-demo_svc_3001
rules:
- default:
backendRefs:
- kind: MeshService
name: external-backend
You can apply the configuration with kubectl apply -f [..]
.
type: MeshTCPRoute
name: tcp-route-1
mesh: default
spec:
targetRef:
kind: MeshService
name: frontend_kuma-demo_svc_8080
to:
- targetRef:
kind: MeshService
name: backend_kuma-demo_svc_3001
rules:
- default:
backendRefs:
- kind: MeshService
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:
# [...]
targetRef:
kind: MeshService
name: frontend
to:
- targetRef:
kind: MeshService
name: backend
rules:
- default:
backendRefs:
- kind: MeshService
name: other-tcp-backend
MeshHTTPRoute:
# [...]
targetRef:
kind: MeshService
name: frontend
to:
- targetRef:
kind: MeshService
name: backend
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