通信

マルチネットワーキングと Kubernetes で通信アプリケーションを変革

2024年5月14日

Google Cloud Japan Team

※この投稿は米国時間 2024 年 4 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。

従来の Kubernetes ネットワーキングは、基本的な Pod 間接続には優れていますが、通信ワークロードのセキュリティ、パフォーマンス、コンプライアンスの要件に対応するには不十分な場合があります。このため、通信プロバイダが Kubernetes のスケーラビリティとアジリティの利点を十分に活用できずにいます。

Google Cloud のマルチネットワーキングアプローチを活用することで、通信プロバイダはこれらの制限を克服し、次のような機能を実現できます。

厳密なネットワーク分離: Kubernetes 内で管理、シグナリング、メディアの各トラフィックを分離することで、法規制を遵守し、セキュリティを強化します。
最大限のパフォーマンス: ハードウェアアクセラレーション（SR-IOV など）を必要とする通信アプリケーションの場合、要求の厳しい 5G モバイルコア、RAN、データプレーンのワークロードに必要な高スループットと低レイテンシを実現します。

Kubernetes のマルチホーム Pod 用メタプラグインである Multus のような既存のソリューションもありますが、いくつかの欠点があります。

使いにくい: Multus は非構造化文字列ベースのアノテーションに依存しているため、構成が複雑でエラーが発生しやすくなっています。
柔軟性に欠ける: Pod へのネットワークの動的な追加や削除ができないため、運用上のオーバーヘッドが発生し、適応性が制限されます。
Kubernetes との統合が限定的: Multus には以下に対するネイティブサポートがありません。

ネットワーク ポリシー: 複数のネットワークにわたってセキュリティを適用するのは困難です。
ネットワーク サービス: セカンダリインターフェースを使用するアプリケーションのロードバランシングとヘルスチェックはサポートされていません。

オブザーバビリティが低い: Multus では、マルチネットワーク設定のモニタリングとトラブルシューティングが困難です。

Google Cloud のアプローチでは、マルチネットワーキングを Kubernetes にネイティブに統合します。これにより、Kubernetes の Service、ロードバランサ、Border Gateway Protocol（BGP）、ネットワークポリシーを簡単に使用できるようになります。これらはすべて、堅牢な通信ネットワークの構築には不可欠です。また Google は、Cloud Native Computing Foundation（CNCF）の Kubernetes Enhancement Proposal の一環として、Kubernetes コミュニティとともにこのコンセプトに取り組んでいます。

Ericsson などのパートナーは、通信ユースケースの特定のニーズに対応することに重点を置いた Google Cloud のマルチネットワーキングアプローチを支持しています。

「Kubernetes の標準的なネットワーキング機能を維持しながら、ネットワーク分離によって通信関連のデプロイメントにおけるセキュリティと運用効率を確保するという課題は、Google のマルチネットワーク機能によって解決できます。Google のマルチネットワーク機能が、機能性を損なうことなくこの課題に対するソリューションになっている点は注目に値します。」- Ericsson

このブログでは、マルチネットワーキングによって可能になる重要な通信ユースケースについて説明します。また、Google Distributed Cloud（GDC）での 2 つの具体的な実装例についても詳しく説明します。一つは、4G / 5G モバイルコアのデプロイメントにおける Mobility Management Entity（MME）と Home Subscriber Server（HSS）間のシグナリングトラフィックの分離です。もう一つは、Network Exposure Function（NEF）とその Application Function（AF）ピア間のシグナリングトラフィックの分離です。

マルチネットワークのユースケース #1

クラウドネイティブネットワーク機能（CNF）アプリケーションでは、追加のインターフェースを Kubernetes Pod にプロビジョニングする必要があります。これらの各インターフェースは、法規制遵守のため、分離されたネットワーク内に存在する必要があります。分離はレイヤ 2 ネットワーク上で行わなければなりません。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_RRbiUht.max-1200x1200.png

マルチネットワークのユースケース #2

CNF アプリケーションでは、ハードウェアベースのインターフェース（例: SR-IOV VF）をワークロード Pod にプロビジョニングする必要があります。ハードウェアは、パフォーマンス目的（高帯域幅、低レイテンシ）のためにユーザー空間アプリケーション（例: DPDK ベース）によって利用されます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_g38jqGG.max-1200x1200.png

