Specifying the LoadBalancer about stunner

[nmate]

Hi! Which type of LB do you use? Klipper or Hetzner LB? Are there any other logs available? Klipper should use host ports and stunner fallbacks to nodePort if LB service cannot be created. So it shall work with Klipper.

[Biacode]

Hi! Which type of LB do you use? Klipper or Hetzner LB? Are there any other logs available? Klipper should use host ports and stunner fallbacks to nodePort if LB service cannot be created. So it shall work with Klipper.

I use Hetzner LB.
I even tried with a different k8s distribution like this one. So far, no success. I cannot observe any LB created in the Hetzner dashboard in this distribution.
I see this pending state in the k8s cluster. See the image attached.

[Biacode]

My understanding is I need to customize LB settings for The Gateway resource.
If so, any idea how can I achieve this?
I believe you need to provide the following annotations for the Hetzner cloud.

    "load-balancer.hetzner.cloud/name": "stunner"
    "load-balancer.hetzner.cloud/hostname": "example.com"
    "load-balancer.hetzner.cloud/use-private-ip": "true"
    "load-balancer.hetzner.cloud/disable-private-ingress": "true"
    "load-balancer.hetzner.cloud/location": "nbg1"
    "load-balancer.hetzner.cloud/type": "lb11"
    "load-balancer.hetzner.cloud/uses-proxyprotocol": "true"

Any chance I can create the LB using those configurations?

[Biacode]

UPDATE: I managed to have a "healthy" load balancer. See the image below.
The issue is that the Hetzner LB doesn't support UDP, so instead, I ended up having only TCP.
After this, I noticed that my stream was almost unwatchable. TCP issue, I believe. Even though the stunner re-forwards the TCP port to UDP, I think it still uses TCP from Client to Stunner. Am I right?

[nmate]

Great to hear that it became healthy! I would need to check the stunner config to be able to figure out what happens now. Stunner supports TCP afaik, but it is useless for media. Could you share the content of the stunnerd configmap? You can contact me on Discord if its confidential. Btw, may I ask why don't you just switch LB?

[Biacode]

Stunner supports TCP afaik

Can we confirm if this is the case? Because I do stream a media. Which won't be the best experience using TCP.

Btw, may I ask why don't you just switch LB?

To be honest, I would love to :)
Not sure how to do that or to what LB to switch.

You can contact me on Discord if its confidential.

I would love to catch-up on Discord. How can I find you?

[levaitamas]

I would love to catch-up on Discord. How can I find you?

Hey @Biacode! You can join here: https://discord.gg/DyPgEsbwzc

[rg0now]

Even though the stunner re-forwards the TCP port to UDP, I think it still uses TCP from Client to Stunner. Am I right?
Yes, this is right.

I agree, this is definitely a "RTP over TCP sux" issue. Nevertheless, I find that most of the time TCP can still provide a decent media experience unless the Internet connection is extremely poor, can it be the case that there is a crowded Wifi or a 3G mobile uplink somewhere in the media path?

My understanding is I need to customize LB settings for The Gateway resource.
If so, any idea how can I achieve this?
I believe you need to provide the following annotations for the Hetzner cloud.

You can set the annotations you want STUNner to add to the LB services it creates in the GatewayConfig spec.loadBalancerServiceAnnotations field. We plan to make this Gateway specific in a later release.

If we are at it, can you share a few words about your use case? We'd be delighted to learn how/why you find STUNner useful in your WebRTC endeavors (if at all...:-)).

[Biacode]

I agree, this is definitely a "RTP over TCP sux" issue. Nevertheless, I find that most of the time TCP can still provide a decent media experience unless the Internet connection is extremely poor, can it be the case that there is a crowded Wifi or a 3G mobile uplink somewhere in the media path?

No, nothing like crowded wifi or 3G mobile. My use case works perfectly fine with a UDP or let's say non K8S setup.
So I guess this is the issue with forwarding traffic through LB and using TCP combination.

You can set the annotations you want STUNner to add to the LB services it creates in the GatewayConfig spec.loadBalancerServiceAnnotations field. We plan to make this Gateway specific in a later release.

That helps. Thanks. I guess I will stop using stunner since TCP is not my solution.

If we are at it, can you share a few words about your use case? We'd be delighted to learn how/why you find STUNner useful in your WebRTC endeavors (if at all...:-)).

I need to stream/capture desktop content in real-time.

[levaitamas]

I use the Hetzner cloud with this automation tool to deploy the k8s cluster.
Whenever I deploy the stunner UDPRoute, it creates a new LB, which never gets to a healthy state. See the screenshot below.

Can this happen because of no UDP support in Hetzner LB? hetznercloud/hcloud-cloud-controller-manager#252 (comment)

It looks like the automation tool supports klipper, which should work with UDP. AFAIK, our neko example was originally done with klipper (and k3s).

[Biacode]

Can this happen because of no UDP support in Hetzner LB? hetznercloud/hcloud-cloud-controller-manager#252 (comment)

Thank you, @levaitamas. I appreciate your efforts on trying to help.
Previously I've tried to deploy the hetzner provider I use using Klipper without that much success.
I'll try to set it up again and post the configs.

[rg0now]

Hi @Biacode, the newest STUNner point release supports HTTP health checking, does this solve your problem? Sorry, no testbed here, that's why I'm asking. Also, the NodePort fallback is always available if you don't like the LB your provider offers. At the moment you cannot prevent STUNner from creating an LB, but once we fix this issue you will be able to override this default.
If not, then do you see any way we could help you on the STUNner side? Happy to chat about your use case of you're interested, just chat on us on the Discord.

[rg0now]

Closing this issue due to inactivity. Feel free to reopen if the problem persists.