はじめに

色々Kubernetes周りのOSSを調べていたところ、STUNnerというKubenetes向けのWebRTC関連のOSSがGAになっていました。
気になったのでどういったOSSなのかを調べてまとめてみました。

STUNnerとは

STUNnerはKubernetes向けに作成されたWebRTC用メディアGatewayです。
オーディオ・ビデオといったWebRTCストリームを仮想化をKubernetes内のmediaサーバへ流す役割を持っています。
L7mp Technologiesという4人の博士課程と1人の修士課程の5人チームの会社が主導して作っているようです。

またCNCF landscapeにも登録されています。

KubernetesとWebRTCの相性

KubernetesとWebRTCの組み合わせは以下の理由から相性が最悪とのこと

Kubernetesは主にHTTP/TCPベースに設計されている-
- WebRTCはUDP/RTPベースで動作するためKubenetesの設計に適してなかった
KubernetesのNAT
- Kubernetsのデータプレーンには複数のNATが存在しておりWebRTCは複数のNAT変換に弱い
- これによりUDP/RTPによる接続が切断されメディアサーバにたどり着けない

現状の解決策としてメディアサーバーPodをデプロイする際にhostnetwork=trueにすることでNAT変換を回避できるが、Kubernetesのアンチパターンにあたってしまう。ref: docs

STUNnerではhostnetwork=trueでメディアサーバPodを実行することなく、メディアトラフィックをKubernetes内に入れることができるとのこと。またSTUNnerはメディアGatewayとしての役割だけでなく、STUN/TURNサーバとしても使うことができる。

STUNerのアーキテクチャ

STUNnerのアーキテクチャは以下のとおりです。

Control planeとData planeに分かれています。一個ずつ見ていきます。

Control plane

Gateway API: オーディオ・ビデオといったメディアトラフィックを受け入れるための設定方法を記述するリソースの集合体
- GatewayClass: 設定階層の一番トップ
- GatewayConfig: STUNner全般の設定を担う
- Gateway: 各TURNサーバリスナーのポートとプロトコルを定義
- UDPRoute: クライアントトラフィックの転送先バックエンドサービスを指定
STUNner Gateway Operator: Gateway APIリソースの監視をする

Data plane

stunnerd pods
- pion/turnというGoのWebRTCフレームワークベースのTURNサーバを実装
- Gateway事に別個のDeploymentとして展開
- バックエンドサービスへのパケット転送
LoadBalancer Service
- Gateway事に作成される
- stunnerd podのTURNリスナーを外部に公開する

こう見るとIngressをWebRTC版に拡張したように見える。(実際はもっと複雑なのかも?)

まとめ

今回はたまたま見かけたSTUNnerを軽く調べてみました。WebRTCはちょこちょこ調べている程度の知識しかありませんでしたが、STUNnerのドキュメントをとうしてKubernetesとWebRTCの相性について学ぶことができました。
次の記事ではSTUNnerを使ったdemoを動かしてみようと思います。

参考文献