Requisitos del sistema

A continuación, se describen el hardware y la infraestructura mínimos necesarios para ejecutar ArcGIS Enterprise en Kubernetes en la versión 11.0. Estos requisitos también se aplican cuando se implementa en un entorno desconectado.

Entornos compatibles

Los requisitos y las especificaciones del sistema se aplican en todos los entornos compatibles, mientras no se indique lo contrario. Para esta versión, se admiten los siguientes entornos:

• Centro de datos local
  • Red Hat OpenShift Container Platform
• Servicios de Kubernetes administrados en la nube
  • Amazon Elastic Kubernetes Service (EKS)
  • Google Kubernetes Engine (GKE)
  • Microsoft Azure Kubernetes Service (AKS)

En esta versión, las siguientes versiones han sido probadas y son compatibles para cada entorno:

ArcGIS Enterprise en Kubernetes	AKS	EKS	GKE	Red Hat OpenShift
Implementar 11.0 en un clúster Kubernetes existente	1.21 - 1.24	1.21 - 1.24	1.21 - 1.24	4.7 - 4.10
Actualizar un clúster Kubernetes existente tras la implementación de 11.0	No compatible	No compatible	No compatible	N/A

Nota:

Para habilitar el escalado automático para los servicios SIG, necesitará Metrics Server para recopilar métricas de nodo. Al implementar en entornos EKS, debe instalar Metrics Server con privilegios de nivel de clúster en el espacio de nombres del sistema kube. Metrics Server se instala de forma predeterminada en otros entornos admitidos.

Registro de contenedor

Las imágenes de contenedor de ArcGIS Enterprise en Kubernetes son accesibles desde un repositorio de Docker Hub privado. Esri proporcionará acceso a este repositorio a aquellos que implementan ArcGIS Enterprise en Kubernetes. Al desplegar en un entorno desconectado, deberá utilizar el registro de contenedores de su organización.

Obtener una licencia de Esri

Para autorizar su organización de ArcGIS Enterprise durante la implementación, necesita un archivo de licencia de ArcGIS Enterprise en Kubernetes en formato JSON (archivo .json). Para obtener este archivo de licencia, visite My Esri con privilegios para realizar una acción de licenciamiento.

Clúster de Kubernetes

Para implementar ArcGIS Enterprise en Kubernetes, debe tener un clúster de Kubernetes en uno de los entornos mencionados arriba.

Nota:

Al crear un clúster en GKE, debe usar el modo de operación estándar. El modo de piloto automático no es compatible.

Nota:

Al crear o actualizar en EKS un clúster con Kubernetes 1.23 y versiones posteriores, debe instalar el complemento de interfaz de almacenamiento de contenedores (CSI) de Amazon EBS. Consulte la documentación de Amazon EKS para obtener más detalles.

Espacio de nombres

ArcGIS Enterprise en Kubernetes requiere su propio espacio de nombres dedicado. El espacio de nombres se debe crear antes de ejecutar el script de implementación. Cada implementación de ArcGIS Enterprise en Kubernetes requiere también un espacio de nombres dedicado.

CPU y memoria

ArcGIS Enterprise en Kubernetes se implementa con uno de los tres perfiles de arquitectura. Las recomendaciones para las solicitudes de recursos (CPU y memoria) y los límites y los requisitos de cálculo generales varían según el perfil seleccionado. A continuación, se proporcionan las recomendaciones para cada perfil.

A continuación, se indican los requisitos mínimos de nodo para cada perfil de arquitectura. Se recomienda que cada nodo de trabajador/agente tenga como mínimo 8 CPU y 32 GiB de memoria.

Perfil de arquitectura	Número mínimo de nodos trabajador/agente	CPU mínimas totales	GiB mínimos totales
Disponibilidad estándar	4	32	128
Disponibilidad mejorada	5	40	160
Desarrollo	3	24	96

Nota:

ArcGIS Enterprise en Kubernetes solo se puede utilizar en las CPU que se ajusten a la arquitectura x86_64 (64 bits).

Los pods de la implementación de ArcGIS Enterprise en Kubernetes se distribuyen entre los nodos de trabajador del clúster. Al escalar la implementación o agregar otra implementación de ArcGIS Enterprise al clúster, debe provisionar hardware en consecuencia. Puede requerir un aumento en la cantidad máxima predeterminada de pods por nodo. El número de pods que se crean inicialmente varía según el perfil de arquitectura. A medida que escala horizontalmente o agrega nueva funcionalidad, el número de pods aumenta.

Nota:

ArcGIS Enterprise en Kubernetes no admite Windows Server imágenes de nodos en entornos de GKE.

Objeto Cuota de recursos

Los pods de ArcGIS Enterprise en Kubernetes tienen solicitudes y límites definidos de CPU y memoria. Si el espacio de nombre tiene un objeto ResourceQuota, la cuota debe ser superior a la suma de todas las solicitudes y límites de pods. Estos valores varían según el perfil de arquitectura seleccionado, como se describe a continuación.

Nota:

Si está efectuando una actualización a 11.0, primero debe actualizar los valores de la cuota de recursos en el espacio del nombre de acuerdo con los requisitos 11.0.

Se recomienda configurar al menos un 10 por ciento de recursos de solicitud para un funcionamiento correcto de los nodos de clúster.

Las siguientes recomendaciones de cuotas para cada perfil se basan en los apartados descritos anteriormente. Los valores de límite que se representan son marcadores de posición y se deben configurar en función de sus requisitos de escalabilidad.

Perfil de disponibilidad estándar:

spec: 
    hard: 
      limits.cpu: "164" 
      limits.memory: 272Gi 
      requests.cpu: "24" 
      requests.memory: 108Gi

Perfil de disponibilidad mejorada:

spec: 
    hard: 
      limits.cpu: "192" 
      limits.memory: 328Gi 
      requests.cpu: "30" 
      requests.memory: 156Gi

Perfil de desarrollo:

spec: 
    hard: 
      limits.cpu: "120" 
      limits.memory: 188Gi 
      requests.cpu: "16" 
      requests.memory: 72Gi

Seguridad

A continuación, se describen los requisitos de seguridad para ArcGIS Enterprise en Kubernetes.

Control de acceso basado en roles

El control de acceso basado en roles (RBAC) debe estar habilitado en el clúster de Kubernetes. Para implementar ArcGIS Enterprise en Kubernetes, no necesita privilegios de administrador de clúster. Si no tiene privilegios de administrador de clúster, el usuario debe tener los privilegios administrativos de espacio de nombres mínimos. Puede asignar defaultClusterRole admin al usuario creando un RoleBinding en el espacio de nombres.

Política de seguridad de pod (restricciones de contexto de seguridad en OpenShift) y memoria virtual

ArcGIS Enterprise en Kubernetes implementa Elasticsearch para admitir varias características de la organización de ArcGIS Enterprise. De forma predeterminada, Elasticsearch utiliza un directorio mmapfs para almacenar los índices requeridos. Los límites predeterminados del sistema operativo en los recuentos de map pueden ser insuficientes para la implementación. Elasticsearch recomienda un valor de vm.max_map_count predeterminado de 262144. Para cambiar el valor predeterminado, se requiere un privilegio elevado (raíz) en cada nodo.

Dependiendo de si su clúster de Kubernetes incluye una política de seguridad de pod y permite que los contenedores se ejecuten con privilegios o sin privilegios, se requieren las siguientes acciones:

• Si el clúster de Kubernetes no incluye una política de seguridad de pod pero permite que los contenedores se ejecuten con privilegios, no se requiere ninguna acción.
• Ejecutar con privilegios: si el clúster de Kubernetes tiene definida la seguridad del pod y permite que los contenedores se ejecuten con privilegios, debe permitir que la cuenta de servicio de Elasticsearch ejecute los contenedores con privilegios. Otras cuentas de servicio no necesitan ejecutar contenedores con privilegios. ArcGIS Enterprise en Kubernetes puede ejecutar un contenedor inicial con privilegios en el nodo que ejecuta Elasticsearch, lo que cambia el valor vm.max_map_count. El script de implementación de ArcGIS Enterprise en Kubernetes crea una cuenta de servicio bajo su espacio de nombres para usar la autenticación del servidor API para los procesos internos de los pods. El pod de Elasticsearch usa su propia cuenta de servicio, que no se comparte con otras cargas de trabajo. La cuenta de servicio predeterminada de Elasticsearch es arcgis-elastic-serviceaccount. Puede otorgar a la cuenta de servicio acceso a la política de seguridad de pod con roles de RBAC y RoleBindings. Para OpenShift, puede otorgar a la cuenta de servicio acceso a las restricciones de contexto de seguridad con privilegios agregando lo siguiente en la sección del usuario:
  “-system:serviceaccount: <Namespace>:arcgis-elastic-serviceaccount"
  

• Ejecutar sin privilegios: si el clúster de Kubernetes tiene definida la seguridad de pod y no puede permitir que la cuenta de servicio de ElasticSearch ejecute contenedores con privilegios, debe preparar cada nodo manualmente ejecutando el siguiente comando como raíz:
  sysctl -w vm.max_map_count=262144
  

• Si ha creado el recurso PodSecurityPolicy, deberá autorizar las siguientes cuentas de servicio en el espacio de nombres de ArcGIS Enterprise.
  • arcgis-admin-serviceaccount
  • arcgis-elastic-serviceaccount
  • arcgis-ingress-serviceaccount
  • arcgis-prometheus-serviceaccount
  • arcgis-queue-serviceaccount
  • predeterminado

  Los contenedores de ArcGIS Enterprise en Kubernetes pueden ejecutarse sin privilegios de raíz. Sin embargo, los aspectos de control fsGroup y supplementalGroups de PodSecurityPolicy deben tener RunAsAny o un rango que incluya el valor 117932853 tal como se muestra en los siguientes ejemplos.

  supplementalGroups:
      rule: 'RunAsAny'
  fsGroup:
      rule: 'RunAsAny'
  

  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 117932853
  
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 117932853
  

Si utiliza Kubernetes NetworkPolicies, asegúrese de que la comunicación entre pods y de pod a servicio sin interrupciones esté permitida en el espacio de nombres ArcGIS Enterprise.

Además, asegúrese de que los pods del espacio de nombres tengan acceso al servidor de API Kubernetes. El servidor API es accesible a través de un servicio llamado Kubernetes en el espacio de nombres predeterminado. Los pods de ArcGIS Enterprise utilizan el nombre de dominio totalmente calificado (FQDN) kubernetes.default.svc.cluster.local para realizar consultas en el servidor de la API.

Nota:

cluster.local es el dominio predeterminado del clúster.

Nota:

Se debe permitir que los pods del clúster se ejecuten con un FSGroup y SupplementalGroup un ID de 117932853.

Registrar una carpeta de datos

Para publicar elementos utilizando datos basados en archivos, como los elementos publicados desde una geodatabase de archivos, deberá colocar los datos en una ubicación compartida de NFS. Este recurso compartido de NFS debe registrarse con la organización de ArcGIS Enterprise para evitar copiar los datos en el servidor durante la publicación. Para registrar la carpeta compartida con éxito, deberá otorgar permisos de lectura de nivel de archivo a otros. Puede proteger el recurso compartido de NFS a nivel de red o infraestructura permitiendo el acceso de red al rango de IP del pod.

Red

Entre los requisitos de red se incluyen un FQDN y un equilibrador de carga. A continuación se indican los detalles de cada uno de ellos.

Nombre de dominio totalmente calificado

ArcGIS Enterprise en Kubernetes requiere un FQDN (por ejemplo, map.company.com). Puede utilizar un sistema de nombres de dominio (DNS) existente para crear uno o utilizar un servicio DNS en la nube como Amazon Route 53. Puede crear el registro de DNS después de la implementación; no obstante, debe indicar su valor durante la implementación. En esta versión, el FQDN no se puede modificar después de la implementación.

Equilibrador de carga

Se requiere un equilibrador de carga para dirigir el tráfico a través de cada nodo trabajador. Al utilizar AKS o EKS, puede proporcionar los siguientes equilibradores de carga desde el script de implementación sin necesidad de configuración manual:

• Azure Load Balancer (público o interno): se pueden especificar en el script de implementación una dirección IP pública estática y una etiqueta DNS proporcionadas previamente.
• AWS Network Load Balancer (con conexión a Internet o interno): se pueden utilizar otros servicios de equilibrio de carga, pero se deben configurar manualmente con cada nodo del clúster.

  Nota:

  Se requiere el complemento AWS Load Balancer Controller para crear equilibradores de carga de red en una subred pública o privada.

En una OpenShift Container Platform, se pueden configurar rutas cuando se apunte al servicio del controlador de entrada.

Puede utilizar un equilibrador de carga administrado automáticamente que apunte a los nodos trabajadores en el NodePort del servicio del controlador de entrada. Para obtener más información, consulte la descripción del parámetro de la guía de implementación del equilibrador de carga.

Cuando utilice un balanceador de carga autogestionado o un proxy inverso como NGINX, especifique la siguiente conexión: proxy_set_header X-Forwarded-Host $host;. Este encabezado es necesario para garantizar que el tráfico se enrute correctamente a la URL de su organización ArcGIS Enterprise.

Requisitos de IP

Planificar su red de clústeres por adelantado es esencial para garantizar una implementación exitosa, los requisitos de escala adecuados y la capacidad de actualización. Inicialmente, ArcGIS Enterprise en Kubernetes implementa de 47 a 66 pods, según el perfil de la arquitectura. La cantidad de pods aumentará a medida que se agreguen capacidades adicionales, se amplíe la implementación y durante el proceso de actualización.

A cada pod se le asigna una dirección IP única y, según la configuración de la red del clúster, los pods pueden obtener sus direcciones IP tanto de un espacio de direcciones lógicamente diferente al de la red del host (una red de superposición) como de la subred del host. Por ejemplo, si configura su clúster para usar Kubenet en Azure (por defecto), los pods recibirán una dirección IP de un espacio de direcciones lógicamente diferente y podrán acceder a los recursos de Azure mediante NAT.

Kubernetes es compatible con Container Network Interface (CNI) y plataformas como AKS y EKS, que usan complementos de CNI específicos de plataforma para las redes de clúster. Por ejemplo, los clústeres de EKS usan una CNI de nube privada virtual (VPC) de forma predeterminada. Si el clúster está configurado con un complemento de CNI, los pods recibirán direcciones IP de la subred del host y un grupo correspondiente de IP disponibles en la VPC/VNet.

Si no tiene una cantidad suficiente de direcciones IP disponibles en las subredes del host, la implementación fallará o no podrá escalar la implementación. Por ejemplo, si un clúster de EKS está configurado con 2 subredes cada una y un prefijo de dirección IPv4 /26 (64 direcciones IPv4 disponibles cada una), no puede haber más de 126 direcciones IP disponibles para los pods. Si bien es posible que pueda implementar ArcGIS Enterprise en Kubernetes en este clúster, no podrá escalar la implementación para tener 80 pods de servicios de entidades, ya que este requisito de escala excederá la cantidad de direcciones IP disponibles.

Almacenamiento del sistema

ArcGIS Enterprise en Kubernetes requiere volúmenes persistentes (PV) para el almacenamiento del sistema. Se pueden proporcionar como dinámicos o estáticos. Al crear PV de cualquiera de los dos tipos, puede utilizar tamaños personalizados (un tamaño mayor) y etiquetas. Las cargas de trabajo con estado de ArcGIS Enterprise incluyen sistemas de administración de bases de datos relacionales, así como bases de datos NoSQL. Se recomienda utilizar dispositivos de almacenamiento en bloques que proporcionen baja latencia, por ejemplo, volúmenes de EBS, discos de Azure o vSphereVolume.

