アドレスプールマネージャーの概要

アドレスプールマネージャーのメリット

• 効率性—アドレス利用の効率を向上させます。APMは、ネットワーク内の複数のBNGのアドレス割り当てを一元化し、自動化します。APMはジャストインタイムのプレフィックス割り当てを使用するため、BNGが追加のIPアドレスを必要とする場合にのみプレフィックスをプロビジョニングします。

  APMは、BNGが必要とする数のプレフィックスのみをプロビジョニングします。APMグローバルプールをプレフィックスのグループに分割した後、APMはBNGの要求に一致するようにプレフィックスをさらに細分化します。この細分化により、APMは割り当てるプレフィックスのサイズを最適化できます。

• 簡素化:各BNGを手動で監視してプロビジョニングするオーバーヘッドや複雑さを回避します。

• 容易な導入性:要件を満たすあらゆるハードウェアにインストールして運用します。

• 再利用可能性:使用中のプレフィックスを、IPアドレスをほとんど使用していないプールから中央のプールに再利用し、必要な他のプールに再配布します。

アドレッシング用語

IPアドレッシング、クラスレス ドメイン間ルーティング(CIDR)、可変長サブネットマスク(VLSM)、およびIPプレフィックスをサブネットワーク(サブネット)に分割する方法について十分に理解している必要があります。アドレス指定戦略を考案する場合 (このドキュメントの範囲外)、または手動アドレス再利用を使用する場合は、IP サブネット計算ツールを表示すると役立つ場合があります。そのような計算機はオンラインでたくさん見つけることができます。

このドキュメントでは、次の用語を使用します。

• プレフィックス—CIDR 表記を使用して表現された 32 ビットの IPv4 ネットワーク アドレスとプレフィックス長。たとえば、198.51.100.0/24 です。プレフィックスは、IP アドレスのネットワーク部分を定義します。プレフィックスはサブネットワークを表します。

• プレフィックス長—プレフィックスの長さとIPアドレスのネットワーク部分のサイズを決定するビット数。/24 プレフィックス長は、アドレスのネットワーク部分が 24 ビットであることを意味します。残りのビット(32ビットのうち)は、ネットワークアドレスのホスト部分を表します。プレフィックス長が /24 のプレフィックスの場合、ホスト部分は 8 ビットです(32 – 24 = 8)。

• ネットワーク サイズ - この用語は、文脈に応じて複数の異なる意味で使用されることがあり、あいまいさにつながる可能性があります。プレフィックス長と、それがサブネットワーク内のホストアドレス数にどのように対応するかを、次のように説明します。

  • プレフィックス長が長いほど、サブネットワークごとに割り当てるホストアドレスが少なく、サブネットワークが多くなります。

  • プレフィックス長が短いほど、サブネットワークごとに割り当てるホスト アドレスが多くなり、サブネットワークの数が減ります。

• 空きアドレスは、使用可能でサブスクライバーに割り当てられていないIPアドレスです。

APMの仕組み

APMは、ネットワーク内のBNGグループのIPプレフィックスの集中コレクションを維持します。APM CLI では、管理対象 BNG をエンティティとして参照します。このドキュメントでは一般に BNG という用語を使用しますが、このドキュメントでは エンティティという用語を使用する場合もあります。

APMは、プールドメインの作成をBNGと連携します。各プール ドメインは、BNG 上の特定のルーティング インスタンスの組み合わせのリンク アドレス プールに対応します。また、BNG CUPS コントローラでは、プール ドメインは、特定の加入者グループとルーティング インスタンスの組み合わせのリンク アドレス プールに対応します。プールドメインは動的に作成されるため、BNGとAPMの両方で、プールドメインのインスタンス化に必要な属性を含むプロファイルまたはテンプレートが維持されます。APMプロファイルには、配分、再利用しきい値、自動再利用動作などの属性が含まれています。BNG。プロファイルには、プレフィックスサイズやルート破棄インストール動作などの属性が含まれます。

APMi バージョン 1(Junos OS リリース 22.1R1 以降と互換性あり)。APMi のバージョンを確認するには、 show apm entity コマンドを実行します。

• しきい値とアラーム
• APMの一般的な操作

表 1: さまざまなアラームに対して APM が実行するアクション

	BNG から送信された時間アラームの説明
T0	—	入力されたプール ドメインを含むタイムラインの開始。
T1の	アラームを按分する	加入者がログインすると、BNG 上のフリー アドレスの数は配分しきい値を下回ります。BNG は配分アラームを送信します。APM は配分アラームを受信し、プレフィックスをプール ドメインに割り当てます。BNG は、プール ドメインのプール プレフィックスからアドレスを割り当てます。
T2の	アラームを按分する	APM は配分アラームを受信しますが、パーティションに使用可能なプレフィックスがありません。アラームは NACK され、再試行タイムスタンプは 15 分後に設定されます。BNG は、アドレスが不要になるまで、このタイムスタンプで割り当てアラームを再試行します。
T3の	アラームを按分する	再試行タイムスタンプで、フリー アドレスの数がまだ割り当てしきい値を下回っているため、BNG は割り当てアラームを再送します。
T4の	アラームの再利用	サブスクライバーは、空きアドレスの数が再利用しきい値を超えるまでログアウトを続けます。BNG は、再利用する推奨プールを含む再利用アラームを送信します。APM は提案されたプールにドレインを配置し、BNG はプールでドレイン プロセスを開始します。
T5の	プールドレインアラーム	アドレス プールの加入者が 0 の場合、プール内に割り当てられたアドレスはありません。BNG はプール ドレイン アラームを APM に送信します。APMは、削除リクエストでプールドレインアラームに応答します。BNG は、プール ドメインのプール リストからプールを削除します。APMは、再割り当てのために、対応するプレフィックスをパーティションに戻します。 プールを削除すると、空きアドレスの数は減少します。
T6の	アラームの再利用	APM は再利用アラームを受信しますが、アラームは再利用ウィンドウ外で発生したため、アクションを実行しません。APMは、再試行タイムスタンプが再利用ウィンドウの開始時刻に設定されたアラームNACKを返します。BNG は、まだ空きアドレスが余っている場合、この時点で再利用アラームを再試行します。

次の手順では、APM の一般的な操作について説明します。

1. BNGとAPMは、ジュニパー定義のgRPCベースのプロトコルであるAPMiを使用して通信します。Google RPC(gRPC)は、拡張可能で相互運用可能な通信プロトコルを構築するための共通フレームワークです。最初の接続時に、BNG はプール ドメインの同期を開始します。プールドメインの同期プロセスでは、アクティブなプールドメインのセットが同期されます。APMは、アクティブなプールドメインのリストをBNGのプールドメインのリストに合わせます。プール ドメインの同期後、BNG はプール ドメインごとにプールの同期(ディスカバリ)を実行します。APMは、各ドメインのプールのリストをBNGのリストに合わせます。APMが追加のプールを保持している場合(BNGのドメインのプールリストにない場合)、プールプレフィックスはパーティションに解放されます。APMにプールがない場合、APMはプールの割り当てを試みます。

2. APM は、BNG から送信されるアラーム メッセージを監視します。

3. APMはアラームを評価し、それに基づいて処理します。例えば、BNGのアドレスが不足している場合、BNGはAPMに按分アラームを送信します。APMは、ドメインのソースパーティションから要求された数のプレフィックスを割り当て、アラーム応答で返します。BNG は、これらのプール プレフィックスをプール ドメインに追加します。

図 1 は、1 つの APM インスタンスのさまざまな機能コンポーネント間の関係をより詳細に示しています。各マネージャ ブロックには、使用するデータベース テーブルが表示されます。

手記：

ネットワーク内の複数の異なるクラスタで、APMの複数のインスタンスを同時に実行できます。APMのこれらのインスタンスは独立しており、互いに認識されていません。インスタンスは状態や構成を共有しません。

各APMインスタンスには、アプリケーションの機能コンポーネントとして次のマイクロサービスが含まれています。

• エンティティ マネージャー:管理下にある BNG のプール管理アクティビティを調整します。これらのアクティビティには、アラームの処理、プールプレフィックスの割り当てと再利用が含まれます。

• アドレス マネージャー:アドレスの中央プールをパーティションに編成し、各パーティションに設定されたルート プレフィックスの割り当てを管理します。ルート プレフィックスをより小さいプレフィックスに細分化し、BNG に設定された基準に従ってプレフィックスを割り当てます。

• プロビジョニング マネージャー:BNG とインターフェイスし、プール ドメインとそれに関連付けられたアドレス プールをプロビジョニングします。プロビジョニング マネージャは、ドメインと関連する割り当て済みプール プレフィックスが APM と BNG 間で同期された状態を維持するようにします。

  APMプロビジョニングマネージャーは、APMiを使用して管理対象BNGと通信します。プロビジョニング マネージャーは gRPC メッセージを送信し、BNG によって開始されるドメイン アラームに応答して、BNG のプレフィックスを直接プロビジョニングおよびプロビジョニング解除します。

• MGMTマイクロサービスには、テキストベースの設定スキーマとCLIが用意されているため、グローバルプレフィックスプール、マネージドBNG、およびそれらに関連付けられたプールドメイン属性を設定できます。CLI を使用して、さまざまな機能コンポーネントの統計情報と状態を表示できます。出力は、システム負荷、効率、使用率、およびエラーまたは異常な状態に関する情報を提供します。

• ブロードバンドエッジ(BBE)イベントの収集と可視化(クラウドベースの集中型ユーティリティ)—APMマイクロサービスのライフサイクルにわたるAPMログをキャプチャする方法を提供します。このユーティリティは、APMマイクロサービスのインスタンス間でログを収集して保存します。

• データベースインスタンス(DB)—APMの各機能コンポーネントが使用するデータベーステーブルへの共有アクセスを提供します。データベースには、アドレス、BNG、およびプール ドメイン情報のテーブルが含まれています。データベースは、構成情報と運用状態のための永続ストレージを提供します。

  APMは、エンティティ、プールドメイン、プール、プレフィックス、割り当て、構成などに関する状態情報を含むデータベースを採用しています。2つのデータベース・インスタンス(プライマリおよびスタンバイ)は、ホット・スタンバイ・モードでデプロイされます。データベースインスタンスは、プライマリデータベースの障害を検出するデータベースセンチネルサービスによって監視されます。1 次データベースに障害が発生すると、新しいスタンバイ・データベースがリストアされる間、2 次データベースが 1 次データベースの役割を引き継ぎます。

  手記：

  冗長性には、プライマリ・ノードに加えて、少なくとも3つのワーカー・ノードが必要です。ワーカー・ノードは、すべて別々の物理サーバー上にある必要があります。ただし、ノードは物理マシンでも仮想マシンでもかまいません。

CLIおよび構成管理

ユーザーインターフェイス(MGMT)は、Junos OS管理プロセスのコンテナ化されたバージョンです。このインターフェイスでは、設定と監視に Junos OS と同じ CLI 構造を使用できます。MGMT は、APM をリモートで管理できるインターフェイスも提供します。

APMは、次のタスクを実行します。

• 他のAPMコンポーネントがランタイム状態に進む前に、管理サービスからデータベースに初期APM設定を読み込みます。

• コマンドと構成を、APMマイクロサービスが理解できるアクションとパラメーターに変換します。

• 初期設定とその後の変更をデータベースに記録し、永続化します。変更があれば、APMコンポーネントに通知します。

エンティティマネージャー

エンティティー・マネージャーは、エンティティーの状態に影響を与える他の機能コンポーネントの操作を調整します。

管理下にある各 BNG について、エンティティー・マネージャーは以下の情報を追跡します。

• BNG アドレスは、管理対象プールをホストする BNG のトランスポート アドレスです。

• 管理対象のプールドメインのリスト。

プールドメインは、BNG上のリンクされたアドレスプールを表します。エンティティーマネージャーは、プールドメインごとに、次の情報を追跡します。

• プール ドメイン名 - BNG の管理対象プールを識別するユーザー定義の文字列。各プール ドメイン名は、その BNG に対して一意である必要があります。つまり、プールのドメイン名は実質的にキーとして機能します。これは、プールドメインキーと呼ばれることもあります。エンティティによって構築されたユーザー定義の文字列。BNG の場合、文字列はルーティング インスタンス名にリンクされたドメイン プロファイル名で構成されます。BNG CUPS コントローラの場合、文字列は加入者グループ名およびルーティングインスタンス名にリンクされたドメインプロファイル名で構成されます。

• APMは、 pool-domain-name-sequence-number の形式を使用して、作成するプールに名前を付けます。 sequence-number は 4 桁以上で、値が 1,000 未満の場合、シーケンス番号の先頭に 0 が埋め込まれます。したがって、0001、0999、1000、213339は有効なシーケンス番号です。たとえば、プール・ドメインの名前がtest-pdの場合、APMは最初のプールにtest-pdという名前を付けます。後続のプールには、test-pd-0000、test-pd-0001 などの名前が付けられます。

• [プレフィックス(Prefixes)]:プール ドメインを構成するプレフィックスの順序指定リスト。

エンティティーマネージャーは、プールドメインに対するさまざまな操作 (最終ディスカバリー、最終割り当て、最終再利用など) について、多数の揮発性統計を収集します。統計情報には、アラーム数、プールの数、関連するプレフィックス、タイムスタンプが含まれます。これらの統計は、show apm entityなどのAPMshowコマンドで表示できます。

エンティティ マネージャーは、プロビジョニング マネージャーが BNG からエンティティ マネージャーに配分アラームをリレーするときに、アドレス マネージャーにプール ドメインの新しいプレフィックスを要求します。

プレフィックス要求には、次の情報が含まれます。

• アドレス ファミリー—現在 IPv4 をサポートしています

• [Allocation key]:管理対象 BNG の IP アドレスとプール ドメイン

• [Requested prefix length]:パーティションからプール ドメインに割り当てるプレフィックスのサイズ。

続いて、エンティティーマネージャーは、割り当てられたプレフィックスを BNG のアドレスプールにプロビジョニングしようとします。

エンティティマネージャは、プロビジョニングマネージャがBNGに到達可能であることをエンティティマネージャに通知すると、管理下のBNGプールドメイン(同期)を検出して調整するプロセスを開始します。プロビジョニングマネージャーは、到達可能性の状態が変化するたびに、エンティティマネージャーに到達可能性レポートを送信します。エンティティー・マネージャーは、その BNG で管理されているすべてのプール・ドメインのディスカバリーを要求します。

検出プロセスでは、プロビジョニング インターフェイスを使用して、BNG が認識するプール ドメインと関連するプール情報を検索します。ディスカバリープロセスの最後に、APMとBNGは同じプールドメインと割り当てられたプールプレフィックスを持ちます。

検出された情報が既存の情報と一致しない場合、APMは(BNGと一致するように)プールドメインのパーティション情報でデータベースを更新します。APMは、更新中にコンフリクトを検出すると、ログに警告としてコンフリクトのフラグを立てます。

アドレスマネージャー

アドレス マネージャーは、VLSM アルゴリズムを使用して、アドレス プール パーティション内のルート プレフィックスを、各ルート プレフィックスに設定した max-prefix-len 値まで、より小さなサブプレフィックスに分割します。割り当て中、アドレス マネージャーは、適切なサイズのプレフィックスの要求をパーティションとルート プレフィックスと照合します。APMは、割り当てイベントを満たすために、ルートプレフィックスから空きサブプレフィックスを割り当てます。

アドレス マネージャーは、パーティション内の空きアドレスの割合が free-prefix-utilization しきい値を下回ると、警告メッセージをログに記録します。このしきい値を超えると、パーティションに非常に多くのアドレスが割り当てられているため、アドレスが不足する危険性があることを示します。

APMを設定する場合、ルートプレフィックスをパーティションに割り当てます。アドレス マネージャーは、任意のドメインに対して 1 つのパーティションからのみプレフィックスを割り当てます。各パーティションは、割り当てコンテキストを表します。アドレス マネージャーは、ドメインに設定したバイアスを使用して、ドメインに割り当てるプレフィックスを分割するパーティションを選択します。

パーティションにルートプレフィックスを追加するときは、そのパーティションに指定された最小プレフィックス長と最大プレフィックス長の制限内に収まることを確認してください。

• min-prefix-len値は、有効な最短のルート プレフィックスです。

• max-prefix-len値は、有効な最長のルート プレフィックスです。

したがって、 min-prefix-len <= ルート プレフィックス長 <= max-prefix-len です。

たとえば、 min-prefix-len が 20、 max-prefix-len が 24 の場合、プレフィックス長が /20、/21、/22、/23、または /24 のルート プレフィックスを追加できます。

プレフィックス長が短いほど、サブネットで使用できる個々のホストアドレスが多くなります。プレフィックス長が長くなるほど、サブネット内で使用可能な個々のホストアドレスは少なくなります。例えば：

• プレフィックス長を /20 にすると、4,094 個の使用可能なホスト アドレスが提供されます。

• プレフィックス長が /24 の場合、254 個の使用可能なホスト アドレスが提供されます。

手記：

指定された制限外にあるルートプレフィックスを設定した場合、APMはそれをパーティションに追加しません。

• 接頭辞サブディビジョン(Prefix Subdivision)
• プレフィックスの割り当て
• VLSMの
• VLSM の例

プロビジョニングマネージャー

プロビジョニング マネージャーは、次のプロビジョニング操作を管理するワーカー プロセスで構成されます。

• ディスカバリー:APMとBNGの間でプールドメインと関連するプール情報を同期します。ディスカバリープロセスの最後に、APMとBNGはプールドメインと割り当てられたプールプレフィックスのリストに同意します。

  APMの動作—APMは、APMリストがBNGのリストと一致するように、プールドメインをBNGのリストと調整します。リコンシリエーション中に削除されたドメインのプールプレフィックスは、関連付けられたプールプレフィックスが元のパーティションに戻されます。

  プロビジョニング マネージャーは、接続障害後に再確立された接続を含め、APM がマネージド BNG との接続を確立するたびに検出を実行します。接続がダウンしている間、管理者は BNG の設定を変更できます。APMは、その後の検出中に変更を検出すると、それに応じて調整します。

• プロビジョニング:管理 BNG のプレフィックスをプロビジョニングおよびプロビジョニング解除します。アドレス マネージャーがプレフィックスの割り当てを管理している間、プロビジョニング マネージャーは BNG と通信してアドレス プールをプロビジョニングします。

接続が復元されると、プロビジョニング・マネージャーはエンティティー・マネージャーに BNG に到達可能であることを通知します。エンティティーマネージャーは、プロビジョニングマネージャーに同期プロセスを開始するように要求します。

プレフィックスの自動再利用

APMを有効にして、再利用のタスクを自動的に処理できます。entity-match ステートメントで設定されたように、エンティティに割り当てられたpool-domain-profileで自動再利用を構成できます。

自動再利用を有効にすると、次のアクションが実行されます。

• APMは、エンティティから送信されたドメイン再利用アラームに応答します。再利用アラームには、再利用するプール名の候補が含まれています。

• APMは、プールにアクティブドレインを配置するようにエンティティに指示することで、再利用アラームに応答します。プールが完全にドレインされた場合(プールからの未処理のアドレス割り当てがない場合)、エンティティはドメイン プールのドレイン アラームを発生させます。

• APMは、プールを削除するようにエンティティに指示することで、プールが枯渇したアラームに応答します。APMは、プールプレフィックスを割り当てられたパーティションに戻します。

• プレフィックスがパーティションに返されると、ドメイン割り当てアラームを発生させる他のエンティティが使用できるようになります。

自動再利用により、エンティティで保持される未使用のアドレスの数を制限できます。自動再利用プロセスには、アクティブ ドレインに影響を与える可能性のあるサービスが含まれるため、構成されたメンテナンス ウィンドウ中にのみ自動再利用を開始するように APM を構成できます。

エンティティに割り当てられたプレフィックスの解放

ネットワーク エンティティに障害が発生し、APM に再接続して、割り当てられたプール プレフィックスをソース パーティションに再利用できない場合は、request apm release entity system-id コマンドを使用できます。このコマンドは、ネットワーク エンティティに関連付けられているすべてのプール プレフィックスとプール ドメインの割り当てを解除します。エンティティの APMi 状態が reachable の場合は、request apm release entity system-id コマンドを使用できません。

到達不能なエンティティからプレフィックスを解放するには、次の手順を使用します。

1. show apm entity system id コマンドを使用して、エンティティの到達可能性ステータスと、そのプールドメインが保持するプールプレフィックスを表示します。出力は、エンティティが到達可能であり、3つのプールプレフィックスが割り当てられていることを示しています。

2. エンティティが到達可能な場合、 request apm release entity system id コマンドは失敗します。

3. show apm entityを入力して、エンティティが到達不能かどうかを確認します。

4. ステップ 3 のエンティティは到達できないため、 request apm release entity system-id コマンドを入力して再利用を開始できます。APMはプールをプロビジョニング解除し、再割り当てのためにアドレスをソースパーティションに戻します。ステップ 1 で報告されたすべてのプール プレフィックスが解放されます。

アドレスの手動再利用

手動再利用により、きめ細かな制御が可能です。手動再利用では、マネージド BNG のプール ドメインとアドレス プールを綿密に監視する必要があります。

