システム要件—ArcGIS Enterprise on Kubernetes

ArcGIS Enterprise on Kubernetes 11.3 を実行するために必要な最低限のハードウェアおよびインフラストラクチャについて以下に説明します。これらの要件は、インターネット非接続環境にデプロイする場合にも適用されます。

サポート環境

システム要件および仕様は、注意書きがない限りサポートされているすべての環境に適用されます。このリリースでは、次の環境がサポートされています。

Kubernetes クラスターでは、自動アップグレードを無効にすることをお勧めします。自動アップグレードが有効になっている場合は、ノードが最新バージョンの Kubernetes に自動的に更新されますが、これらの将来のバージョンは ArcGIS Enterprise でまだサポートされていない可能性があります。

注意:

完全な互換性とサポートを保証するには、Kubernetes バージョンがサポートされている範囲内にあることを確認してから ArcGIS Enterprise on Kubernetes をアップグレードします。

各環境の次のバージョンはテスト済みで、サポートされています。


サポートされている環境	サポートされている Kubernetes バージョン
クラウド上のマネージド Kubernetes サービス (AKS、EKS、GKE) Red Hat OpenShift Container Platform (ROSA と ARO を含む) [4.14] RKE および RKE2	1.27 - 1.29

注意:

ArcGIS Enterprise on Kubernetes は、x86_64 アーキテクチャ (64 ビット) に準拠した CPU のみでサポートされています。ワーカーノードは Linux ベースである必要があります。

コンテナーレジストリ

ArcGIS Enterprise on Kubernetes のコンテナーイメージには、プライベートの Docker Hub 組織からアクセスできます。 Esri は、ArcGIS Enterprise on Kubernetes をデプロイしているユーザーにこの組織のリポジトリへのアクセス権を提供します。非接続環境にデプロイする場合は、プライベートの Docker Hub 組織から、自分のクラスターからアクセスできる独自のプライベートコンテナーレジストリへイメージをプッシュする必要があります。

Esri ライセンスの取得

デプロイ時に ArcGIS Enterprise 組織を認証するには、JSON 形式 (.json ファイル) の ArcGIS Enterprise on Kubernetes ライセンスファイルが必要です。このライセンスファイルを取得するには、ライセンスアクションを実行する権限を使用して My Esri にアクセスします。

ワーカーノード

ArcGIS Enterprise on Kubernetes は、3 つのアーキテクチャプロファイルのいずれかを使用してデプロイされます。リソース (CPU とメモリ) の要求と制限および全体的な計算要件の推奨事項は、選択したプロファイルによって異なります。各プロファイルの推奨事項を以下に示します。

各アーキテクチャプロファイルの最小ノード要件は以下のとおりです。組織でワークロードのスケーリングと機能の有効化をサポートするには、追加のワーカーノードが必要です。

各ワーカー/エージェントノードには、8 CPU および 32 GiB のメモリ以上を推奨します。 ArcGIS Enterprise on Kubernetes に関連付けられたコンテナーイメージのダウンロードを補完するために、100 GiB 以上のルートディスクサイズも推奨します。


アーキテクチャプロファイル	最小ワーカー/エージェントノード	最小 CPU の合計	最小 GiB の合計
Enhanced availability	5	40	160
Standard availability	4	32	128
開発	3	24	96

ArcGIS Enterprise on Kubernetes デプロイメント内のポッドは、クラスター内のワーカーノード全体に分散しています。ワーカーノードのクロックを共通のソースと同期させ、クラスター内で時間の一貫性を保つ必要があります。デプロイメントをスケーリングする場合や、別の ArcGIS Enterprise デプロイメントをクラスターに追加する場合は、ハードウェアを適切にプロビジョニングする必要があります。これには、ノードあたりの最大ポッド数のデフォルト値を増やす必要がある場合があります。最初に作成されるポッドの数は、アーキテクチャプロファイルによって異なります。水平方向にスケールするか、機能を追加すると、ポッド数が増加します。

セキュリティ

以下に、ArcGIS Enterprise on Kubernetes のセキュリティ要件を説明します。

ロールベースのアクセス制御

Kubernetes クラスターでロールベースのアクセス制御 (RBAC) が有効になっている必要があります。 ArcGIS Enterprise on Kubernetes のデプロイでは、cluster-admin 権限は必要ありません。 cluster-admin 権限がない場合、ユーザーは最小の名前空間管理権限を持っている必要があります。名前空間に RoleBinding を作成することで、ユーザーにデフォルトの ClusterRole を割り当てることができます。詳細については、RBAC ロールのリソースをご参照ください。