Dado que estos volúmenes persistentes almacenan datos y ajustes, se deben proteger mediante políticas de seguridad restrictivas. Para los volúmenes persistentes basados en el almacenamiento basado en archivos, como NFS, Azure File o Gluster, asegúrese de que los permisos para los directorios estén configurados para evitar el acceso no autorizado. Para el almacenamiento de bloques, como volúmenes de EBS, Azure Disk y iSCSI, asegúrese de que los dispositivos de bloque estén limitados solo a aquellos usuarios que necesitan acceso.

A continuación, se describen los volúmenes de almacenamiento y sus fines previstos:

Nota:

Se establecen los requisitos de volumen persistente para 11.0 y pueden diferir de las versiones anteriores.

• En memoria: almacena recursos temporales del sistema.
• Paquetes de elementos: almacena grandes cargas y paquetes para admitir flujos de trabajo de publicación.
• Objeto: almacena contenido cargado y guardado, cachés de capas de imágenes y teselas alojadas y salida de geoprocesamiento. Se requieren cuatro para la implementación.
• En cola: almacena trabajos de geoprocesamiento asíncronos.
• Relacional: almacena datos de entidades alojados y aspectos administrativos tales como los ajustes de configuración y personalización. Se requieren dos para la implementación.
• Espaciotemporal e índice: almacena registros e índices, así como datos de entidades alojados.
• Datos métricos de uso: almacena los datos de uso del servicio SIG.

Tenga en cuenta los requisitos de almacenamiento de su organización y defina el tamaño de cada PV en consecuencia.

PV estáticos

Si está proporcionando PV estáticos antes de la implementación, se recomiendan las especificaciones y etiquetas descritas a continuación.

Se proporciona el número de PV requerido para cada perfil de arquitectura.

Volumen	Perfil de desarrollo	Perfil de disponibilidad estándar	Perfil de disponibilidad mejorada
in-memory-volume	1	1	1
item-packages-volume	1	2	2
object-volume	1	3	8
queue-volume	1	2	2
relational-volume	2	2	2
spatiotemporal-and-index-volume	1	3	5
usage-metric-volume	1	1	1

Al configurar una organización con el asistente de configuración se pueden utilizar especificaciones como las siguientes (nombre del volumen, tamaño, aplicación y nivel) para la vinculación de volúmenes; sin embargo, puede personalizarlas según sea necesario:

Volumen	Tamaño en GiB (mínimo)	Modo de acceso	Etiqueta
in-memory-volume	16	ReadWriteOnce	arcgis/tier=storage, arcgis/app=ignite
item-packages-volume	16	ReadWriteOnce	arcgis/tier=api, arcgis/app=sharing
object-volume	32	ReadWriteOnce	arcgis/tier=storage, arcgis/app=ozone
queue-volume	16	ReadWriteOnce	arcgis/tier=queue, arcgis/app=rabbitmq
relational-volume	16	ReadWriteOnce	arcgis/tier=storage, arcgis/app=postgres
spatiotemporal-and-index-volume	16	ReadWriteOnce	arcgis/tier=storage, arcgis/app=elasticsearch
usage-metric-volume	30	ReadWriteOnce	arcgis/tier=storage, arcgis/app=prometheus

Consideraciones adicionales para PV estáticos

El tipo de almacenamiento suministrado que configure durante la implementación determinará los requisitos para las actualizaciones y el escalado:

• PV dinámicos: el software escala y ajusta el almacenamiento siempre que haya suficiente almacenamiento disponible y se cumplan las especificaciones de la clase de almacenamiento.
• PV estáticos: si está aprovisionando para su implementación, deberá proporcionar PV de paquetes de elementos adicionales con las mismas especificaciones (etiquetas, tamaño y modo de acceso) que las especificadas durante la implementación para admitir el escalado y la actualización de los flujos de trabajo.

Ajuste los PV estáticos para escalar la implementación de la API del portal

Para escalar la implementación de la API del portal se necesita un PV de paquetes de elementos adicionales para cada pod adicional que se agrega a la implementación. Por ejemplo, si la organización necesita tres pods adicionales para la implementación de la API del portal, se deben suministrar y configurar un mínimo de tres PV de paquetes de elementos adicionales con especificaciones equivalentes a las especificadas durante la implementación.

PV dinámicos

Para el aprovisionamiento dinámico, se requiere una StorageClass.

El parámetro StorageClass de reclaimPolicy debe tener el valor retain.

Nota:

No todos los tipos de VM admiten discos premium en Azure. Utilice un disco premium cuando el tipo VM lo admita.

• Para AKS, se muestra a continuación un ejemplo de una definición de StorageClass con Premium Azure Disk:
  kind: StorageClass 
  apiVersion: storage.k8s.io/v1 
  metadata: 
    name: arcgis-storage-default 
  provisioner: kubernetes.io/azure-disk 
  parameters: 
    kind: Managed 
    storageaccounttype: Premium_LRS 
  reclaimPolicy: Retain
  allowVolumeExpansion: true
  volumeBindingMode: WaitForFirstConsumer
  

• Para EKS, se muestra a continuación un ejemplo de una definición de StorageClass con volúmenes de EBS de tipo GP2:
  kind: StorageClass 
  apiVersion: storage.k8s.io/v1 
  metadata: 
    name: arcgis-storage-default  
  provisioner: kubernetes.io/aws-ebs 
  parameters: 
    fsType: ext4 
    type: gp2 
  reclaimPolicy: Retain
  allowVolumeExpansion: true
  volumeBindingMode: WaitForFirstConsumer
  

También puede utilizar las clases de almacenamiento predeterminadas que se proporcionan con un clúster de AKS o EKS. En AKS, son las clases de almacenamiento "default (Azure disk)" o "managed-premium" En EKS, es una clase de almacenamiento "GP2".

Estación de trabajo de cliente

Los scripts de implementación son scripts de Bash que se pueden ejecutar desde una estación de trabajo de cliente remota.

Nota:

La estación de trabajo cliente utilizada debe estar de conformidad con los entornos admitidos. Los emuladores de Linux no son compatibles con la implementación de ArcGIS Enterprise en Kubernetes.

Necesitará lo siguiente al configurar su estación de trabajo de cliente (se proporcionan los vínculos de descarga):

• Kubectl
• Una interfaz de línea de comandos específica del entorno (CLI)

Kubectl es un requisito previo para ejecutar el script de implementación. Utilice la instalación y configuración de Kubectl para descargar la herramienta de línea de comandos de Kubernetes.

Al administrar su implementación, puede utilizar herramientas de línea de comandos específicas del entorno. Utilice los siguientes vínculos para descargar una CLI específica del entorno:

• CLI de Azure
• CLI de AWS
• CLI de GKE
• CLI de OpenShift

Certificado TLS

ArcGIS Enterprise en Kubernetes utiliza un controlador de entrada basado en NGINX. Este controlador de entrada tiene un ámbito de espacio de nombres y se implementa para escuchar únicamente el tráfico de entrada del espacio de nombres de ArcGIS Enterprise. Se requiere un certificado TLS con el FQDN en el nombre común del certificado y el nombre alternativo de sujeto. Se puede utilizar un certificado firmado por una autoridad certificadora o un certificado autofirmado; no obstante, por motivos de seguridad, se recomienda utilizar un certificado firmado por una autoridad certificadora. Este es el certificado TLS predeterminado para el controlador de entrada. Las siguientes opciones de certificado están disponibles en el script de implementación para aplicar un certificado TLS para el tráfico de entrada:

• Un secreto de TLS existente que contiene una clave privada y un certificado
• Un archivo .pfx que contiene una clave privada y un certificado
• Una clave privada y un certificado con formato PEM
• Un certificado autofirmado

ArcGIS Enterprise en Kubernetes admite el uso de un certificado TLS para el controlador de entrada emitido y administrado por el administrador de certificados de Kubernetes. Este certificado se debe almacenar en un secreto de TLS en el mismo espacio de nombres que ArcGIS Enterprise. A continuación, se puede hacer referencia al secreto de TLS durante la implementación o después de crear la organización de ArcGIS Enterprise.

ArcGIS Pro

• ArcGIS Pro 3.0 es la versión complementaria de ArcGIS Enterprise en Kubernetes 11.0. Para beneficiarse de las últimas funciones disponibles, utilice ArcGIS Pro 3.0.
• Para publicar servicios en ArcGIS Enterprise en Kubernetes, se requiere ArcGIS Pro 2.8 o versiones posteriores.
• Para consumir servicios desde ArcGIS Enterprise en Kubernetes, se requiere ArcGIS Pro 2.7 o versiones posteriores.

Al registrar un elemento del almacén de datos desde una geodatabase empresarial, la versión de la geodatabase debe ser 10.9.0.2.8 o posterior.

Nota:

Para beneficiarse de las últimas funciones disponibles, actualice la versión de su geodatabase a 11.0.0.3.0.

El número de versión de la geodatabase es una combinación de los números de ArcGIS Enterprise y ArcGIS Pro. Para obtener más información, consulte Compatibilidad entre clientes y geodatabases.

Requisitos de actualización y mejora

Antes de llevar a cabo una actualización, debe cumplir con varios requisitos, como los siguientes:

• Si hay una actualización requerida disponible, debe aplicarla antes de actualizar a esta versión. Consulte las notas de la versión para obtener detalles sobre la última actualización requerida.
• Debe tener una licencia unificada de ArcGIS Enterprise en Kubernetes para esta versión.
• Debe actualizar los valores de cuota de recursos en su espacio de nombres para cumplir con los requisitos actuales.
• Si ha aprovisionado PV estáticos, debe aprovisionar almacenamiento adicional para adaptarse a los requisitos de actualización. Consulte la sección Ajustar PV estáticos para la actualización para obtener más detalles.
• Si su almacenamiento aprovisionado tiene PV dinámicos, debe asegurarse de que haya suficiente almacenamiento disponible para los paquetes de elementos adicionales, el volumen de objetos y el volumen de cola.
• Si está actualizando desde la versión 10.9.1, debe aprovisionar al menos el cincuenta por ciento (50%) de almacenamiento adicional para acomodar nuevos PV de almacenamiento de objetos para cada perfil de arquitectura. Por ejemplo, si ha asignado 100 GB de almacenamiento para el PV del almacén de objetos por cada pod de almacenamiento de objetos, debe proporcionar al menos 150 GB de almacenamiento adicional.
• Ejecute el script de actualización previa. Este script detectará y abordará cualquier requisito funcional para cumplir con la versión actual del software.
• Si configuró un Web Adaptor con su organización, revise los requisitos de instalación y actualización.
• Si su organización se encuentra en un entorno desconectado, siga los pasos para aplicar una mejora o actualización en entornos desconectados.
• Si utilizó el registro de contenedores de su organización al desplegar ArcGIS Enterprise en Kubernetes, debe copiar las imágenes de contenedor necesarias del repositorio Esri al registro de su organización antes de ejecutar la actualización o mejora.

Ajuste los PV estáticos para las actualizaciones

Antes de una actualización, cada pod de las implementaciones de la API del portal y el almacén de cola de la organización se ha configurado con un PV de paquetes de elementos o de volumen de cola, respectivamente. Para preparar una actualización, cada pod de las implementaciones de la API del portal y el almacén de cola debe configurarse con un PV adicional.

Por ejemplo, antes de una actualización, si la implementación del almacén de cola y de la API del portal se configura con tres pods en ejecución, se deben suministrar y configurar tres PV adicionales con especificaciones equivalentes a las especificadas durante la implementación.

Una vez completada la actualización, la implementación de la API del portal o el almacén de cola utilizará los volúmenes persistentes recién suministrados y la reclamación de volumen persistente, y el set original podrá eliminarse.

Será necesario aprovisionar PV estáticos adicionales para las implementaciones de almacén de objetos cuando se actualice de acuerdo con la siguiente tabla:

Tipo de implementación	PV de volumen de objeto estático predeterminado	Se requieren PV estáticos adicionales para actualizar
Perfil de desarrollo	1	Crear 1 PV adicional
Perfil de disponibilidad estándar	3	Crear 3 PV adicionales
Perfil de disponibilidad mejorada	8	Crear 8 PV adicionales