システム要件
このページには、接続環境または非接続環境でデプロイする場合に ArcGIS Enterprise on Kubernetes の実行に必要な最低限のハードウェアとインフラストラクチャーが一覧されています。
サポートされている環境
システム要件および仕様は、注意書きがない限りサポートされているすべての環境に適用されます。 このリリースでは、次の環境がサポートされています。
注意:
ArcGIS Enterprise on Kubernetes は、x86_64 アーキテクチャー (64 ビット) に準拠した CPU のみでサポートされています。 ワーカー ノードは Linux ベースである必要があります。
Kubernetes クラスターでは、自動アップグレードを無効にすることをおすすめします。 自動アップグレードが有効になっている場合は、ノードが最新バージョンの Kubernetes に自動的に更新されますが、これらの将来のバージョンは ArcGIS Enterprise でまだサポートされていない可能性があります。
注意:
完全な互換性とサポートを保証するには、Kubernetes バージョンがサポートされている範囲内にあることを確認してから ArcGIS Enterprise on Kubernetes をアップグレードします。
各環境の次のバージョンはテスト済みで、サポートされています。
|
サポートされている環境 |
サポートされている Kubernetes のバージョン |
|---|---|
|
クラウドのマネージド Kubernetes サービス (AKS、EKS、GKE) Red Hat OpenShift (セルフマネージド Kubernetes エンジン、ROSA、ARO) [4.20-4.21] RKE2 VMware Tanzu |
1.33 - 1.35 |
コンテナー レジストリー
ArcGIS Enterprise on Kubernetes のコンテナー イメージには、プライベートの Docker Hub 組織からアクセスできます。 Esri は、ArcGIS Enterprise on Kubernetes をデプロイしているユーザーにこの組織のリポジトリーへのアクセス権を提供します。
組織のコンテナー レジストリーを使用している場合、Esri イメージを使用してそのレジストリーを準備する必要があります。 非接続環境でデプロイする場合、これは必須です。
Esri ライセンスの取得
デプロイ時に ArcGIS Enterprise 組織を認証するには、JSON 形式 (.json ファイル) の ArcGIS Enterprise on Kubernetes ライセンス ファイルが必要です。 このライセンス ファイルを取得するには、ライセンス アクションを実行する権限を使用して My Esri にアクセスします。
ワーカー ノード
各ワーカー/エージェント ノードには、最小で 200 GiB のルート ディスク サイズを推奨します。 必要に応じて、クラスター管理者に連絡して、ワーカー/エージェント ノードのシステム リソースを増やしてください。
ArcGIS Enterprise on Kubernetes デプロイメント内のポッドは、クラスター内のワーカー ノード全体に分散しています。 ワーカー ノードのクロックを共通のソースと同期させ、クラスター内で時間の一貫性を保つ必要があります。
デプロイメントをスケーリングする場合や、別の ArcGIS Enterprise デプロイメントをクラスターに追加する場合は、ノードを適切にプロビジョニングする必要があります。 これには、ノードあたりの最大ポッド数のデフォルト値を増やす必要がある場合があります。
リソース要件
ArcGIS Enterprise on Kubernetes に必要な CPU とメモリーの合計量は、ポッド レプリカの数と、それらのポッドに設定されているリソースの要求と制限によって異なります。
既存の組織をこのリリースにアップグレードする場合、全体のリソース要件はポッド レプリカの数および構成したリソースの要求と制限に基づきます。 現在のリソース割り当てがニーズを満たすのに十分であれば、アップグレード後も同じレベルのリソース割り当てを使用できます。
新規デプロイメントの場合、初期リソース要件は選択したアーキテクチャー プロファイルによって異なります。 以下の表に、このソフトウェアをインストールして新しい組織を構成するための最小リソース要件を示します。 組織におけるワークロードのスケーリングと機能の有効化をサポートするため、必要に応じて、これらの最小値を超える追加のリソースを割り当てます。
|
標準パフォーマンス |
拡張パフォーマンス |
|
|---|---|---|
|
開発およびテスト環境 |
|
|
|
標準高可用性 |
|
|
|
拡張高可用性 |
|
|
標準高可用性と標準パフォーマンスを組み合わせたデフォルトのポッド構成は、お使いのライセンスでカバーされます。
これらの要件を満たすために必要なノード数は、ノード サイズによって異なります。 たとえば、8 vCPU と 32 GiB メモリーのサイズのノードを使用する場合、標準パフォーマンスと標準高可用性の組み合わせでは少なくとも 10 ノードが必要です。 16 vCPU と 32 GiB メモリーのノードを使用する場合、同じプロファイルの組み合わせで少なくとも 5 ノードが必要です。
オブジェクト ストアまたはリレーショナル ストアのクラウド サービスと統合する場合、アプリケーション リソース要件は可用性プロファイルに応じて次の分量だけ削減されます:
|
アーキテクチャー プロファイル |
オブジェクト ストア |
リレーショナル ストア |
|---|---|---|
|
拡張高可用性 |
4 vCPU/ 64 GiB |
1 vCPU/ 4 GiB |
|
標準高可用性 |
1.5 vCPU/ 24 GiB |
1 vCPU/ 4 GiB |
|
開発およびテスト環境 |
0.5 vCPU/ 8 GiB |
1 vCPU/ 4 GiB |
セキュリティー
以下の各セクションでは、ArcGIS Enterprise on Kubernetes のセキュリティー要件について説明します。
ロールベースのアクセス制御
Kubernetes クラスターでロールベースのアクセス制御 (RBAC) が有効になっている必要があります。 ArcGIS Enterprise on Kubernetes をデプロイするには、cluster-admin 権限は必要ありません。 cluster-admin 権限がない場合、少なくとも名前空間管理権限を持っている必要があります。 名前空間に RoleBinding を作成することで、ユーザーにデフォルトの ClusterRole を割り当てることができます。 詳細については、RBAC ロールのリソースをご参照ください。
SELinux のサポート
SELinux (Security-Enhanced Linux) モジュールは、ArcGIS Enterprise on Kubernetes を実行しているワーカー ノードでサポートされています。 SELinux のデフォルトのポリシーにより、ArcGIS が内部コンポーネントに到達できないために、管理者が SELinux ポリシーを変更する必要がある場合があります。 このためには、一時的に SELinux ポリシー モードを permissive に設定します。 これにより、内部リソースにアクセスするために ArcGIS が行うアクションなど、ポリシーの違反が記録されますが、これらは許可されます。 管理者は、これらの違反を記録し、これらを許可するように SELinux ポリシー構成を変更した後で、ポリシー モードを enforced に再設定できます。
データ フォルダーの登録
ネットワーク共有上のファイル ジオデータベースから公開されたアイテム、キャッシュ タイルのコレクション、ロケーターなどのファイルベースのデータを使用してアイテムを公開するため、共有された NFS の場所のデータをホストしたり、PV ベース フォルダーのデータ ストアを追加できます。 GIS およびシステム サービスが共有場所に適切にアクセスできるようにするには、実行中のサービス ポッドのユーザーおよびグループ ID またはその他のディレクトリー権限により、共有、そのサブディレクトリー、およびそこに含まれるファイルへの読み取りアクセスを提供する必要があります。 このフォルダー データ ストアを組織に登録すると、公開中にデータを組織にコピーする必要がなくなります。 NFS サーバーの場合、エクスポートのためにポッドの IP 範囲へのネットワーク アクセスのみを許可することで、ネットワークまたはインフラストラクチャー レベルでセキュリティーを管理できます。
ネットワーク
ネットワーク要件には、完全修飾ドメイン名 (FQDN) と、ロード バランサーまたはリバース プロキシー (クライアントからのトラフィックを標準の HTTPS ポート (443) 経由で構成済みのバックエンド ターゲットへ転送する) が含まれます。 それぞれの詳細を以下に示します。
完全修飾ドメイン名
ArcGIS Enterprise on Kubernetes は FQDN (たとえば map.company.com) が必要です。 既存のドメイン名システム (DNS) サービスを使用して CNAME または A レコードを作成するか、クラウド プロバイダーの DNS サービス (Amazon Route 53 など) と統合できます。 デプロイメント後に DNS レコードを作成できますが、デプロイメント プロセス中に FQDN が指定されている必要があります。 このリリースでは、デプロイ後に FQDN を変更することはできません。
注意:
Amazon EKS クラスター用のネットワーク ロード バランサーまたはアプリケーション ロード バランサーを作成するには、AWS Load Balancer Controller アドオンが必要です。
ロード バランサー
ロード バランサーを使用して、トラフィックを ArcGIS Enterprise on Kubernetes デプロイメントに転送できます。 レイヤー 4 とレイヤー 7 両方のロード バランサーをデプロイメント スクリプトからプロビジョニングできます。手動による構成は不要です。 デプロイメント スクリプトに基づいてデプロイメントと統合されているロード バランサーは、トラフィックをクラスター内 NGINX Ingress コントローラーのポッドへ直接ルーティングします。
または、着信トラフィックがデプロイメントのワーカー ノードの特定のポートに送信される必要があるデプロイメントにトラフィックをルーティングするために、ArcGIS Enterprise on Kubernetes Web Adaptor を使用することもできます。
次のレイヤー 4 ロード バランサーをデプロイメント スクリプトからプロビジョニングできます。手動による構成は不要です。
Azure Load Balancer (パブリック向けまたは内部向け) - プロビジョニングされる静的なパブリック IP アドレスおよび DNS ラベルは、デプロイメント スクリプトで指定できます。
AWS Network Load Balancer (インターネット向けまたは内部) - サイレント デプロイする際に、カスタム アノテーションを使用してロード バランサーをカスタマイズできます。 詳細については、「追加のサイレント デプロイ プロパティ」のカスタム Ingress アノテーションのセクションをご参照ください。
Google Cloud Platform TCP Load Balancer (インターネット向けまたは内部向け) - プロビジョニングされる静的なパブリック IP アドレスは、デプロイメント スクリプトで指定できます。
一般ロード バランサー - MetalLB、Traefik、HAProxy など、組織がオンプレミス インフラストラクチャーですでに運用に慣れている可能性のあるレイヤー 4 ソリューションをサポートします。 マネージド クラウド プロバイダーの Kubernetes クラスターを使用する場合は、対応する統合クラウド オプションを選択する必要がありますが、セルフマネージド クラスターの場合は、一般ロード バランサー オプションによって、デプロイメント プロパティ ファイルで定義されているすべてのアノテーションがカスタム アノテーションとして追加されます。
上で指定されたロード バランサーは、基になる Kubernetes サービス オブジェクトのアノテーションを使用してカスタマイズできます。 たとえば、AWS の Network Load Balancer でクロスゾーン負荷分散を有効にしたり、Azure Blob Load Balancer を特定のリソース グループに配置したりできます。 デプロイメント スクリプトに付属している deploy.properties テンプレート ファイルに、サイレント デプロイ時にこれらのアノテーションを指定する方法の例が記載されています。
デプロイメント スクリプトを使用して、Web アプリケーション ファイアウォールなどのレイヤー 7 負荷分散機能を使用したり、既存の Ingress コントローラーを使用する配置されたアプリケーションへの Ingress に関する組織の要件を満たしたりすることができます。 次のレイヤー 7 ロード バランサーをデプロイメント スクリプトから直接デプロイまたは統合することができます。
AWS Application Load Balancer
Azure Application Gateway
Google Cloud Platform Application Load Balancer
RedHat OpenShift は、外部クライアントからのトラフィックをクラスター内に存在するサービスに向けるための統合構築物である Route を提供します。 このオプションでは、プロパティが組織の要件に応じて異なる可能性があるため、管理者がデプロイメント スクリプトの外部で Route を作成する必要があります。 ルート オブジェクトは、コンソールまたは YAML から作成でき、バンドルされた Ingress コントローラーへのトラフィックを中継するためにエンドツーエンドの TLS 暗号化を使用する必要がありますが、パススルー モードまたは再暗号化モードも使用できます。
クラスターレベルで実装される Ingress コントローラーは、これらのロード バランサーを使用することで、着信トラフィックを ArcGIS Enterprise on Kubernetes デプロイメントにルーティングするためのクラスター レベルの Ingress ルールを実装します。 サイレント デプロイの前にデプロイメント スクリプトからこれらのロード バランサーを実装するには、layer-7-templates フォルダー内のテンプレート YAML ファイルを修正してクライアント ワークステーションに保存し、CLUSTER_INGRESS_CONTROLLER_YAML_FILENAME パラメーターにこの場所を指定できます。 詳細については、「クラスターレベルの Ingress コントローラー」をご参照ください。
注意:
ノートブック サービスをサポートするには、外部のリバース プロキシーまたはロード バランサーが WebSocket トラフィックをバックエンド ターゲットに転送でき、セッションが 10 分間開いたままになるように要件を設定する必要があります。
セルフマネージド ロード バランサーまたは 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 が最初にデプロイするポッドの数は、その可用性プロファイルによって異なります。 機能の追加、デプロイメントのスケーリング、アップグレード処理に伴い、ポッドの数が増加します。
各ポッドには一意の 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 ボリュームなどのブロック ストレージの場合、ストレージ ボリュームへのアクセスが、そのアクセスを必要とするユーザーのみに制限されていることを確認します。
ストレージ ボリュームの説明と使用目的は次のとおりです。
インメモリー - 一時システム リソースを格納します。
アイテム パッケージ - 公開ワークフローをサポートするサイズの大きいアップロードとパッケージを格納します。
オブジェクト - アップロードおよび保存されたコンテンツ、ホスト タイル、画像、シーン レイヤーのキャッシュ、およびジオプロセシングの出力を格納します。
キュー - 非同期ジオプロセシング ジョブを格納します。
リレーショナル - ホスト フィーチャ データと、カスタマイズや構成設定などの管理面の情報を格納します。 デプロイメント用に 2 つ必要です。
時空間およびインデックス - ログとインデックスのほか、ホストフィーチャ データを格納します。
使用状況指標データ - GIS サービス使用状況データを格納します。
組織に合ったストレージ要件を検討し、各 PV のサイズを状況に応じて適切に定義してください。
クライアント ワークステーション
デプロイメント スクリプトは、リモートのクライアント ワークステーションから実行できる Bash スクリプトです。 スクリプトによってサブディレクトリーに一時リソース ファイルを書き込めるように、読み取りと書き込みのアクセス権を持つユーザーとしてスクリプトを実行する必要があります。
次のオペレーティング システムは、デプロイメント スクリプトの実行、スクリプトの構成、その他のパッケージ化されたスクリプトとツールに対応しています:
|
サポートされているオペレーティング システム |
最新の更新内容またはテスト済みサービス パック |
|---|---|
|
Red Hat Enterprise Linux Server 8 |
Update 10 |
|
Red Hat Enterprise Linux Server 9 |
Update 7 |
|
AlmaLinux 8 |
Update 10 |
|
AlmaLinux 9 |
Update 7 |
|
SUSE Linux Enterprise Server 15 |
Service Pack 7 |
|
Ubuntu Server 24.04 LTS |
24.04.4 |
|
Ubuntu Server 22.04 LTS |
22.04.5 |
|
Oracle Linux 8 |
Update 10 |
|
Oracle Linux 9 |
Update 7 |
|
Rocky Linux 8 |
Update 10 |
|
Rocky Linux 9 |
Update 7 |
クライアント ワークステーションは、サブシステムやコンテナー化された環境としてではなく、ネイティブ Linux システムとしてインストールされているこれらのオペレーティング システムでテストされています。 他の未テストのシェル環境、Linux 互換レイヤー、オペレーティング システムでも動作することがありますが、組織をデプロイおよび構成する際に予期しない問題が発生する可能性があります。 環境で問題が発生した場合は、上記に記載されている環境と一致するクライアント ワークステーションをプロビジョニングすることをおすすめします。
クライアント ワークステーションの設定時に以下が必要です (ダウンロード用リンクを記載しています)。
Kubectl
環境固有のコマンド ライン インターフェイス (CLI)
Kubectl は、デプロイメントスクリプトの実行前に必ず必要です。 Kubectl のインスタンスとセットアップを使用して、お使いのクラスターの Kubernetes のバージョンと互換性があるバージョンの Kubernetes コマンド ライン ツールをダウンロードします。
デプロイメントを管理する場合は、環境固有のコマンド ライン ツールを使用できます。 次のリンクを使用して、環境固有の 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.7 は ArcGIS Enterprise 12.1 on Kubernetes のコンパニオン リリースです。 利用可能な最新機能を入手するには、ArcGIS Pro 3.7 をご使用ください。
ArcGIS Enterprise on Kubernetes にサービスを公開するには、ArcGIS Pro 2.8 以降が必要です。
ArcGIS Enterprise on Kubernetes のサービスを使用するには、ArcGIS Pro 2.7 以降が必要です。
エンタープライズ ジオデータベースからデータ ストア アイテムを登録する場合、ジオデータベースのバージョンは 10.9.0.2.8 以降でなければなりません。
詳細については、「クライアントとジオデータベースの互換性」をご参照ください。
ArcGIS Enterprise on Kubernetes Web Adaptor
ArcGIS Enterprise on Kubernetes Web Adaptor は、Windows の IIS Web サーバーか、Windows または Linux の Java Web サーバーのいずれかと統合することができます。 固有の前提条件およびバージョンの要件については、「ArcGIS Enterprise on Kubernetes Web Adaptor のシステム要件」をご参照ください。