-
Notifications
You must be signed in to change notification settings - Fork 20
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
Comments
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 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. |
Thank you, this is great information! 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. |
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. |
Is there an example or documentation for how to deploy STUNner in this way? |
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 moreGateway
resources, which are all fromgateway.networking.k8s.io
, and finally aUDPRoute
orTCPRoute
fromstunner.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?
The text was updated successfully, but these errors were encountered: