アップグレードの準備
新しいバージョンの ArcGIS Enterprise on Kubernetes にアップグレードすると、組織は新機能や改善機能を利用できます。 新機能についてよく理解し、組織のメンバーに影響を与える可能性がある変更を特定してください。
アップグレードする前に、お使いの環境が要件を満たしているか必ず確認してください。 すべての環境で必須となる要件があるほか、構成によっては、環境固有の要件も満たす必要がある場合があります。
ヒント:
更新またはアップグレード時に使用されるポッドに対するノードのアフィニティーと耐障害性を設定または変更できます。 配置ポリシーは作成されると、アップグレード ジョブが作成されるたびに適用されます。 設定した値は、リセットされるまで、今後すべての更新およびアップグレードの間保持されます。 詳細については、「更新 (構成のアップグレード)」をご参照ください。
アップグレード要件
アップグレードを実施する前に、次の要件が満たされている必要があります。
お使いの環境はこのリリースのシステム要件を満たしている必要があります。 このリリースでは、サポートされる Kubernetes のバージョン、ワーカー ノードのディスク サイズ、必要なシステム ストレージ、その他のシステム要件が変更されている可能性があります。 お使いのクラスターの Kubernetes のバージョンが、ArcGIS Enterprise on Kubernetes の現在のバージョンとこのリリースの両方でサポートされていることを確認します。
組織のバックアップが必要です。 アップグレード前に新しいバックアップを取ることをおすすめします。
このリリースには、ArcGIS Enterprise on Kubernetes の統合ライセンスが必要です。
必要なアップデートが利用可能であれば、このリリースにアップグレードする前に適用する必要があります。 最新の必要なアップデートの詳細については、リリース ノートをご参照ください。
アップグレード前スクリプトを実行する必要があります。 このスクリプトは、現在のソフトウェア リリースに対応するよう、さまざまな機能要件を検出し、対処します。
現在の要件を満たすには、名前空間のリソース クォータ値を更新する必要があります。
アップグレードを実施する前に、お使いの環境で、ポッド セキュリティー アドミッション標準などのポッド セキュリティー標準を満たす必要があります。
ストアのボリューム サイズが、アップグレード先のリリースの最小要件を満たしている必要があります。 ボリューム拡張が、ストレージ クラスで使用されるプロビジョナーで利用できない場合は、ボリュームを増加させて構成した新しい組織へとバックアップを復元します。 最小ストレージ要件が満たされないと、組織のアイテムの読み込み時やサービスの開始時に問題が発生する可能性があります。
リレーショナル ストアをアップグレードするため、バックアップがリレーショナル データ ストア インスタンスと同じ永続ボリュームに作成されています。 このバックアップには、少なくともデータベース サイズの 50 パーセントの容量が使用可能である必要があります。 たとえば、リレーショナル ストアが 100 GB のストレージを現在使用している場合、関連付ける PV はアップグレード前で 50 GB 以上必要です。したがって、必要なボリューム サイズは合計で 150 GB 以上になります。 ボリューム サイズの増加手順については、必要なストレージの管理をご参照ください。
アップグレード中に書き込まれる追加データを考慮に入れるために、オブジェクト ストアには少なくとも 20 GB の空き容量を、時空間およびインデック スストアには少なくとも 20% の空き容量を確保してください。 これにより、アップグレード中にデータ ストアが読み取り専用モードになるのが防止されます。
すべてのオフラインの ArcGIS Pro ライセンスが、組織のメンバーによってチェック インされている必要があります。 ライセンス アクティビティーを確認すると、オフライン使用するよう ArcGIS Pro ライセンスをチェック アウトしたメンバーを確認できます。 オフライン ライセンスをチェック インする方法については、「オフライン ライセンスのチェック イン」をご参照ください。
環境固有のアップグレード要件
環境の構成によっては、アップグレードの前に追加の要件を満たす必要がある場合があります。
お使いの環境が Red Hat OpenShift 内にある場合は、現在のセキュリティー コンテキストの制約を満たす必要があります。
静的永続ボリューム (PVs) をプロビジョニングした場合、アップグレード要件に対応できるよう、追加のストレージをプロビジョニングする必要があります。 詳細については「アップグレードのための静的 PV の調整」をご参照ください。
プロビジョニングしたストレージに動的 PV がある場合、追加のアイテムパッケージ ボリューム、オブジェクト ボリューム、キュー ボリュームに十分なストレージが確保されている必要があります。
組織で Web Adaptor を構成した場合は、インストールとアップグレードの要件をご確認ください。
組織のコンテナー レジストリーを使用する場合や非接続環境にデプロイした場合は、アップデートやアップグレードを実行する前に、必要なコンテナー イメージを Esri リポジトリーからレジストリーへコピーする必要があります。
デプロイメントが複数のアベイラビリティー ゾーンを使用する場合は、各アベイラビリティー ゾーンにステートフル ワークロードの追加レプリカをサポートできるだけの十分な容量が必要です。 このためアップデートまたはアップグレード時に、一時的にノード グループのスケール アウトが必要になる場合があります。
クラウド リレーショナル ストアを使用している場合、ArcGIS Enterprise on Kubernetes の現在のリリースとアップグレード先リリースの両方でデータベース バージョンがサポートされている必要があります。 このために、クラウド リレーショナル ストアのデータベース インスタンスのアップグレードが必要になる場合があります。
まだ実施されていない場合は、リソース使用量とクラスター容量に基づき、各サービスのリクエストと制限が適切かどうかを確認することをおすすめします。 必要に応じてサービスのリソースを垂直にスケーリングします。
注意:
アップグレードを行っても、リソースのリクエストと制限を調整するパフォーマンス プロファイルは適用されません。
以前に EKS で IAM 認証用のポッド ベースの ID を構成したことがある場合は、IAM ロールとポッド ID の関連付けに関する、更新されたサービス アカウント要件を確認してください。
アップグレードのための静的 PV の調整
アップグレード前に、追加の PV を使用して、rest-portal-api、in-memory-store、queue-store StatefulSets の各ポッドを構成する必要があります。 デプロイメント中に指定されたものと同じ仕様で各 PV を構成する必要があります。 対応するサイズとラベルの要件をご参照ください。
たとえば、rest-portal-api が 2 つのポッドで構成されている場合、item-packages-volume のサイズとラベルの要件を満たす追加のボリュームを 2 つプロビジョニングする必要があります。
アップグレードが完了すると、rest-portal-api、in-memory-store、queue-store は、新たにプロビジョニングされた PV と永続ボリューム クレーム (PVC) を使用するようになります。 この後、元のボリューム セットは削除できます。 以前のアップグレードまたはアップデート時にリリースされた PV が再使用されることはないため、リリース済み状態の PV はすべて削除することを強くおすすめします。