feat: add native Azure support and configurable ingress for livekit-server chart

[fajarhide]

Add Native Azure LoadBalancer Support for LiveKit Server

Problem Statement

On Azure AKS, using HostNetwork or ClusterIP for LiveKit often leads to WebRTC connection failures due to Azure's strict Outbound NAT restrictions. Standard Ingress Controllers (like Nginx) also face challenges routing high-volume UDP traffic in a way that remains compatible with LiveKit's ICE candidate discovery.

Proposed Changes

This PR introduces a new loadBalancer.type: azure to the livekit-server Helm chart, making it "Azure Native."

Key Enhancements:

1. Native Azure LoadBalancer: Setting loadBalancer.type: azure automatically configures a Service of type LoadBalancer and correctly exposes the necessary multiplexed ports (rtc-tcp, rtc-udp, and turn-udp/tcp).
2. Decoupled Ingress Toggle: Introduced loadBalancer.ingress.enabled (default: true). This allow users to disable the chart-generated Ingress while still using a LoadBalancer for Media traffic. This is a Best Practice for Azure, where SSL is often handled by a manual/separate Ingress while Media goes through a dedicated LB IP.
3. TURN Port Exposure: Automatically exposes port 3478 (UDP/TCP) when the Azure LoadBalancer is active to ensure reliable fallback connectivity.

Why this is needed

Azure's LoadBalancer doesn't support massive UDP port ranges easily. By providing a native type that focuses on multiplexed ports and allowing users to decouple Ingress from the Service, we enable a stable, production-ready LiveKit deployment on Azure with minimal manual overrides.

Design Decisions & Best Practices

1. Hybrid Networking Model: In high-scale WebRTC deployments (like on Azure AKS), it is a Best Practice to decouple the Signal traffic (WSS/443) from the Media traffic (UDP).
   • Signal: Handled by the existing cluster Ingress Controller (Nginx/Traefik) for easy SSL termination and standard HTTP features.
   • Media: Handled by a dedicated, high-performance LoadBalancer IP to bypass Azure's Outbound NAT limitations without overwhelming the Ingress Controller with raw UDP traffic.
2. "Freedom of Choice" (Flexibility): By introducing the loadBalancer.ingress.enabled toggle, this chart remains beginner-friendly (default: true) while empowering enterprise users to disable the automatic Ingress and use their own manual/centralized Ingress setup.

How to Test:

1. Validate Helm Template Output:
   Run helm template . -f values.yaml and verify:

   • The Service should have type: LoadBalancer.
   • Ports 7881 (RTC TCP) and 3478 (TURN UDP/TCP) should be present in the Service spec.
   • No Ingress resource should be generated if loadBalancer.ingress.enabled is set to false.

2. Verify on Azure AKS:
   Deploy the chart to an Azure cluster with the following values:

   loadBalancer:
     type: azure
     ingress:
       enabled: false
   livekit:
     rtc:
       use_external_ip: false
       node_ip: <EXTERNAL_IP_OF_LOADBALANCER>

   • Verify that a dedicated LoadBalancer is created by Azure with a Public IP.

3. End-to-End Connectivity:
   Run the LiveKit Connection Test using the server's domain (via a manual Ingress) and verify that:

   • The Signal connection (WSS) is established.
   • Audio/Video packets are successfully published and received.
   • ICE candidates point to the dedicated LoadBalancer IP.

[CLAassistant]

All committers have signed the CLA.