データフォルダーの登録

ファイルベースのデータ (ファイルジオデータベースから公開されたアイテムなど) を使用してアイテムを公開するには、データを NFS で共有された位置に配置する必要があります。データの公開中にデータがサーバーにコピーされないよう、この NFS 共有を ArcGIS Enterprise 組織に登録する必要があります。共有フォルダーを正常に登録するには、他のユーザーにファイルレベルの読み取り権限を付与する必要があります。ポッドの IP 範囲へのネットワークアクセスを許可することで、ネットワークまたはインフラストラクチャレベルで NFS 共有を保護できます。

ネットワーク

ネットワーク要件には、完全修飾ドメイン名 (FQDN) と、ロードバランサーまたはリバースプロキシ (クライアントからのトラフィックを標準の HTTPS ポート (443) 経由で構成済みのバックエンドターゲットへ転送する) が含まれます。それぞれの詳細を以下に示します。

完全修飾ドメイン名

ArcGIS Enterprise on Kubernetes は FQDN (たとえば map.company.com) が必要です。既存のドメイン名システム (DNS) サービスを使用して CNAME または A レコードを作成するか、クラウドプロバイダーの DNS サービス (Amazon Route 53 など) と統合できます。デプロイメント後に DNS レコードを作成できますが、デプロイメントプロセス中に FQDN が指定されている必要があります。このリリースでは、デプロイ後に FQDN を変更することはできません。

ロードバランサー

ロードバランサーを使用して、トラフィックを ArcGIS Enterprise on Kubernetes デプロイメントに転送できます。レイヤー 4 とレイヤー 7 両方のロードバランサーをデプロイメントスクリプトからプロビジョニングできます。手動による構成は不要です。デプロイメントスクリプトに基づいてデプロイメントと統合されているロードバランサーは、トラフィックをクラスター内 NGINX Ingress コントローラーのポッドへ直接ルーティングします。

または、着信トラフィックがデプロイメントのワーカーノードの特定のポートに送信される必要がある配置へトラフィックをルーティングするために、ArcGIS Enterprise on Kubernetes Web Adaptor を使用することもできます。

次のレイヤー 4 ロードバランサーをデプロイメントスクリプトからプロビジョニングできます。手動による構成は不要です。

Azure Load Balancer (パブリック向けまたは内部向け) - プロビジョニングされる静的なパブリック IP アドレスおよび DNS ラベルは、デプロイメントスクリプトで指定できます。
AWS Network Load Balancer (インターネット向けまたは内部向け) - その他のロードバランシングサービスを使用できます。ただし、クラスターノードごとに手動で構成する必要があります。
注意:
パブリックまたはプライベートサブネットにネットワークロードバランサーを作成するには、AWS Load Balancer Controller アドオンが必要です。
Google Cloud Platform TCP Load Balancer (インターネット向けまたは内部向け) - プロビジョニングされる静的なパブリック IP アドレスは、デプロイメントスクリプトで指定できます。

上で指定されたロードバランサーは、基になる Kubernetes サービスオブジェクトのアノテーションを使用してカスタマイズできます。たとえば、AWS の Network Load Balancer でクロスゾーン負荷分散を有効にしたり、Azure Blob Load Balancer を特定のリソースグループに配置したりできます。デプロイメントスクリプトに付属している deploy.properties テンプレートファイルに、サイレントデプロイメント時にこれらのアノテーションを指定する方法の例が記載されています。

デプロイメントスクリプトを使用して、Web アプリケーションファイアウォールなどのレイヤー 7 負荷分散機能を使用したり、既存の Ingress コントローラーを使用する配置されたアプリケーションへの Ingress に関する組織の要件を満たしたりすることができます。次のレイヤー 7 ロードバランサーをデプロイメントスクリプトから直接デプロイまたは統合することができます。

AWS Application Load Balancer
注意:
パブリックまたはプライベートサブネットに Application Load Balancer を作成するには、AWS Load Balancer Controller アドオンが必要です。
Azure Application Gateway
Google Cloud Platform Application Load Balancer

クラスターレベルで実装される Ingress コントローラーは、これらのロードバランサーを使用することで、着信トラフィックを ArcGIS Enterprise on Kubernetes デプロイメントへルーティングするためのクラスターレベルの Ingress ルールを実装します。サイレントデプロイの前にデプロイメントスクリプトからこれらのロードバランサーを実装するには、layer-7-templates フォルダー内のテンプレート YAML ファイルを修正してクライアントワークステーションに保存し、CLUSTER_INGRESS_CONTROLLER_YAML_FILENAME パラメーターにこの場所を指定できます。詳細については、「クラスターレベルの Ingress コントローラー」をご参照ください。