4G / 5G ネットワーキングのシナリオにおけるマルチネットワーキングアプリケーション

マルチネットワークのユースケース: S6a トラフィック

それでは、4G モバイルコアネットワークの Mobility Management Entity（MME）と Home Subscriber Server（HSS）機能間のネットワーキングにおけるマルチネットワークフレームワークの具体的な使用例を見てみましょう。4G モバイルネットワークでは、MME と HSS がユーザーの接続とセキュリティの管理を担当する主要なネットワーク要素です。

MME:

ユーザーの接続 / 切断手続き、ネットワーク上のデバイスの登録と登録解除を処理します。
ユーザーの移動に伴う基地局間の引き継ぎを管理します。
ユーザーから、またはユーザーへの発着信およびデータトラフィックをルーティングします。

HSS:

認証情報、サブスクリプションの詳細、ローミング契約などの加入者情報を保存します。
認証および認可手順を実行して、ユーザー ID とアクセス制御を検証します。
緊急サービスやその他の目的で、ユーザーの位置情報を MME に提供します。

MME と HSS は連携し、ネットワーク効率と加入者情報の完全性を維持しながら、安全でスムーズなユーザーエクスペリエンスを提供します。

この接続シナリオは、GDC のコネクテッド構成を使用し、分離されたシグナリングネットワークを介して MME Pod と HSS Pod を接続する目的で、上記のユースケース #1 の特定の使用例に焦点を当てています。GDC のコネクテッド構成では、AI、セキュリティ、オープンソースを備えた最新のアプリケーションをエッジで配信する、フルマネージドのハードウェア製品とソフトウェア製品が提供されます。この実装では、MME は MACVLAN タイプのインターフェースを使用し、HSS Pod は別のマルチネットワークインターフェースを使用して、Diameter トラフィックを同じシグナリングネットワークに誘導します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_cKwYAm3.max-1800x1800.png

次に、シグナリングネットワーク定義のスニペットと、それぞれの Pod でこの追加の Pod ネットワークを参照するために変更された HSS Pod 仕様を示します。

読み込んでいます...

NEF の N33 インターフェースを使ったマルチネットワークのユースケースここで、5G ネットワークアーキテクチャの 2 つのノードである、Network Exposure Function（NEF）とその Application Function（AF）ピア間のネットワーキングにおけるマルチネットワークフレームワークの具体的な使用例を見ていきましょう。

NEF - このネットワーク機能は、3GPP ネットワーク機能によって提供されるサービスと機能をアプリケーションに安全に公開する手段になります。
AF ピア - このネットワーク機能は、トラフィック管理と QoS 割り当てにおいて重要な役割を果たします。

このシナリオでは、NEF の AF ピアはお客様の信頼されたドメイン内に存在し、シグナリングネットワーク（VRF）に接続されています。デフォルトでは、NEF Pod はプライマリインターフェースを介してデフォルトネットワーク（VRF）に接続されます。同じ VRF 上にトラフィックを維持するために、NEF Pod 上でシグナリングマルチネットワーキングを有効にして、シグナリングネットワークに接続します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_fqn7EBn.max-1500x1500.png

上記の 2 つのユースケースでは、Service VIP（仮想 IP）として示されている HSS または NEF の 3GPP エンドポイントが、GDC にバンドルされている BGP ロードバランサを使用して、Service type: LoadBalancer として公開されます。これは BGP ベースの L3 ロードバランサであり、コントロールプレーンとしての BGP スピーカーと eBPF ベースのデータパスが含まれています。BGP スピーカーは、構成された eBGP ピアに Kubernetes Service（type=LoadBalancer）の Service IP を自動的にアドバタイズします。その後、eBPF ベースのデータパスは、受信した Service VIP トラフィックをバックエンド Pod に分散します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/5_iJMef7G.max-1400x1400.png

ロードバランサの仕様の一部を以下に示します。

読み込んでいます...

ここでは、3GPP の Service VIP に割り振る外部 IP を決定的に選択できるようにする config-map 仕様を確認しましょう。

読み込んでいます...

マルチネットワーキングによる通信プロバイダの強化

今回のブログでは、Google Cloud のマルチネットワーキングアプローチがどのように Kubernetes 上の重要な通信ユースケースを実現できるかをご紹介してきました。通信ワークロードに Google Distributed Cloud と GKE を使用する方法について詳しくは、次のリソースをご確認ください。