ポッドとサービスの参考資料

機能の概要と変更履歴

要約データ

表 1. 要約データ

該当製品または機能エリア

SMF

該当プラットフォーム

SMI

機能のデフォルト設定

有効：常時オン

このリリースでの関連する変更点

N/A

関連資料

該当なし

更新履歴

表 2. マニュアルの変更履歴
改訂の詳細 リリース
node-monitor ポッドは、すべての K8 ポッドのモニタリングを有効にするためにサポートされています。

2021.02.0

grafana-dashboard-app-infra ポッドが削除されました。

2021.02.3.t3

最初の導入。

2020.02.0 より前

機能説明

Kubernetes クラスタ戦略に SMF は、構築されています。これは、コンテナ化、高可用性、拡張性、モジュラ性、および展開の容易さというネイティブの概念を採用していることを示します。Kubernetes に提供された利点を達成するために SMF は、ポッドやサービスなどのコンポーネントを含む構造を使用します。

展開環境に応じて、SMF は、仮想マシンにポッドを展開します。ポッドは、ポッド内通信を担当するサービスによって動作します。ポッドをホストするマシンに障害が発生した場合、またはネットワークの中断が発生した場合、ポッドは終了または削除されます。ただし、この状況は一時的なものであり、Kubernetes は新しいポッドを回転して無効なポッドを置き換えます。

次のワークフローは、ホストマシン、および関連するポッドとサービスへの高度な可視性を提供します。また、ポッドが相互に通信する方法も表します。展開インフラストラクチャに基づいて、表示が異なる場合があります。
図 1. ポッドの通信ワークフロー

Kubernetes の展開には、クラスタ内の Kubernetes リソースを管理するための kubectl コマンドラインツールが含まれています。ポッド、ノード、およびサービスを管理できます。

Kubernetes の概念に関する情報については、Kubernetes のドキュメントを参照してください。

SMF の Kubernetes コンポーネントの詳細については、次を参照してください：

  • ポッド

  • サービス

ポッド

ポッドは、Kubernetes クラスタで実行されるプロセスです。ポッドは、コンテナと呼ばれる細かなユニットをカプセル化します。各ポッドには、1 つ以上のコンテナを含めることができます。

Kubernetes は、物理マシンまたは仮想マシンである単一ノードに 1 つまたは複数のポッドを展開します。各ポッドには、内部 IP アドレスとポート スペースを持つ個別の ID があります。ただし、ポッド内のコンテナは、ストレージ リソースとネットワーク リソースを共有できます。

次の表に、SMF ポッドの名前と、割り当てたラベルに応じてそれらが展開されるホストを示します。ラベルの割り当て方法については、 「ノードへのポッドの関連付け」を参照してください。

表 3. SMF ポッド
ポッド名 説明 Virtual Machine Name
api-smf-ops-center SMF Ops センターの confD API ポッドとして機能します。 OAM
base-entitlement-smf スマート ライセンス 機能をサポートします。 OAM
cache-pod 他のポッドが適宜使用するあらゆる種類のシステム情報をキャッシュするポッドとして動作します。 プロトコル
cdl-ep-session CDL へのインターフェイスを提供します。 セッション
cdl-index-session セッション ポッドへのキーのマッピングを保持します。 セッション
cdl-slot-session セッション データを保存する CDL セッション ポッドとして動作します。 セッション
dns-proxy SMF の DNS エンドポイントとして動作 プロトコル

diameter-ep-gx-client

Diameter エンドポイントとして動作し、Gx インターフェイスを介した SMF と PCRF 間の通信を可能にします。

プロトコル

diameter-ep-gy-client

Diameter エンドポイントとして動作し、Gy インターフェイスを介した SMF と PCRF 間の通信を可能にします

プロトコル
マニュアル ドキュメントが含まれています。 OAM
edr-monitor pod 永続ボリュームに維持されている EDR ファイルが含まれています。 OAM
etcd-smf-etcd-cluster ポッド インスタンス、リーダー情報、NF-UUID エンドポイントなどの情報を保存する SMF アプリケーションの etcd をホストします。 OAM
grafana-dashboard-cdl Grafana の CDL メトリックのデフォルト ダッシュボードが含まれます。 OAM
grafana-dashboard-smf Grafana の SMF サービス メトリックのデフォルト ダッシュボードが含まれます。 OAM
gtpc-ep SMF の GTPC エンドポイントとして動作します。 プロトコル
kafka CDL レプリケーションの Kafka の詳細をホストします。 プロトコル
li-ep SMF の合法的傍受エンドポイントとして動作します。 プロトコル
nodemgr N4 リンクの確立と管理（ハートビート）など、ノード レベルの連携動作を実行します。また、UE IP アドレス、SEID、CHF-ID、リソース URI などの一意の識別子を生成します。 サービス
node-monitor pod すべての K8 ノードを監視し、問題が発生するとセルフリブートを実行します。これにより、他のラックへの GR がトリガーされます。 NA
oam-pod show コマンド、configuration コマンド、モニタ プロトコル モニタ サブスクライバなど、Ops センターのアクションを促進するためのポッドとして動作します。 OAM
ops-center-smf-ops-center SMF Ops センターとして機能します。 OAM
protocol アプリケーション プロトコル（PFCP、GTP、RADIUS など。その基礎となるトランスポート プロトコルは UDP）のエンコーダおよびデコーダとして動作します。 プロトコル
Radius-ep SMF の RADIUS エンドポイントとして動作 プロトコル
rest-ep HTTP2 通信用の SMF の REST エンドポイントとして動作します。 プロトコル
サービス SMF のメインのビジネス ロジックが含まれています。 サービス
smart-agent-smf-ops-center SMF Ops センターのユーティリティ ポッドとして機能します。 OAM
UDP プロキシ すべての UDP メッセージのプロキシとして動作します。UDP クライアントおよびサーバの機能を所有しています。 プロトコル
swift-smf-ops-center SMF Ops センターのユーティリティ ポッドとして機能します。 OAM
zookeeper トポロジ管理のために Kafka を支援します。 OAM

UDP プロキシの詳細は、「UDP プロキシ ポッド」のセクションを参照してください。

これらの SMF ポッドは、共通実行環境（CEE）ポッドと通信します。CEE ポッドの完全なリストについては、『UCC CEE 構成および管理ガイド』を参照してください。

レプリカ

各ポッドは、アプリケーションの 1 つのインスタンスで実行されます。より多くのインスタンスを実行してより多くのリソースを提供する場合は、インスタンスごとに 1 つずつ複数のポッドを使用できます。この概念は、Kubernetes ではレプリケーションと呼ばれます。複製されたポッドまたはレプリカは通常、ワークロード リソースとそのコントローラによってグループとして作成および管理されます。

複数のレプリカがある場合、Kubernetes はそれらの間で負荷を分散できます。ノード障害時に、レプリカを使用できます。


（注）  

レプリカは、ハードウェアと展開されたコール モデルに基づいています。

UDP プロキシ ポッド

機能説明

SMF には、UPF（N4）および SGW（EPS インターワーキング用の s5 または s8）への UDP インターフェイスがあります。プロトコル レイヤ ポッド（smf-protocol and gtp-ep）を利用して、これらの UDP インターフェイス上でメッセージのエンコード、デコード、および交換が行われます。

3GPP 仕様に記載されている機能を使用するには、次の手順を実行します。

  • プロトコル レイヤ ポッドが元の送信元と宛先の IP アドレスおよびポート番号を受け取ることは必須です。ただし、着信パケットが Kubernetes（K8s）クラスタの UDP サービスに到着した後、元の IP および UDP ヘッダーは保持されません。

  • 同様に、発信メッセージの場合、（ピア ノードに公開される）UDP サービスの外部 IP アドレスに設定された送信元 IP が必須です。ただし、プロトコル レイヤ ポッドのさまざまなインスタンスが K8s クラスタのさまざまなノードから発信メッセージを送信する場合、送信元 IP は出力インターフェイスに従って選択されます。

プロトコル レイヤ ポッドは、前述の条件を満たすために外部 IP アドレスを構成された物理インターフェイスを持つノードで生成されます。ただし、プロトコル レイヤ ポッドを生成すると、次の結果が発生します。

  • プロトコル ポッドは K8s クラスタの同じノードで生成されるため、ノード レベルの HA（高可用性）を実現することはできません。そのノードに障害が発生すると、サービスが失われる可能性があります。

  • プロトコル ポッド（smf-protocol、gtp-ep および radius-ep）には、独自の UDP クライアントおよびサーバ機能が含まれている必要があります。さらに、各プロトコル レイヤ ポッドには、アフィニティ ルールに基づいて K8s ノードにラベル付けを行う必要がある場合があります。これにより、プロトコル レイヤ ポッドのスケーリング要件が制限されます。

SMF では、「udp-proxy」と呼ばれる新しい K8s ポッドを導入することで、これらの問題に対処します。このポッドの主な目的は次のとおりです。

  • 「udp-proxy」ポッドは、あらゆる種類の UDP メッセージのプロキシとして機能します。また、UDP クライアントおよびサーバの機能も備えています。

  • プロトコル ポッドは、個々のプロトコル（PFCP、GTP、Radius）のエンコーディングと復号化を実行し、「udp-proxy」ポッドに UDP ペイロードを提供します。「udp-proxy」ポッドは、プロトコル ポッドからペイロードを受信した後、UDP ペイロードを送信します。

  • 「udp-proxy」ポッドは、物理 IP の代わりに仮想 IP（VIP）で UDP ソケットを開きます。これにより、「udp-proxy」ポッドが特定の K8s ノード（VM）に対して厳密なアフィニティを持ちません。したがって、UDP プロキシに対してノードレベルの HA が有効になります。


Note

「udp-proxy」ポッドの 1 つのインスタンスは、デフォルトで、K8s クラスタ内のすべてのワーカー ノードで生成されます。

SMF 向けの UDP プロキシ機能は、仮想 IP アドレス機能と機能的な関連性があります。
アーキテクチャ

udp-proxy ポッドは、K8s クラスタのワーカー ノードに配置されます。

  1. 各 K8s ワーカー ノードには、udp-proxy ポッドのインスタンスが 1 つ含まれています。ただし、仮想 IP を所有するのは K8s ワーカー ノードの 1 つだけです。仮想 IP を所有するワーカー ノードはアクティブ モードのままで、他のすべてのワーカー ノードはスタンバイ モードのままです。

  2. アクティブな udp-proxy ポッドは、仮想 IP および指定されたポートにバインドされて、ピア ノード（UPF および SGW）からの UDP メッセージをリッスンします。

  3. ピア ノードから受信した UDP ペイロードは、プロトコルの 1 つのインスタンス、gtp-ep、または radius-ep ポッドに転送されます。ペイロードは、さらに処理するために同じノードまたは異なるノードのいずれかで転送されます。

  4. protocol、gtp-ep、または radius-ep ポッドからの応答メッセージは、udp-proxy ポッドのアクティブなインスタンスに転送されます。udp-proxy ポッドは、対応するピア ノードに応答メッセージを送り返します。

  5. SMF によって開始されたメッセージは、protocol、gtp-ep、または radius-ep ポッドでエンコードされます。さらに、UDP ペイロードが udp-proxy ポッドに送信されます。最終的に、udp-proxy ポッドは完全な IP ペイロードで構成され、メッセージをピアに送信します。ピアからの応答を受信すると、メッセージを送信したのと同じ smf-protocol、gtp-ep、または radius-ep ポッドに UDP ペイロードが送り返されます。

ピアによって開始されたメッセージのプロトコル ポッドの選択

udp-proxy ポッドは、ピア ノード（UPF など）によって開始されたメッセージを受信すると、プロトコル インスタンス間で負荷分散して、プロトコル ポッドの任意のインスタンスを選択します。このインスタンス番号のエントリが、ピア ノードの送信元 IP および送信元ポート番号とともに保存されます。同じ送信元 IP および送信元ポートからのメッセージが、以前に選択されたインスタンスと同じインスタンスに送信されます。

UDP プロキシの高可用性

UDP プロキシの HA モデルは、キープアライブ仮想 IP の概念に基づいています。VIP は、展開中に N4 インターフェイスに指定されます。また、キープアライブ インスタンスは VIP を管理し、VIP の IP アドレスが K8s クラスタのワーカー ノードのいずれかにあるインターフェイスのセカンダリ アドレスとして作成されるようにします。

このワーカー ノードの「udp-proxy」インスタンスは VIP にバインドされ、アクティブな「udp-proxy」ポッドのロールを担います。他のワーカー ノードのすべての「udp-proxy」インスタンスはスタンバイ モードのままです。

ノード モニタリング ポッド

ノード モニタ ポッドは、マスター ノードとワーカー ノードなどすべての Kubernetes ノードで実行され、他のノードの動作状態を定期的にチェックします。ネットワークの問題またはハードウェアの一時的な問題により、ノードが到達不能になる可能性があります。

ノードの動作状態に応じて、ノード モニタ ポッドはさまざまなモードに切り替わります。SMF は、グローバル コンフィギュレーション モードで CLI コマンド nodemonitor を使用してモードを切り替えます。

次の構成セクションでは、コマンドとモードに関する詳細について説明します。

ノード モニタリング ポッドの構成

ノード モニタリング ポッドは、ハードウェアの一時的な問題を解決するためにさまざまなモードに切り替わります。

モードを切り替えるには、次の構成例を使用します。

config 
   nodemonitor mode { 0 | 1 | 2 | 3 interval wait_time } 
   end

注：

  • nodemonitor mode { 0 | 1 | 2 | 3 interval wait_time }

    • mode 0 ：モニタリング機能を無効にします。

    • mode 1 ：2 つ以上のノードに到達できない場合に、ノードのモニタリングを有効にし、ハードコードされた値の 2 秒に達した後にのみ自己再起動を実行します。これがデフォルトの設定です。

    • mode 2 ：すべてのノードではなく、2 つ以上のノードに到達できない場合に、ノードのモニタリングを有効にし、自己リブートを実行します。

    • mode 3 interval wait_time ：2 つ以上のノードに到達できない場合に、ノード モニタリング ポッドが再起動されるまでの時間間隔を秒単位で指定します。

      wait_time は、 5 ～ 300 の範囲の整数である必要があります。

設定例

次に、ノード モニタリング ポッド構成の例を示します。

config 
   nodemonitor mode 3 interval 15 
   end

この例に従って、ノード モニタリング ポッドは 15 秒待機してから、2 つまたは ノードに到達できない場合、セルフリブートを実行します。

設定の確認

構成を確認するために、この show running-config nodemonitor コマンドを使用します。

この show コマンドの出力には、ノード モニタリング ポッドのモードに関する構成が表示されます。

smf# show running-config nodemonitor 
nodemonitor mode 3 interval 15

サービス

SMF の構成は、一連の個別のポッドで実行される複数のマイクロサービスが含まれています。マイクロサービスは、SMF の展開時に展開されます。SMF はこれらのサービスを使用して、ポッド間の通信を可能にします。別のポッドと対話する場合、サービスはポッドの IP アドレスを識別してトランザクションを開始し、ポッドのエンドポイントとして機能します。

次の表では、SMF サービスと、それらが実行されるポッドについて説明します。

表 4. SMF サービスとポッド
Service Name ポッド名 説明
base-entitlement-smf base-entitlement-smf スマート ライセンス 機能をサポートします。
datastore-ep-session cdl-ep-session CDL セッションを担当します。
datastore-notification-ep smf-rest-ep smf-rest-ep を介して CDL から smf-serviceに通知を送信します。
datastore-tls-ep-session cdl-ep-session セキュアな CDL 接続を担います。

diameter-ep-gx-client

diameter-ep-gx-client

クレジット制御メッセージのために、gRPC メッセージを Diameter エンドポイントに送信します。これは、Diameter エンドポイントによって Diameter CCR メッセージに変換され、Gx サーバーに送信されます。

diameter-ep-gy-client

diameter-ep-gy-client

クレジット制御メッセージのために gRPC メッセージを Diameter エンドポイントに送信します。これは、Diameter エンドポイントによって Diameter CCR メッセージに変換され、Gy サーバーに送信されます。

マニュアル マニュアル SMF ドキュメントを担当します。
edr-monitor edr-monitor 永続ボリューム内の EDR ファイルのメンテナンスを担当します
etcd etcd-smf-etcd-cluster-0、etcd-smf-etcd-cluster-1、etcd-smf-etcd-cluster-2 名前空間内のポッド検出を担当します。
etcd-smf-etcd-cluster-0 etcd-smf-etcd-cluster-0 etcd クラスタ間のデータの同期を担当します。
etcd-smf-etcd-cluster-1 etcd-smf-etcd-cluster-1 etcd クラスタ間のデータの同期を担当します。
etcd-smf-etcd-cluster-2 etcd-smf-etcd-cluster-2 etcd クラスタ間のデータの同期を担当します。
grafana-dashboard-app-infra grafana-dashboard-app-infra Grafana のアプリ インフラ メトリックのデフォルト ダッシュボードを担当します。
grafana-dashboard-cdl grafana-dashboard-cdl Grafana の CDL メトリックのデフォルト ダッシュボードを担当します。
grafana-dashboard-smf grafana-dashboard-smf Grafana の SMF-service メトリックのデフォルト ダッシュボードを担当します。
gtpc-ep gtpc-ep GTP-C ポッドとのポッド間通信を担当します。
helm-api-smf-ops-center api-smf-ops-center Ops センター API を管理します。
kafka kafka Kafka メッセージを処理します。
li-ep li-ep 合法的傍受の相互作用を担います。
local-ldap-proxy-smf-ops-center ops-center-smf-ops-center Grafana などの他のアプリケーションによって Ops センターのログイン情報を活用する責任があります。
oam-pod oam-pod Ops センターでの Exec コマンドの促進を担当します。
ops-center-smf-ops-center ops-center-smf-ops-center SMF Ops センター を管理します。
ops-center-smf-ops-center-expose-cli ops-center-smf-ops-center 外部 IP アドレスで SMF Ops センターにアクセスする。
smart-agent-smf-ops-center smart-agent-smf-ops-center SMF Ops センター API に対応します。
smf-sbi-service smf-rest-ep REST-EP ポッドへの着信 HTTP2 メッセージのルーティングを担当します。
smf-n10-service smf-rest-ep REST-EP ポッドへの着信 N10 メッセージのルーティングを担当します。
smf-n11-service smf-rest-ep REST-EP ポッドへの着信 N11 メッセージのルーティングを担当します。
smf-n40-service smf-rest-ep REST-EP ポッドへの着信 N40 メッセージのルーティングを担当します。
smf-n7-service smf-rest-ep REST-EP ポッドへの着信 N7 メッセージのルーティングを担当します。
smf-nrf-service smf-rest-ep REST-EP ポッドへの着信 NRF メッセージのルーティングを担当します。
smf-nodemgr smf-nodemgr smf-nodemgr ポッドとのポッド間通信を担当します。
smf-protocol smf-protocol smf-protocol ポッドとのポッド間通信を担当します
smf-radius-dns smf-radius-dns smf-radius-dns ポッドとのポッド間通信を担当します
smf-rest-ep smf-rest-ep smf-rest-ep ポッドとのポッド間通信を担当します
smf-service smf-service smf-service ポッドとのポッド間通信を担当します。
swift-smf-ops-center swift SMF Ops センターのユーティリティ ポッドとして機能します
zookeeper zookeeper トポロジ管理のために Kafka を支援します
zookeeper-service zookeeper トポロジ管理のために Kafka を支援します

オープン ポートおよびサービス

SMF は、通信目的で異なるポートを使用します。次の表に、デフォルトのオープン ポートおよび関連するサービスを示します。

表 5. オープン ポートおよびサービス
ポート サービス 使用方法
9003 gRPC これは、ホスト ネットワークを使用していないすべてのアプリケーション ポッドのデフォルトの gRPC ポートです。
8080 TCP/HTTP これは、ホスト ネットワークを使用していないすべてのアプリケーション ポッドのデフォルトの prometheus サーバー ポートです。
8090 TCP/HTTP SMF は、SBI インターフェイス エンドポイントの HTTP2 REST エンドポイントを使用します。
2024 SSH SMF Ops Center はこのポートを使用して ConfD CLI アクセスを提供します。
2379-2380 TCP SMF は etcd サーバー クライアント エンドポイントを使用して、システム データを保存および取得します。
8882 gRPC これは、他のすべてのアプリケーション ポッドで使用される CDL セッション DB エンドポイントです。
8890 gRPC アプリケーション REST エンドポイントはこのポートを使用して、CDL からコールバック タイマーまたは通知を受信します。
8883 gRPC これは、他のすべてのアプリケーションポッドで使用される TLS - CDL セッション DB エンドポイントです。
2123 UDP SMF は、GTP-C プロトコル メッセージ（制御パス）のシグナリングに 3GPP 標準の GTP-C ポートを使用します。
2152 UDP SMF は、GTP-U プロトコル メッセージ（データパス）のシグナリングに 3GPP 標準 GTP-U ポートを使用します。
8805 UDP SMF は、PFCP プロトコル メッセージのシグナリングに 3GPP 標準 PFCP ポートを使用します。
8765 TCP6 SMF は、このポートを UDP プロキシポッドの準備プローブ ポートとして使用します。
7179、7189 TCP/HTTP Pprof サーバー エンドポイントは、S11 や S5 などの GTP-C エンドポイント インターフェイス固有のポッドからのランタイム プロファイリング データを提供します。
23300, 23310 TCP/gRPC SMF は、GTP-C エンドポイント インターフェイス固有のポッドに TLS GRPC IPC サーバー エンドポイントを使用します。
9005、9015 TCP/gRPC GTP-C エンドポイント インターフェイス固有のポッドの非 TLS GRPC IPC サーバー ポート。
27000、27010 TCP SMF は、GTP-C エンドポイント インターフェイス固有のポッドに KeepAliveD エンドポイントを使用します。
7279、7289 TCP このポートは、GTP-C エンドポイント インターフェイス固有のポッドで使用される管理エンドポイントの内部ポートです。このポートは、稼働状態および準備状態プローブに使用されます。
7079、7089 TCP/HTTP SMF は、GTP-C エンドポイント インターフェイス固有のポッドに prometheus サーバーポートを使用します。
8083 TCP/HTTP SMF は、プロトコル ポッドに prometheus サーバー ポートを使用します。
9006 TCP/gRPC SMF は、プロトコル ポッドの非 TLS GRPC IPC サーバー エンドポイントを使用します。
8003 TCP/HTTP SMF は、プロトコル ポッドに prometheus サーバー ポートを使用します。
23100 TCP/gRPC SMF は、プロトコル ポッドの TLS GRPC IPC サーバー エンドポイントを使用します。
7679 TCP/HTTP Pprof サーバー エンドポイントは、プロトコル ポッドからのランタイム プロファイリング データを提供します。
7879 TCP このポートは、プロトコル ポッドで使用される管理エンドポイントの内部ポートです。このポートは、稼働状態および準備状態プローブに使用されます。
27500 TCP SMF は、プロトコル ポッドにこの KeepAliveD エンドポイントを使用します。
28000 TCP SMF は、UDP プロキシ ポッドのこのキープアライブ エンドポイントを使用します。
23200 TCP/gRPC SMF は、UDP プロキシ ポッドの TLS GRPC IPC サーバー エンドポイントを使用します。
9004 TCP/gRPC UDP プロキシ ポッドの非 TLS GRPC IPC サーバーエンドポイント。
7879 TCP このポートは、UDP プロキシ ポッドで使用される管理エンドポイントの内部ポートです。このポートは、稼働状態および準備状態プローブに使用されます。
8850 TCP/HTTP Pprof サーバー エンドポイントは、UDP プロキシ ポッドからのランタイム プロファイリング データを提供します。

上記のポートに加えて、SMF は SMI 宛てのポートを使用して、ホスト間の情報をルーティングします。SMI ポートについては、『 Ultra Cloud Core Subscriber Microservices Infrastructure Operations Guide』を参照してください。

ノードへのポッドの割り当て

ここでは、ラベルに基づきポッドをノードに関連付ける方法について説明します。

クラスタを構成したら、ラベルを使用してポッドをノードに関連付けることができます。この関連付けにより、キーと値のペアに基づいて、ポッドを適切なノードに展開できます。

ラベルは、展開する必要があるノードを識別し、サービスを実行するために ポッドに必要です。たとえば、必要なキーと値のペアを使用してプロトコル層のラベルを構成すると、そのキーと値のペアに一致するノードに ポッドが展開されます。

ラベルを介してポッドをノードに関連付けるには、次の構成例を使用します。

config 
   k8 label vm_group key label_key value label_value 
   end

注：

  • k8 label vm_group key label_key value label_value ：K8 ノード アフィニティ ラベルのパラメータを構成します。

    • vm_group ：VM グループを指定します。次のいずれかである必要があります。

      • cdl-layer

      • oam-layer

      • protocol-layer

      • service-layer

    • key label_key ：ラベル キーを指定します。 label_key は 文字列である必要があります。

    • value label_value ：ラベル値を指定します。 label_value は 文字列である必要があります。

  • ラベルを構成しない場合、SMF ではデフォルトのキー値のペアを含むラベルが想定されます。

ポッドの詳細とステータスの表示

サービスに追加のポッドが必要な場合、SMF はポッドを作成して展開します。展開内でポッドのリストは、SMF Ops Center で確認できます。

マスター ノードから kubectl コマンドを実行して、Kubernetes リソースを管理できます。

ポッドの詳細は、YAML 形式で利用できます。

次のサンプル構成を使用して、包括的なポッドの詳細を表示するには：

kubectl get pods -n smf pod_name -o yaml

このコマンドの出力には、次の情報の列が表示されます。

  • ポッドが展開されているホストの IP アドレス。

  • ポッドで実行されているサービスとアプリケーション。

  • ポッド内のコンテナの ID と名前。

  • ポッドの IP アドレス。

  • ポッドの現在の状態とフェーズ。

  • ポッドが現在の状態になった時刻からの開始時刻。

SMF 名前空間内のすべてのポッドを表示するには、次の構成例を使用します：

kp get pods -n smf_namespace -o wide

状態

ポッドの状態を理解することで、現在の正常性を判断し、潜在的なリスクを防ぐことができます。以下のテーブルでは、ポッドの状態を説明します。

表 6. ポッドの状態

状態

説明

Running

ポッドは正常であり、ノードに展開されています。

1 つ以上のコンテナが含まれている。

Pending

アプリケーションは、ポッドのコンテナ イメージを作成中です。

成功

ポッド内のすべてのコンテナが正常に終了したことを示します。これらのポッドは再起動できません。

失敗しました（Failed）

ポッド内の 1 つ以上のコンテナが終了プロセスに失敗しました。障害は、コンテナがゼロ以外のステータスで終了したか、システムによってコンテナが終了されたために発生しました。

不明

ポッドの状態を特定できませんでした。通常、これは、ポッドが存在するノードに到達できないために発生する可能性があります。

UDP プロキシ バイパスを使用した PFCP プロトコル エンドポイント マージ

機能説明

バイパス プロキシは、この GTP パケットが gtpc-ep ポッドに直接到着できるようにするために導入されました。これにより、udp-proxy での処理が回避され、パケット転送での 1 ホップが減少します。

既存の gtpc-ep と udp-proxy でサポートされているすべての機能が、新しくマージされたパスに統合されます

次の機能は udp-proxy から統合されています。

  • トランザクション SLA

  • GTP パケットの DSCP マーキング

  • ローミング サブスクライバの BGP ルートのオン ザ フライを追加

  • ディスパッチャ機能と着信再送信のサポート

  • DDN の SGW キャッシュの統合

  • MBR キャッシュ統合

次の機能は gtpc-ep から統合：

  • アウトバウンド要求の n3t3 構成に基づく再送信

  • プロトコルをモニタし、サブスクライバをモニタする

  • エコー メッセージ処理

GR スプリットを使用した GTPC エンドポイント

スケーリングされた GTP トラフィックを処理し、CPU を最適に使用するために、GTPC-EP の複数のアクティブ インスタンスが開始され、GR インスタンスに基づいてトラフィック分割が行われます。

プロトコル マイクロサービスに統合された UDP プロキシ機能

機能説明

UDP プロキシ マイクロサービスは、UDP を必要とするプロトコル（PFCP、GTPC、および RADIUS）の UDP トランスポート終端を提供します。UDP プロキシは、ユーザー空間パケット転送と IPC 通信をプロトコル マイクロサービスへ提供します。また、送信元 IP アドレスのオブザーバビリティのためにホスト ネットワーキングを使用し、アクティブ/スタンバイ モードで動作します。

複数のプロトコル マイクロ サービスが UDP 転送の UDP プロキシに依存しているため、UDP プロキシはスケールのボトルネックと単一の障害発生時点になります。UDP プロキシ機能をそれぞれのプロトコルのマイクロサービスに統合することで、シグナリング パス内のマイクロサービス間での 1 ホップを減らすことにより、スケールのボトルネックを軽減し、CPU の使用率を向上させることができます。

機能の仕組み

UDP プロキシ バイパスを使用した PFCP プロトコル エンドポイント

プロトコル エンドポイントは UDP プロキシをバイパスし、N4/Sxa メッセージを UPF に直接送信します。UPF からの着信 N4/Sxa メッセージも UDP プロキシをバイパスして、プロトコル ポッドに到達します。（ハートビート要求メッセージでの送信元 IP アドレス IE の UPF サポートの対象となります）。プロトコル ポッドは、非ホスト ネットワーキング モードの動作を使用し続けます。

Kubernetes サービスが構成された VIP IP アドレスおよび標準ポートでリッスンを開始し、着信 N4/Sxa UDP パケットがプロトコル ポッドに送信されるようにします。着信メッセージ/パケットに関連付けられたインターフェイスを識別するための個別のターゲット ポートを使用して、N4 および Sx 用に作成された個別の Kubernetes サービス。Kubernetes クライアント IP アドレス アフィニティは、UPF からの再送信パケットが同じプロトコル ポッド インスタンスに送信されて再送信キャッシュに正常にヒットするようにするために利用されます。

現在のモード（バイパスなし）

この動作モードでは、N4、Sxa、GTP-U のメッセージ交換は UDP プロキシを介して行われます。UDP プロキシは、UPF との接続または受信を行います。

すべての PFCP に関連するノード関連のメッセージやセッション サービスまたは UPF から開始され、その応答は UDP プロキシを通過します。

アウトバウンド バイパス プロキシ モード

この操作モードは、S-GW または SMF サービスによって開始され、システムが Kubernetes Pod 環境変数「OUTBOUND_PROXY_BYPASS」を介して PFCP を使用して UPF に送信するすべてのメッセージに対してデフォルトで有効になっています。SMF（プロトコルポッド）によって UPF に直接送信されるメッセージは、関連するセッションで、次のようになります。

  1. PFCP セッション確立要求

  2. PFCP セッション変更要求

  3. PFCP セッション削除要求

このモードでは、UPF から、またはサービスによって開始された UPF への GTP-U メッセージは、引き続き UDP プロキシを介して交換されます。このモードでは、セッション関連のメッセージ（つまり、SMF サービスによって開始されたメッセージ）のみが、プロトコルから UPF に直接流れます。

プロトコル ポッドは、サービスから UPF IP アドレスを受信します。これは、UPF との接続の設定に使用され、その後、セッション関連のメッセージ交換に同じアドレスを使用します。ノードに関連するメッセージは、UDP プロキシからプロトコルまたはノード マネージャへのパスを継続して取り続けます。

完全なバイパス モード（インバウンドおよびアウトバウンド）

このモードでは、着信メッセージと発信メッセージの両方が、UDP プロキシをバイパスするプロトコル ポッドによって送受信されます。プロトコル ポッドは、構成された VIP に基づいて N4 および GTPu または Sxa ポートでリッスンします。プロトコル ポッドは Kubernetes サービス ネットワーク上に存在しなくなり、ホスト ベースのネットワーキング モードのままになります。プロトコル ポッドは、それが存在するノードまたは VM の IP を取得します。この条件は、プロトコルおよび UDP プロキシ ポッドの両方に存在するか、または使用可能な環境変数（UDP_PROXY_BYPASS）に基づいてトリガーされます。デフォルトでは、この変数は false で、UDP プロキシとプロトコルは、UPF とメッセージを交換する UDP プロキシの現在のように続行されます。

UDP_PROXY_BYPASS は、次の両方の条件が満たされた場合にのみ true に設定されます：

  1. VIP は、エンドポイント PFCP インターフェイス N4 またはインターフェイス Sxa で構成されます。

  2. エンドポイント プロトコル インターフェイス N4 またはインターフェイス Sxa で構成された VIP はありません。

