support NodePort alternative to hostnetwork for RTCD chart

[jthunderbird]

Summary

RTCD requires direct UDP access from the client (running outside the cluster). This means the client needs to be able to reach the RTCD pod(s) directly via a configurable UDP port.

The default mechanism RTCD handles this via the chart is to turn on hostNetwork: true in the deployment/daemonset and to create a headless service. The implications required here for your client to reach RTCD over UDP now mean RTCD will have access to the underlying node network stack and require the node be reachable via the client.

Both of these factors go against best practice with Kubernetes networking and also are not required. I am working another PR for the documentation here to further elaborate, but the basic premise is you can use a NodePort instead of hostNetwork to expose your application. Further, you can put an external LB in front of the cluster to protect the nodes and just forward UDP/8443 to the nodeport via the LB.

The last part is optional, but the nodeport paradigm is impossible without forking the chart (or in our case using flux to postrenderer - egh). This PR maintains the default posture of hostnetwork and headless service, but simply makes them configurable if you would prefer the nodeport route.

The corresponding documentation update PR here.

Ticket Link

no ticket link

[mattermost-build]

Hello @jthunderbird,

Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

[theo-commits]

LGTM

[streamer45]

Thanks @jthunderbird . No major concerns from my side. Let me know when this is ready for final review so I can ask one of our infra people to have a look.

One potentially important detail to document is that disabling host networking will likely affect how local ICE candidates are generated. Specifically, it may hinder connectivity within a private network, as the RTCD service won't be able to determine the node's IP address and will instead generate local candidates based on the pod IP—which is typically not directly reachable.

As a result, this setup may require more extensive use of the ice_host_override setting to support the common deployment model: on-prem clients connecting via the local network, and external clients connecting through a public IP (e.g., an NLB).

[jthunderbird]

Thanks @jthunderbird . No major concerns from my side. Let me know when this is ready for final review so I can ask one of our infra people to have a look.

One potentially important detail to document is that disabling host networking will likely affect how local ICE candidates are generated. Specifically, it may hinder connectivity within a private network, as the RTCD service won't be able to determine the node's IP address and will instead generate local candidates based on the pod IP—which is typically not directly reachable.

As a result, this setup may require more extensive use of the ice_host_override setting to support the common deployment model: on-prem clients connecting via the local network, and external clients connecting through a public IP (e.g., an NLB).

In the linked related documentation PR, I did mention the required RTCD_RTC_ICEHOSTOVERRIDE that needs to be set so RTCD knows what to hand out. Maybe I should add a comment in this project reflecting that as well so it is very explicit.

As for taking out of draft, I am pretty sure it is fine but have not actually tested it (our environment is offline so can't test there). I will verify this works soon. We are currently deploying in this manner but I had to use Flux postrenderers to make these changes, but still need to make sure I did not invoke some stupid syntax error or something.

[mattermost-build]

This PR has been automatically labelled "stale" because it hasn't had recent activity.
A core team member will check in on the status of the PR to help with questions.
Thank you for your contribution!

[KengTeong]

I can confirm this works for us within our environment and is currently deployed in at least 5 different clusters. @jthunderbird
However, this is deployed in a specific environment.