1. show apm alarms コマンドを使用して、BNG から受信した保留中のアラームをすべて表示します。出力には、アラームステータスがreclaimプールの名前が表示されます。

   reclaimアラームは、プールドメインにアドレスが余っていることを意味します。Infoフィールドには、BNG が再利用を推奨するプールの名前が含まれます。再利用アラームは、プールにアクティブなドレイン セットがあることを意味するものではありません。プールにドレインが設置されていない場合でも、プールはアドレスを割り当てることができます。

2. request apm drain コマンドを発行して、プールのドレインを開始します。
   手記：

   request apm activate コマンドを発行することにより、開始したドレーンを除去できます。

3. show apm alarms コマンドを使用して、プールがドレインされたことを確認します。アラーム ステータスには、pool-drained ステータスが表示されます。
4. request apm reclaim コマンドを発行して、レクラメーション処理を開始します。APMはプールをプロビジョニング解除し、再割り当てのためにアドレスをソースパーティションに戻します。

手動再利用を選択する場合は、再利用するプールの選択に注意してください。ここでは、再利用するプールを選択する際の考慮事項をいくつか紹介します。

• プールをドレインする場合は、プールドメイン内の他のプールにあるそれらのアドレスを使用するサブスクライバーに対応する必要があります。(ドメイン内の)他のプールには、これらの加入者を吸収するのに十分な空きアドレスが必要です。したがって、プールドメイン内の空きアドレスの数は、ドレインするプール内の使用済みアドレスの数より大きくする必要があります。

  (プール・ドメイン・フリー・アドレス) –(ドレイン・プールのフリー・アドレス)>(ドレイン・プールの使用済みアドレス)

• プールをドレインするときは、プール ドメインを空きアドレス不足の差し迫った危険にさらさないでください。ドメイン内のフリーアドレス数が配分しきい値を下回ると、配分アラームがトリガーされ、APMはプールにより多くのアドレスをプロビジョニングします。言い換えれば、次の不等式が当てはまらない限り、プールのドレインを開始しないようにしてください。

  (プール ドメインの空きアドレス)–(プールの合計アドレスの排出)>(割り当てしきい値)

タイムスタンプ

show apm entityコマンドを使用して、APMの再利用操作を監視します。ルーターまたは特定のプール ドメインの統計情報を表示すると、コマンド出力に、最終ディスカバリ、最終割り当て、および最終レクラメーション イベントのタイムスタンプが表示されます。タイムスタンプは ISO-8601 形式で、24 時間表示です。

YYYY-MM-DDThh:mm:ssZ

• T は、日付と時刻の間の区切り文字です。

• Z は、時刻が UTC タイム ゾーンであることを示します。ルーターの時刻が別のタイム ゾーンを使用する場合、形式はタイム ゾーンを識別するために UTC からのオフセットを示します。

• UTC より西のタイム ゾーンには、–hh:mm で指定される負のオフセットがあります。

• UTC より東のタイム ゾーンには、+hh:mm で指定された正のオフセットがあります。

たとえば、次のタイムスタンプは、標準時間を前提として、すべて同じ時刻を示しています。

• 2020–03–20T15:10:25Z (ロンドン)

• 2020–03–20T10:10:25-05:00 (ニューヨーク)

• 2020–03–20T16:10:25+01:00 (パリ)

• 2020–03–20T23:10:25+08:00 (北京)

APMでプロビジョニングされたKubernetesオブジェクト

APMは、起動時またはロールアウト時に次のKubernetesオブジェクトを作成します。APMは、ライフサイクル全体を通じてこれらのオブジェクトを使用します。オブジェクトは apm stopで削除されます。

• 名前空間—APMを実行しているノードマシンの仮想クラスタ。すべてのAPMオブジェクトはjnpr-apmで分離されています。

• 外部サービス—オブジェクトはセットアップ時に作成され、クラスターのロードバランサー(イングレスコントローラー)によって割り当てられた外部IPアドレスを取得します。クラスタ外の外部サービスは、これらの外部IPアドレスを使用してAPMとの通信を開始します。クラスタがネットワーク・ロード・バランサをサポートしていない場合、クラスタはプライマリ・ノードを外部IPアドレスとして使用します。

• ConfigMap - データベース サーバー用の構成ファイル(redis.conf)と MGMT 用の初期構成ファイル(juniper.conf)を格納します。

• PersistentVolumeClaims - 動的なデータストレージ要件を持つコンテナの場合。このオブジェクトには、管理とデータベースのデプロイが含まれます。

• シークレット—APMi を保護するために必要なキーと証明書を格納します。