TCP routing

Experimental Channel

The TCPRoute resource described below is currently only included in the “Experimental” channel of Gateway API. For more information on release channels, refer to our versioning guide.

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:

  1. apiVersion: gateway.networking.k8s.io/v1
  2. kind: Gateway
  3. metadata:
  4.   name: my-tcp-gateway
  5. spec:
  6.   gatewayClassName: my-tcp-gateway-class
  7.   listeners:
  8.   - name: foo
  9.     protocol: TCP
  10.     port: 8080
  11.     allowedRoutes:
  12.       kinds:
  13.       - kind: TCPRoute
  14.   - name: bar
  15.     protocol: TCP
  16.     port: 8090
  17.     allowedRoutes:
  18.       kinds:
  19.       - kind: TCPRoute
  20. ---
  21. apiVersion: gateway.networking.k8s.io/v1alpha2
  22. kind: TCPRoute
  23. metadata:
  24.   name: tcp-app-1
  25. spec:
  26.   parentRefs:
  27.   - name: my-tcp-gateway
  28.     sectionName: foo
  29.   rules:
  30.   - backendRefs:
  31.     - name: my-foo-service
  32.       port: 6000
  33. ---
  34. apiVersion: gateway.networking.k8s.io/v1alpha2
  35. kind: TCPRoute
  36. metadata:
  37.   name: tcp-app-2
  38. spec:
  39.   parentRefs:
  40.   - name: my-tcp-gateway
  41.     sectionName: bar
  42.   rules:
  43.   - backendRefs:
  44.     - name: my-bar-service
  45.       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:

  1. spec:
  2.   parentRefs:
  3.   - name: my-tcp-gateway
  4.     sectionName: foo

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

  1.   listeners:
  2.   - name: foo
  3.     protocol: TCP
  4.     port: 8080
  5.   - name: bar
  6.     protocol: TCP
  7.     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.

Note that you can achieve this same result by binding the Routes to the Gateway listeners using the port field in the parentRefs:

  1. spec:
  2.   parentRefs:
  3.   - name: my-tcp-gateway
  4.     port: 8080

Using the port field instead of sectionName for the attachment has the downside of more tightly coupling the relationship between the Gateway and its associated Routes. Refer to Attaching to Gateways for more details.