Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is the stunner helm chart compatible with Ingress controllers instead of Gateway API? #53

Open
IanMoroney opened this issue Feb 27, 2025 · 5 comments

Comments

@IanMoroney
Copy link

Referring to #51 which @levaitamas closed a few weeks ago, i'm re-phrasing the original question asked in the previous issue raised.

Is the stunner helm chart compatible with Ingress controllers instead of Gateway API?

The documentation points to the creation of a GatewayClass, GatewayConfig, and one or more Gateway resources, which are all from gateway.networking.k8s.io, and finally a UDPRoute or TCPRoute from stunner.l7mp.io.

However, in AWS, the deployment of Gateway API requires AWS VPC Lattice, and I have neither deployed.

I have an existing NLB i'd like to use via the nginx ingress controller which is already in place (and for example I can target a specific load balancer using an Ingress resource with className: myIngressClassName).

So, in a scenario where I already have load balancers deployed, I can target them via an Ingress, can I use the stunner helm chart to use those Ingress resources instead of gateway resources?

@rg0now
Copy link
Member

rg0now commented Feb 27, 2025

Just to make sure that I understand the question: there are some issues on AWS that prevent the installation of a set of CRDs? What is that stops you from deploying the Gateway API? If the Gateway API CRDs are already deployed, you can skip installation by using the --skip-crds Helm option, would this work? Sorry for my negligence, I try to avoid AWS services.

For clarification: The Gateway API is just a set of Kubernetes resource definitions we use to describe the WebRTC ingestion logics. STUNner absolutely depends on it unless you want to manually configure the dataplane pods (some people do this), Ingress will not work. The Gateway API is however completely independent of the LoadBalancer integration in your cluster: STUNner tries to create a Kubernetes LoadBalancer for convenience but you can easily skip this and manually deploy your own LoadBalancer Service or rely on NodePorts if you want. Would that work?

As per nginx: you can use nginx to proxy ingress traffic to STUNner but you will have to find a clever configuration for UDP because by default nginx does not implement stateful conntrack in the UDP proxy and every client packet coming from a new source port will confuse STUNner. Envoy works though.

@IanMoroney
Copy link
Author

Thank you, this is great information!
The primary issue is that AWS does not have a native Gateway API implementation, i.e. it doesn't spin up a L7 load balancer when requesting a Gateway resource. It uses another service called AWS VPC Lattice which has a separate pricing structure.
The idea was to use the load balancers we already have provisioned, which use nginx ingress.

So the starting point for us would be "I already have load balancers deployed, how do I deploy STUNner now?"

If instead of using nginx, i just need to deploy an Envoy ingress and configure STUNner to use that, that's totally fine.
I'd just like to understand what a deployment like that would look like as far as STUNner is concerned.

@rg0now
Copy link
Member

rg0now commented Feb 27, 2025

The primary issue is that AWS does not have a native Gateway API implementation, i.e. it doesn't spin up a L7 load balancer when requesting a Gateway resource.

Don't worry, STUNner does not need a "native Gateway API implementation", it handles the Gateway API itself. It does not rely on the cloud-provider to "spin up a L7 load balancer when requesting a Gateway resource" either, it will create the LB Service on its own (this assumes your Kubernetes load-balancer integration works). Or you can configure STUNner to create a NodePort Service for your Gateways if you want, or disable automatic Gateway exposition all together and configure the external service yourself.

@IanMoroney
Copy link
Author

Or you can configure STUNner to create a NodePort Service for your Gateways if you want, or disable automatic Gateway exposition all together and configure the external service yourself.

Is there an example or documentation for how to deploy STUNner in this way?

@rg0now
Copy link
Member

rg0now commented Feb 28, 2025

I'm afraid you'll have to read the reference and run through the examples. Here is the specific documentation for tweaking the LB Service STUNner creates per Gateway. We're happy to answer simple questions at our Discord too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants