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

機能の概要と変更履歴

要約データ

表 1. 要約データ

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

cnSGW-C

該当プラットフォーム

SMI

機能のデフォルト設定

有効、常時オン

関連資料

該当なし

マニュアルの変更履歴

改訂の詳細

リリース

初版

2020.07

機能説明

cnSGW-C は Kubernetes クラスタ戦略に基づいて構築されており、コンテナ化、高可用性、拡張性、モジュラ性、および展開の容易さというネイティブの概念を採用しています。cnSGW-C は、Kubernetes が提供するポッドやサービスなどのコンポーネントを使用します。

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

次のワークフローは、以下に関する概要レベルの情報を示しています。

  • ホストマシン

  • 関連するポッドとサービス

  • ポッド間の相互作用

表現は、使用している展開インフラストラクチャによって異なる場合があります。

図 1. ポッドの通信ワークフロー

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

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

ポッド

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

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

次の表に、cnSGW-C ポッドおよび共通実行環境(CEE)ポッドの名前と、割り当てたラベルに応じてそれらが展開されるホストを示します。ラベルの割り当て方法については、次の表を参照してください。

表 2. cnSGW-C ポッド
ポッド名 説明 ホスト名
api-sgw-ops-center cnSGW-C Ops センターの confD API ポッドとして機能します。 OAM
base-entitlement-sgw スマートライセンス機能をサポートするために動作します。 OAM

(注)  

 

現在サポートされていません。

bgpspeaker

L3 ルート管理および BFD モニタリングのダイナミックルーティングをサポートするために動作します。

プロトコル

cache-pod 必要に応じて他のポッドによって使用されるシステムキャッシュ情報をサポートするために動作します。 プロトコル
cdl-ep-session-c1 CDL へのインターフェイスを提供します。 セッション
cdl-index-session-c1 セッションポッドへのキーのマッピングを保持します。 セッション
cdl-slot-session-c1 セッションデータを保存する CDL セッションポッドとして動作します。 セッション
マニュアル ドキュメントが含まれます。 OAM
etcd-sgw-etcd-cluster ポッドインスタンス、リーダー情報、エンドポイントなどの情報を保存する cnSGW-C OAM アプリケーションの etcd をホストします。 OAM

georeplication

キャッシュ、サイト間での ETCD レプリケーション、およびサイトロールの管理をサポートするために動作します。

プロトコル

grafana-dashboard-app-infra Grafana の app-infra メトリックのデフォルトダッシュボードが含まれます。 OAM
grafana-dashboard-cdl Grafana の CDL メトリックのデフォルトダッシュボードが含まれます。 OAM
grafana-dashboard-sgw Grafana の cnSGW-C サービスメトリックのデフォルトダッシュボードが含まれます。 OAM
gtpc-ep-n0 cnSGW-C の GTPC エンドポイントとして動作します。 プロトコル
kafka CDL レプリケーションの Kafka の詳細をホストします。 プロトコル
li-ep-n0 cnSGW-C の合法的傍受エンドポイントとして動作します。 プロトコル
oam-pod show コマンド、configuration コマンド、モニター プロトコル モニター サブスクライバなど、Ops センターのアクションを促進するためのポッドとして動作します。 OAM
ops-center-sgw-ops-center cnSGW-C Ops センターとして機能します。 OAM
smart-agent-sgw-ops-center cnSGW-C Ops センターのユーティリティポッドとして機能します。 OAM
nodemgr-n0 Sxa リンクの確立と管理(ハートビート)など、ノードレベルの連携動作を実行します。

UE IP アドレスや SEID などの一意の識別子を生成します。

Service
protocol-n0 アプリケーションプロトコル(PFCP、その基礎となるトランスポートプロトコルは UDP)のエンコーダおよびデコーダとして動作します。 プロトコル
rest-ep-n0 cnSGW-C は、通知クライアントとして REST-EP を使用します。 プロトコル
service-n0 cnSGW-C の主なビジネスロジックが含まれます。 Service
udp-proxy すべての UDP メッセージのプロキシとして動作します。UDP クライアントおよびサーバーの機能を備えています。 プロトコル
swift-sgw-ops-center cnSGW-C Ops センターのユーティリティポッドとして機能します。 OAM
zookeeper トポロジ管理のために Kafka を支援します。 OAM

CEE ポッド

詳細については、『UCC 共通実行環境 - 構成および管理ガイド』の「CEE ポッド」のトピックを参照してください。

UDP プロキシポッド

機能説明

cnSGW-C には、UP(Sxa)、MME(S11)、および PGW(S5 または S8)に対する UDP インターフェイスがあります。プロトコルレイヤポッドを利用して、これらの UDP インターフェイス上でメッセージのエンコード、デコード、および交換が行われます。

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

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

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

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

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

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

cnSGW-C では、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)が実現されます。


(注)  


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

cnSGW-C 向けの UDP プロキシ機能は、仮想 IP アドレス機能と機能的な関連性があります。


アーキテクチャ

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

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

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

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

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

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

ピアが開始したメッセージのプロトコルポッドの選択

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

UDP プロキシの高可用性

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

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

サービス

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

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

表 3. cnSGW-C サービスとポッド
Service Name ポッド名 説明
base-entitlement-sgw base-entitlement-sgw スマートライセンス機能をサポートするために動作します。

bgpspeaker-pod

bgpspeaker

L3 ルート管理および BFD モニタリングのダイナミックルーティングをサポートするために動作します。

datastore-ep-session cdl-ep-session-c1 CDL セッションを担当します。
datastore-notification-ep smf-rest-ep smf-rest-ep を介して CDL から sgw-service に通知を送信します。

(注)  

 

cnSGW-C は、通知クライアントとして REST-EP ポッドを使用します。

datastore-tls-ep-session cdl-ep-session-c1 セキュアな CDL 接続を担います。
マニュアル マニュアル cnSGW-C ドキュメントを担当します。
etcd

etcd-sgw-etcd-cluster-0、

etcd-sgw-etcd-cluster-1、

etcd-sgw-etcd-cluster-2

名前空間内のポッド検出を担当します。
etcd-sgw-etcd-cluster-0 etcd-sgw-etcd-cluster-0 etcd クラスタ間のデータの同期を担当します。
etcd-sgw-etcd-cluster-1 etcd-sgw-etcd-cluster-1 etcd クラスタ間のデータの同期を担当します。
etcd-sgw-etcd-cluster-2 etcd-sgw-etcd-cluster-2 etcd クラスタ間のデータの同期を担当します。
grafana-dashboard-app-infra grafana-dashboard-app-infra Grafana の app-infra メトリックのデフォルトダッシュボードを担当します。
grafana-dashboard-cdl grafana-dashboard-cdl Grafana の CDL メトリックのデフォルトダッシュボードを担当します。
grafana-dashboard-sgw grafana-dashboard-sgw Grafana の cnSGW-C サービスメトリックのデフォルトダッシュボードを担当します。
gtpc-ep gtpc-ep-n0 GTP-C ポッドとのポッド間通信を担当します。
helm-api-sgw-ops-center api-sgw-ops-center Ops センター API を管理します。
kafka kafka Kafka メッセージを処理します。
li-ep li-ep-n0 合法的傍受の相互作用を担います。
local-ldap-proxy-sgw-ops-center ops-center-sgw-ops-center Grafana などの他のアプリケーションによる Ops センターのログイン情報の活用を担当します。
oam-pod oam-pod Ops センターでの Exec コマンドの促進を担当します。
ops-center-sgw-ops-center ops-center-sgw-ops-center cnSGW-C Ops センターを管理します。
ops-center-sgw-ops-center-expose-cli ops-center-sgw-ops-center 外部 IP アドレスで cnSGW-C Ops センターにアクセスします。
smart-agent-sgw-ops-center smart-agent-sgw-ops-center cnSGW-C Ops センター API を担当します。
smf-nodemgr smf-nodemgr smf-nodemgr ポッドとのポッド間通信を担当します。
smf-protocol smf-protocol smf-protocol ポッドとのポッド間通信を担当します。
sgw-service sgw-service cnSGW-C サービスポッドとのポッド間通信を担当します。
swift-sgw-ops-center swift cnSGW-C Ops センターのユーティリティポッドとして機能します。
zookeeper zookeeper トポロジ管理のために Kafka を支援します。
zookeeper-service zookeeper トポロジ管理のために Kafka を支援します。

オープンポートとサービス

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

表 4. オープンポートとサービス

Port

タイプ

Service

使用方法

22

tcp

SSH

SMI は、TCP ポートを使用して仮想マシンと通信します。

53

tcp

ドメイン

DNS ポート。

80

tcp

HTTP

SMI は、CLI、ドキュメント、および TAC への Web アクセスを提供するために TCP ポートを使用します。

111

tcp

rpcbind

オープン ネットワーク コンピューティング リモート プロシージャ コール。

179

tcp

bgp

Border Gateway Protocol(BGP)

443

tcp

SSL/HTTP

SMI は、CLI、ドキュメント、および TAC への Web アクセスを提供するために TCP ポートを使用します。

2379

tcp

etcd-client

CoreOS etcd クライアント通信。

6443

tcp

http

SMI は、ポートを使用して Kubernetes API サーバーと通信します。

7472

tcp

不明

Grafana で使用されるスピーカーです。

8083

tcp

us-srv

Kafka は REST インターフェイスに接続します。

8850

tcp

不明

udp-proxy

8879

tcp

不明

udp-proxy

9100

tcp

jetdirect

SMI は TCP ポートを使用してノードエクスポータと通信します。

ノードエクスポータは、プラガブル メトリック コレクタを備えたハードウェアおよび OS メトリック用の Prometheus エクスポータです。

これにより、メモリ、ディスク、CPU 使用率などのさまざまなマシンリソースを測定できます。

10250

tcp

SSL/HTTP

SMI は TCP ポートを使用して Kubelet と通信します。

Kubelet は Kubernetes の最下位コンポーネントです。個々のマシンで実行されている内容に関与します。

アクティブコンテナに注目するプロセスウォッチャまたはスーパーバイザです。指定されたコンテナが稼働していることを確認します。

10251

tcp

-

SMI は TCP ポートを使用して Kube スケジューラと対話します。

Kube スケジューラは Kubernetes のデフォルトのスケジューラであり、コントロールプレーンの一部として実行されます。スケジューラは、ノードが割り当てられていない新しく作成されたポッドを監視します。

スケジューラは、検出されたすべてのポッドに対して、そのポッドを実行するのに最適なノードを見つける責任を負います。

10252

tcp

apollo-relay

SMI は、この TCP ポートを使用して Kube コントローラと対話します。

Kubernetes コントローラマネージャは、Kubernetes に付属のコア制御ループを組み込むデーモンです。コントローラは、API サーバーを介してクラスタの共有状態を監視し、現在の状態を目的の状態に移行するための変更を行う制御ループです。

10256

-

HTTP

SMI は TCP ポートを使用して Kube プロキシと対話します。

Kube プロキシは、クラスタ内の各ノードで実行されるネットワークプロキシです。Kube プロキシは、ノードのネットワークルールを維持します。これらのネットワークルールにより、クラスタの内部または外部のネットワークセッションからポッドへのネットワーク通信が可能になります。

50051

tcp

不明

gRPC サービスリッスンポート。

53

udp

domain ISC BIND (Fake version:

9.11.3-

1ubuntu1.9-

Ubuntu)

DNS ポート

111

udp

rpcbin

オープン ネットワーク コンピューティング リモート プロシージャ コール

2123

udp

gtpc

GTP 制御

8805

udp

pfcp

パケット転送制御プロトコル(PFCP)

ノードへのポッドの関連付け

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

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

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

  1. ラベルを使用してポッドをノードに関連付けるには、次の設定を使用します。

    config 
     k8 
       label 
         cdl-layer   
           key key_value 
           value value 
         oam-layer   
           key key_value 
           value value 
         protocol-layer   
           key key_value 
           value value 
         service-layer   
           key key_value 
           value value 
           end 

注:

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

    • label { cdl-layer { key key_value | value value } :CDL のキーと値のペアを設定します。

    • oam-layer { key key_value | value value } :OAM 層のキーと値のペアを設定します。

    • protocol-layer { key key_value | value value } :プロトコル層のキーと値のペアを設定します。

    • service-layer { key key_value | value value } :サービス層のキーと値のペアを設定します。

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

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

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

ポッドの詳細

  1. 包括的なポッドの詳細を表示するには、次のコマンドを使用します。

    kubectl get pods -n sgw pod_name -o yaml 

このコマンドの出力には、次の情報を含む YAML 形式でポッドの詳細が提供されます。

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

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

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

  • ポッドの IP アドレス。

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

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

次のコマンドを使用して、ポッドの詳細の概要を表示します。

kubectl get pods -n sgw_namespace -o wide 

状態

次の表で、ポッドの状態について説明します。

表 5. ポッドの状態

状態

説明

Running

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

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

Pending

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

成功

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

失敗しました(Failed)

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