Skip to content

TCP routing

Gateway API is designed to work with multiple protocols and TCPRoute is one such route which allows for managing TCP traffic.

In this example, we have one Gateway resource and two TCPRoute resources that distribute the traffic with the following rules:

  • All TCP streams on port 8080 of the Gateway are forwarded to port 6000 of my-foo-service Kubernetes Service.
  • All TCP streams on port 8090 of the Gateway are forwarded to port 6000 of my-bar-service Kubernetes Service.

In this example two TCP listeners will be applied to the Gateway in order to route them to two separate backend TCPRoutes, note that the protocol set for the listeners on the Gateway is TCP:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: Gateway
metadata:
  name: my-tcp-gateway
spec:
  gatewayClassName: my-tcp-gateway-class
  listeners:
  - name: foo
    protocol: TCP
    port: 8080
    allowedRoutes:
      kinds:
      - kind: TCPRoute
  - name: bar
    protocol: TCP
    port: 8090
    allowedRoutes:
      kinds:
      - kind: TCPRoute
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
  name: tcp-app-1
spec:
  parentRefs:
  - name: my-tcp-gateway
    sectionName: foo
  rules:
  - backendRefs:
    - name: my-foo-service
      port: 6000
---
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
  name: tcp-app-2
spec:
  parentRefs:
  - name: my-tcp-gateway
    sectionName: bar
  rules:
  - backendRefs:
    - name: my-bar-service
      port: 6000

In the above example we separate the traffic for the two separate backend TCP Services by using the sectionName field in the parentRefs:

spec:
  parentRefs:
  - name: my-tcp-gateway
    sectionName: foo

This corresponds directly with the name in the listeners in the Gateway:

  listeners:
  - name: foo
    protocol: TCP
    port: 8080
  - name: bar
    protocol: TCP
    port: 8090

In this way each TCPRoute "attaches" itself to a different port on the Gateway so that the service my-foo-service is taking traffic for port 8080 from outside the cluster and my-bar-service takes the port 8090 traffic.

Alternatives: Routing Using Traffic Matching

Experimental Channel

This functionality is currently only included in the "Experimental" channel of Gateway API. For more information on release channels, refer to the related documentation.

In addition to simply matching traffic based on a Gateway's listeners (as seen in the above examples) a TCPRoute can also match further on the traffic bound for that listener:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
  name: traffic-matching-example
spec:
  rules:
  - matches:
    - sourceAddresses:
      - value: "192.168.1.1"
      - value: "FE80::0202:B3FF:FE1E:8329"
      destinationAddresses:
      - value: "10.96.0.1"
    backendRefs:
    - name: my-service
      port: 8080

In the above example the matches option for the TCPRoute rules enables the route to only serve the traffic that matches specified destination and/or source address patterns. In this way separate TCPRoute objects can be responsible for routing different traffic on the same Gateway listener and can enable significant flexibility for pure TCP routing.

Back to top