セルフマネージドロードバランサーまたは NGINX などのリバースプロキシを使用している場合は、トラフィックが ArcGIS Enterprise 組織の URL に正しくルーティングされるようにX-Forwarded-Host ヘッダーを、クライアントに接続する URL の Host ヘッダーの値に設定する必要があります。 NGINX の場合、これは proxy_set_header X-Forwarded-Host $host; ディレクティブを使用して実現できます。

注意:

ArcGIS Enterprise は、リバースプロキシ/ロードバランサーを通じた SSL オフロードをサポートしていません。リバースプロキシが構成で使用されている場合、HTTPS を通じて ArcGIS Web Adaptor にリダイレクトするか、組織に直接リダイレクトする必要があります。

IP 要件

正常なデプロイメント、適切なスケーリング要件、アップグレード機能を確保するためには、クラスターネットワークを事前に計画することが必要です。 ArcGIS Enterprise on Kubernetes が最初にデプロイするポッドの数は、アーキテクチャプロファイルに応じて 47 ～ 66 個です。機能の追加、デプロイメントのスケーリング、アップグレード処理に伴い、ポッドの数が増加します。

各ポッドには一意の IP アドレスが割り当てられます。また、クラスターネットワークの構成に応じて、ポッドは、ホストネットワーク (オーバーレイネットワーク) とは論理的に異なるアドレス空間から、またはホストサブネットから IP アドレスを取得できます。たとえば、Azure で Kubernet を使用するようクラスターを構成した場合 (デフォルト)、ポッドは論理的に異なるアドレス空間から IP アドレスを取得し、NAT を使用して Azure リソースにアクセスできるようになります。

Kubernetes は CNI (Container Network Interface) と、プラットフォーム固有の CNI プラグインをクラスターネットワークで使用するプラットフォーム (AKS や EKS など) をサポートしています。たとえば、EKS クラスターはデフォルトで VPC (Virtual Private Cloud) CNI を使用します。クラスターに CNI プラグインが構成されている場合、ポッドは、ホストサブネットと、VPC/VNet で利用可能な対応 IP プールから IP アドレスを取得します。

ホストサブネットで使用できる IP の数が十分ではない場合、デプロイメントは失敗するか、デプロイメントをスケーリングできません。たとえば、EKS クラスターにそれぞれ 2 個のサブネットと /26 IPv4 アドレス接頭辞 (それぞれ 64 個の IPv4 アドレスを使用可能) が構成されている場合、ポッドで使用できる IP アドレス数は 126 個を超えることはできません。このクラスターに ArcGIS Enterprise on Kubernetes をデプロイできますが、80 個のフィーチャサービスポッドを持つようこのデプロイメントをスケーリングすることはできません。このスケーリング要件では、利用可能な IP アドレスの数を超過してしまいます。

システムストレージ

ArcGIS Enterprise on Kubernetes では、システムストレージとして永続ボリューム (PV) が必要です。PV は、ストレージクラスによって動的にプロビジョニングすることも、組織を作成する前に管理者が静的にプロビジョニングすることもできます。静的プロビジョニングと動的プロビジョニングの詳細

ArcGIS Enterprise のステートフルワークロードには、リレーショナルデータベース管理システムと NoSQL データベースが含まれます。 EBS ボリューム (EKS の使用時)、Azure ディスク (AKS の使用時)、Persistent Disk (GKE の使用時)、vSphereVolume または Longhorn ボリューム (セルフマネージドクラスターへのデプロイメント時) など、低遅延のブロックストレージデバイスで PV をプロビジョニングすることをお勧めします。

これらの PV は組織のデータと設定を格納するため、制限付きセキュリティポリシーを使用して保護する必要があります。 NFS、Azure ファイル、GlusterFS など、ネットワークファイルストレージに基づく PV の場合、不正なアクセスを防ぐように権限が設定されていることを確認します。 EBS、Azure ディスク、vSphereVolume、Longhorn ボリュームなどのブロックストレージの場合、ストレージボリュームへのアクセスが、そのアクセスを必要とするユーザーのみに制限されていることを確認します。

ストレージボリュームの説明と使用目的は次のとおりです。

注意:

11.3 の永続ボリューム要件が記載されており、前のバージョンとは異なる可能性があります。

インメモリ - 一時システムリソースを格納します。
アイテムパッケージ - 公開ワークフローをサポートするサイズの大きいアップロードとパッケージを格納します。
オブジェクト - アップロードおよび保存されたコンテンツ、ホストタイル、画像、シーンレイヤーのキャッシュ、およびジオプロセシングの出力を格納します。
キュー - 非同期ジオプロセシングジョブを格納します。
リレーショナル - ホストフィーチャデータと、カスタマイズや構成設定などの管理面の情報を格納します。デプロイメント用に 2 つ必要です。
時空間およびインデックス - ログとインデックスのほか、ホストフィーチャデータを格納します。
注意:
このリリースでは、時空間ホストフィーチャレイヤーはサポートされていません。
Usage metric data - GIS サービス使用状況データを格納します。

組織に合ったストレージ要件を検討し、各 PV のサイズを状況に応じて適切に定義してください。

クライアントワークステーション

デプロイメントスクリプトは、リモートのクライアントワークステーションから実行できる Bash スクリプトです。スクリプトを実行しているユーザーには、スクリプトによってサブディレクトリに一時リソースファイルを書き込めるように、読み取りおよび書き込みアクセス権が必要です。

注意:

互換性に関する既知の問題のため、ArcGIS Enterprise on Kubernetes のデプロイでは、Linux エミュレーターはサポートされていません。

クライアントワークステーションの設定時に以下が必要です (ダウンロード用リンクを記載しています)。

Kubectl
環境固有のコマンドラインインターフェイス (CLI)

Kubectl は、デプロイメントスクリプトの実行前に必ず必要です。 Kubectl のインストールとセットアップを使用して Kubernetes コマンドラインツールをダウンロードします。

注意:

kubectl クライアントバージョンは、Kubernetes API サーバーバージョンの 1 つのマイナーリリースに含まれる必要があります。たとえば、kubectl 1.28 は Kubernetes クラスターバージョン 1.27-1.29 と互換性があります。

デプロイメントを管理する場合は、環境固有のコマンドラインツールを使用できます。次のリンクを使用して、環境固有の CLI をダウンロードしてください。

TLS 証明書

ArcGIS Enterprise on Kubernetes は、NGINX ベースの ingress コントローラーを使用します。この ingress コントローラーは、スコープされた名前空間であり、ArcGIS Enterprise の名前空間への ingress トラフィックのみを待機するようにデプロイされます。トランスポート層セキュリティ (TLS) 証明書は、証明書の共通名と Subject Alternative Names (サブジェクトの代替名) に FQDN が含まれている必要があります。 CA 署名証明書または自己署名証明書を使用できますが、セキュリティ上の理由から、CA 署名証明書をお勧めします。これは、ingress コントローラーのデフォルトの TLS 証明書です。デプロイメントスクリプトでは、次の証明書オプションを使用して ingress トラフィックに TLS 証明書を適用できます。

プライベートキーと証明書を含む既存の TLS シークレット
プライベートキーと証明書を含む .pfx ファイル
PEM 形式のプライベートキーと証明書
自己署名証明書

ArcGIS Enterprise on Kubernetes では、ingress コントローラーに対し、Kubernetes cert-manager によって発行および管理された TLS 証明書を使用できます。この証明書は、ArcGIS Enterprise と同じ名前空間の TLS シークレットに格納する必要があります。 TLS シークレットは、デプロイしている間または ArcGIS Enterprise 組織の作成後に参照される可能性があります。

ArcGIS Pro

ArcGIS Pro 3.3 は ArcGIS Enterprise on Kubernetes 11.3 のコンパニオンリリースです。利用可能な最新機能を入手するには、ArcGIS Pro 3.3 をご使用ください。
ArcGIS Enterprise on Kubernetes にサービスを公開するには、ArcGIS Pro 2.8 以降が必要です。
ArcGIS Enterprise on Kubernetes のサービスを使用するには、ArcGIS Pro 2.7 以降が必要です。

エンタープライズジオデータベースからデータストアアイテムを登録する場合、ジオデータベースのバージョンは 10.9.0.2.8 以降でなければなりません。

注意:

利用可能な最新機能を活用するには、ジオデータベースのバージョンを 11.3.0 にアップグレードしてください。

詳細については、「クライアントとジオデータベースの互換性」をご参照ください。

このトピックへのフィードバック

サポート環境

注意:

注意:

コンテナー レジストリ