UDP_PROXY_BYPASS 変数の値を変更すると、UDP プロキシとプロトコル ポッドの両方が再起動され、この新しい動作モードが有効になるか、UDP プロキシを介してメッセージ交換の以前のモードにフォールバックします。

CLI を使用したバイパス モードのトリガー

バイパス モードまたはプロトコル プロキシ マージの機能をトリガーするには、次に示すように、エンドポイント PFCP で VIP-IP を構成する必要があります。

no instance instance-id 1 endpoint protocol interface n4
no instance instance-id 1 endpoint protocol interface gtpu
instance instance-id 1 endpoint pfcp interface n4 vip-ip X.X.X.X
instance instance-id 1 endpoint pfcp interface gtpu vip-ip X.X.X.X

重要

上記の構成で、環境変数 UDP_PROXY_BYPASS の値が変更されます。これにより、ポッドの UDP プロキシとプロトコルの両方の再起動がトリガーされます。

endpoint+ protocol に存在するすべての機能は、対応するように endpoint+PFCP で構成する必要があります。これには、DSCP、SLA、ディスパッチャ関連の構成などの機能が含まれている必要があります。すべての機能の設定は、内部 VIP-IP がエンドポイント = PFCP およびインターフェイス N4 またはインターフェイス Sxa で構成されている場合にのみ有効になります。エンドポイント プロトコルの下に、インターフェイス N4 と VIP-IP、またはインターフェイス Sxa と VIP-IP が存在する必要があります。

CLI 値のレンダリング

N4 および Sxa VIP の構成に基づいて、レンダリング ロジックはエンドポイント プロトコルで公開する値を計算します。構成は、「endpointIp」というキーを持つポッドでレンダリングされます。個々のポッドの構成パスは、/config/AppName/vip-ip/endpointIp.yaml にあります。影響を受けるポッドは次のとおりです：

  1. プロトコル

  2. Node Mgr

  3. SMF-Service

  4. SGW サービス。

エンドポイント - pfcp 構成がエンドポイント - プロトコルの下でレンダリングされるようにすると、バックグラウンド構成読み取りロジックへの変更を回避できます

ノード管理

この場合、プロトコルはピアが接続するために PFCP エンドポイントを開始します。同時に、アプリ サービスが UPF に向けて PFCP メッセージを開始すると、UPF との接続も確立します。次のメッセージが含まれます：

  1. PFCP 関連付けのセットアップ要求/応答

  2. PFCP 関連付け更新要求/応答

  3. PFCP セッションレポート要求/応答

  4. PFCP ノード レポート要求/応答

  5. ハートビート要求/応答

  6. PFCP PFD 管理要求/応答

セッション管理

サービスによって開始され、プロトコル ポッドを介して UPF に直接送信されるセッション管理メッセージ。プロトコル ポッドは UPF との接続を開始してこれらのメッセージを送信します。これが、プロトコル ポッドが存在するノードの IP アドレスを取得するために「ホスト ネットワーキング」にある必要がある理由です。

標準化されたポート番号

「マージ」モードをトリガーしている間、プロトコル ポッドはホスト ベースのネットワーキングに移行します。プロトコル ポッドは、既存の UDP プロキシ ポッドと同様にホストまたはノードの IP アドレスを取得します。UDP プロキシ、GTPC-EP、およびプロトコルが同じポートを共有しないことが重要です。ポート計算のための経験的なルールは次のとおりです。 

Port_Value = Base_Port _Value + (Gr_Instance_Id_index *50) + (Logical_Instance_id mod 50)

Gr_Instance_id：CLI を使用して構成で提供される GR インスタンス ID。

Logical_Instance_id：論理 SMF インスタンスの識別子。

Prometheus ポート：

完全な UDP プロキシ バイパスでは、Prometheus ポート 8080 は使用されず、代わりにインスタンス 1 の Prometheus 8004 の開始ポートが使用されます。8003 で追加される「instance-Id」はポート番号である必要があります。

プロキシ キープアライブ ポート:

プロキシ キープアライブ ポートは、27500+ 「Instance-Id」から始まります。

  1. GR インスタンス 1 & 論理インスタンス ID 0：- 27500 +（0 * 50）+（0 % 50）= 27500

  2. GR インスタンス 2 & 論理インスタンス ID 0：- 27500 +（1 * 50）+（0 % 50）= 27550

キープアライブおよび活性プローブの管理ポート:

管理ポートは 7879 + (Gr_Instance_Id_index * 50) + (Logical_Instance_id mod 50) になります。

インフラ診断ポート:

Infra Diag ポートは、7779 + (Gr_Instance_Id_index * 50) + (Logical_Instance_id mod 50) になります。

PProf ポート:

PProf プロファイリング ポートは 7679 +（Gr_Instance_Id_index * 50）+（Logical_Instance_id mod 50）になります