Configuring built-in routes with MeshHTTPRoute and MeshTCPRoute

Uses: Kong Mesh

To configure how traffic is forwarded from a listener to your mesh services, use MeshHTTPRoute and MeshTCPRoute.

You must use spec.targetRef to target gateway data plane proxies when you use these route resources with a gateway.

When using MeshHTTPRoute and MeshTCPRoute with built-in gateways, spec.to[].targetRef is restricted to kind: Mesh.

MeshHTTPRoute

Here’s an example of a MeshHTTPRoute resource:

Listener hostname

MeshGateway listeners have an optional hostname field that limits the traffic accepted by the listener depending on the protocol:

  • HTTP: Host header must match
  • TLS: SNI must match
  • HTTPS: Both SNI and host must match

When attaching routes to specific listeners, the routes are isolated from each other. If we consider the following listeners:

conf:
  listeners:
  - port: 8080
    protocol: HTTP
    hostname: foo.example.com
    tags:
      hostname: foo
  - port: 8080
    protocol: HTTP
    hostname: *.example.com
    tags:
      hostname: wild

Along with the following MeshHTTPRoute rule:

This route explicitly attaches to the second listener with hostname: *.example.com.

This means that requests to foo.example.com, which match the first listener because it’s more specific, will return a 404 because there are no routes attached for that listener.

Route hostnames

MeshHTTPRoute rules can specify an additional list of hostnames to further limit the traffic handled by those rules. For example:

This route would send all traffic to dev.example.com to the v2 backend, but other traffic to v1.

MeshTCPRoute

If your traffic isn’t HTTP, you can use MeshTCPRoute to balance traffic between services:

Help us make these docs great!

Kong Developer docs are open source. If you find these useful and want to make them better, contribute today!