承接 Day 12（影像編碼調校），今天來看 Ingress 與 TURN 的拓樸擺位。這決定了使用者從不同網路環境（公司內網、家用 NAT、公網）連進來時，能否成功建立 WebRTC 連線，以及延遲能否保持在可接受範圍。

A. 基本角色複習

• Ingress (NGINX)：K8s 對外入口，負責 HTTPS / WebSocket / signaling。
• Selkies Sidecar：處理 WebRTC 連線建立與 GStreamer 視訊串流。
• STUN/TURN (coturn)：協助 ICE 穿透 NAT，TURN 可中繼流量。
• DNS：提供固定名稱（如 isaac.example.com, turn.example.com）。

B. 拓樸模式一：公網直連（最單純）

Browser ──HTTPS──▶ Ingress (LB:443) ─▶ Selkies Pod
         └─STUN──▶ turn.example.com:3478 (僅查詢外網 IP)

• 適用情境：叢集有公網 IP，使用者大多在家中單層 NAT。
• 優點：結構最簡單、延遲最低（P2P 直連）。
• 缺點：遇到企業網、飯店 WiFi 多層 NAT → 常失敗。

C. 拓樸模式二：私網 + 公網 TURN（最常見）

Browser ──HTTPS──▶ Ingress (企業/雲 LB)
         └─STUN──▶ 公網 STUN Server
         └─TURN──▶ 公網 TURN (relay)

• 適用情境：K8s 叢集本身跑在私網（無公網 IP），僅有 NAT 出口。
• TURN 必須有公網 IP：例如 turn.example.com → 1.2.3.4。
• 優點：通用性最佳，多 NAT 仍可連通。
• 缺點：一旦走 TURN，延遲增加 30~100ms。

建議：Ingress 可在私網 LoadBalancer / NodePort，TURN Server 需放在可被外部訪問的公網節點。

D. 拓樸模式三：多區 TURN（低延遲優化）

[User Asia] ─▶ turn-asia.example.com ─▶ coturn (Tokyo)
[User US]   ─▶ turn-us.example.com   ─▶ coturn (Oregon)
[User EU]   ─▶ turn-eu.example.com   ─▶ coturn (Frankfurt)

• 適用情境：使用者分布全球，需要就近 relay。

• DNS / Anycast 技巧：

  • 用 GeoDNS → 自動導向最近 TURN。
  • 或用 Anycast IP → 由 BGP 導流。

• 優點：減少跨洲轉發延遲。

• 缺點：運維成本提高。

E. Ingress 與 TURN 的協同

1. 不同角色，勿混用：

   • Ingress = HTTPS Signaling
   • TURN = SRTP/DTLS relay
   • 不建議共用同一個 Nginx 或 Pod。

2. 防火牆規則：

   • Ingress：443/tcp
   • TURN：3478/udp, 5349/tcp（建議至少開 UDP 3478）

3. TLS：

   • Ingress 用 ACME/Let’s Encrypt。
   • TURN 也可跑 TLS (turns:)，但多數情境下 UDP3478 即可。

F. 常見問題

• 為何一定要公網 TURN？ → 因為 NAT 後的私網 IP 外界無法直連，必須 relay。
• 能不能把 TURN 與 Ingress 合併？ → 理論上可，但安全與效能風險高，不建議。
• 延遲過高 → 部署多區 TURN，或縮短客戶端與 TURN 之間的物理距離。

感想

今日気づいてしまった、買ったストレージサーバーはk8sサポートしていませ......