User reports for TCPRoute and UDPRoute

[youngnick]

This discussion is for folks who are actively using TCPRoute and UDPRoute. The community would like to know what you're using them for, and how you find the experience?

[pamelia]

I've been collaborating with a client on a project that focuses on secure video meetings. The service leverages WebRTC for real-time communication and incorporates the STUNner project as a WebRTC media gateway, running seamlessly in Kubernetes. STUNner uses Gateway API with UDPRoute for efficient traffic management, which has significantly enhanced scalability and reliability. It's been a fascinating experience working on such cutting-edge technologies to deliver secure and high-performing video communication solutions running natively in Kubernetes.

[LionelJouin]

I investigated Gateway API with TCP and UDP routes for a potential implementation of a Kubernetes Load-Balancer for Telco use-cases.

The first thing I noticed is the port and protocol that must be written in listener (Gateway), ParentReds (Route), BackendRef (Route) and Service. I have had a hard time to understand how the listeners field fits with the Routes on layer 4 (TCP/UDP Route) and potentially lower layers. Is it really required? Maybe a better solution could be to have the possibility to allow any port and any protocol? Here are some related discussion related to this: #130 ; #780 (comment) ; #818 ; #1061

For my use case on telco load-balancer, I would probably also need some kind of SCTP Route. But, in my opinion, a Layer 3 and 4 Route would probably make more sense. The route would match based on Src/Dst IPs and Ports + Protocol, and use some kind of service as a backend which would define the actual endpoints.

Few month ago, I made a PoC in this area, I would be happy to demo what I have to the community if there is an interest: https://github.com/LionelJouin/l-3-4-gateway-api-poc
It is about layer 3 and 4 Routes and (Kubernetes) service decomposition. In this PoC, the Gateway workload is collocated with the service implementation.
The 2 main experiments in this PoC are the following:

1. Service as a Route
   • The Kubernetes service object is considered and used as route + load-balancer (service.kubernetes.io/service-proxy-name indicates in which Gateway the service must be running).
   • It (Kubernetes Service) is considered as a route as we can specify the Port + Protocol + IPs.
   • It (Kubernetes Service) is considered as a load-balancer as we have a selector selecting the endpoints and load-balancing the traffic towards them.
2. Service decomposition: Layer 3/4 Route + Load-Balancer
   • New Route L34Route pointing to a service (backendRefs).
   • The service is a headless service containing only the Selector field (Maybe the service object could contain traffic manipulation fields. E.g. Load-Balancer algorithm, NAT being applied, Port forwarding, ...).

Probably what I said is also related to this discussion: #3351
We (I and some people from SIG-Network) also had some discussion around this topic in the hallway of Kubecon NA.