Prepare to upgrade
Upgrading to a new version of ArcGIS Enterprise on Kubernetes provides your organization with new features and improved functionality. Learn about the new features and identify any changes that may affect your organization's members.
Before upgrading, make sure that your environment meets the requirements. Some requirements are necessary for all environments, and there are additional environment-specific requirements that you may also need to meet depending on your configuration.
Tip:
You can set or modify the node affinity and tolerations for the pods that are used during updates or upgrades. Once a placement policy has been created, it will be applied whenever an upgrade job is created. The values that you set will persist for all future updates and upgrades until they are reset. See Update (Upgrades Configuration) for details.
Upgrade requirements
Before performing an upgrade, the following requirements must be met:
Your environment must meet the system requirements for this release. The supported Kubernetes version, worker node disk size, required system storage, and other system requirements may have changed in this release. Ensure that the Kubernetes version of your cluster is supported for both your current version of ArcGIS Enterprise on Kubernetes and this release.
You must have a backup of your organization. It is recommended to take a new backup before upgrading.
You must have a unified ArcGIS Enterprise on Kubernetes license for this release.
If a required update is available, you must apply it before upgrading to this release. Review the release notes for details about the latest required update.
You must run the pre-upgrade script. This script will detect and address any functional requirements to meet the current software release.
You must update the resource quota values in your namespace to meet the current requirements.
Your environment must meet pod security standards such as the pod security admission standards before conducting the upgrade.
The volume sizes of stores must meet the minimum requirements for the release you're upgrading to. If volume expansion is not available for the provisioner used by the storage class, restore a backup to a new organization configured with increased volumes. Not meeting the minimum storage requirements could result in issues when loading your organization's items and starting services.
To upgrade the relational store, a backup is created in the same persistent volume as the relational data store instance. This backup requires at least 50 percent of the database size to be available. For example, if the relational store is currently using 100 GB of storage, the associated PV must have at least 50 GB available before upgrading, making the total volume size required 150 GB or larger. See Manage required storage for instructions on increasing volume size.
To account for additional data written during the upgrade, ensure that the object store has at least 20 GB of available space and the spatiotemporal and index store has at least 20% free space. This prevents the data stores from going into read-only mode during the upgrade.
All offline ArcGIS Pro licenses must be checked in by your organization members. You can view license activity to see which members have checked out their ArcGIS Pro license for offline use. For information about how to check in an offline license, see Check in an offline license.
Environment-specific upgrade requirements
Depending on the configuration of your environment, you may need to meet additional requirements before upgrading:
If your environment is in Red Hat OpenShift, it must meet the current security context constraints.
If you have provisioned static persistent volumes (PVs), you must provision additional storage to accommodate upgrade requirements. See Adjust static PVs for upgrades for details.
If your provisioned storage has dynamic PVs, sufficient storage must be available for the additional item-packages volume, object volume, and queue volume.
If you have a configured web adaptor with your organization, review installation and upgrade requirements.
If you use your organization's container registry or if you've deployed in a disconnected environment, you must copy the required container images from the Esri repository to your registry before running the update or upgrade.
If the deployment uses multiple availability zones, there must be adequate capacity in each availability zone to support additional replicas of the stateful workloads. This may require temporarily scaling out the node group during updates or upgrades.
If you are using a cloud relational store, the database version must be supported for both your current release of ArcGIS Enterprise on Kubernetes and also the release you're upgrading to. This may require upgrading the cloud relational store database instance.
It is recommended that you verify requests and limits for each service are appropriate based on resource usage and cluster capacity, if you have not already done so. Vertically scale the resources for services if necessary.
Note:
Upgrading will not apply a performance profile to adjust resource requests and limits.
If you previously configured pod-based identity for IAM authentication in EKS, review the updated service accounts requirements for IAM role and pod identity associations.
Adjust static PVs for upgrades
Before upgrading, each pod in the rest-portal-api, in-memory-store and queue-store StatefulSets must be configured with an additional PV. Each PV must be configured with equivalent specifications as those specified during deployment. See the corresponding size and label requirements.
For example, if the rest-portal-api is configured with two pods, you must provision two additional volumes that meet the size and label requirements for the item-packages-volume.
Once the upgrade is complete, the rest-portal-api, in-memory-store, and queue-store will use the newly provisioned PVs and persistent volume claim (PVC). The original set of volumes can then be removed. It is strongly recommended that you remove any PVs in a released state, as PVs released during prior upgrades or updates must never be reused.