Requisitos del sistema

A continuación, se describen el hardware y la infraestructura mínimos necesarios para ejecutar ArcGIS Enterprise on Kubernetes en la versión 10.9.

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 4.6 o posterior
• Servicios de Kubernetes administrados en la nube
  • Microsoft Azure Kubernetes Service (AKS)
  • Amazon Elastic Kubernetes Service (EKS)

Registro de contenedor

Las imágenes de contenedor de ArcGIS Enterprise on Kubernetes son accesibles desde un repositorio de Docker Hub privado. Esri proporcionará acceso a este repositorio a aquellos que implementan ArcGIS Enterprise on Kubernetes. Hable con su representante de Esri para obtener más detalles.

Licencias de Esri

Para autorizar su organización de ArcGIS Enterprise durante la implementación, necesita un archivo de licencia de tipo de usuario en formato JSON (archivo .json) y un archivo de licencia de servidor en formato ECP o PRVC (archivo .ecp o .prvc). Para obtener estos archivos de licencia, visite My Esri con privilegios para 'realizar una acción de licenciamiento'.

• Inicie sesión en My Esri.
• Seleccione Mis organizaciones > Licencia.
• En Productos de Esri con licencia, haga clic en Iniciar.
• En Producto, seleccione ArcGIS Enterprise; en Versión, seleccione la versión de ArcGIS Enterprise deseada; y, en la lista Tipo de licencia, siga los pasos para generar archivos de licencia para ArcGIS Server y Portal for ArcGIS, incluidos sus roles de servidor, tipos de usuarios y aplicaciones, según corresponda.

Clúster de Kubernetes

Para implementar ArcGIS Enterprise on Kubernetes, debe tener un clúster de Kubernetes en una de las plataformas mencionadas arriba. Para cada entorno compatible, la versión del clúster de Kubernetes debe ser 1.19 o posterior.

Espacio de nombres

ArcGIS Enterprise on 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 on Kubernetes requiere también un espacio de nombres dedicado.

Calcular

ArcGIS Enterprise on 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	3	24	96
Disponibilidad mejorada	4	32	128
Desarrollo	2	16	64

Nota:

ArcGIS Enterprise on 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 on 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.

Cuota de recursos

Los pods de ArcGIS Enterprise on 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.

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

A continuación, se presentan las siguientes recomendaciones de cuotas para cada perfil, basadas en los apartados anteriores. 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 reales.

Perfil de disponibilidad estándar:

spec: 
    hard: 
      limits.cpu: "120" 
      limits.memory: 196Gi 
      requests.cpu: "22" 
      requests.memory: 86Gi

Perfil de disponibilidad mejorada:

spec: 
    hard: 
      limits.cpu: "132" 
      limits.memory: 256Gi 
      requests.cpu: "28" 
      requests.memory: 108Gi

Perfil de desarrollo:

spec: 
    hard: 
      limits.cpu: "86" 
      limits.memory: 154Gi 
      requests.cpu: "14" 
      requests.memory: 58Gi

Seguridad

A continuación, se describen los requisitos de seguridad para ArcGIS Enterprise on 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 on 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 on 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 mmap 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 permite que los contenedores se ejecuten con privilegios o sin privilegios, se requieren las siguientes acciones.

• Ejecutar con privilegios: ArcGIS Enterprise on Kubernetes ejecuta un contenedor inicial con privilegios en el nodo que ejecuta Elasticsearch y no se necesita ninguna acción adicional.
• Ejecutar sin privilegios: si el clúster de Kubernetes tiene definida la seguridad de pod y no permite que los contenedores se ejecuten con privilegios, se aplican las siguientes opciones:
  • Opción 1: el script de implementación de ArcGIS Enterprise on Kubernetes crea una cuenta de servicio bajo su espacio de nombres para ejecutar contenedores. La cuenta de servicio predeterminada es rcgis-admin-serviceaccount. Si el clúster incluye una política de seguridad de pod, debe permitir que la cuenta de servicio ejecute contenedores con privilegios. Para OpenShift, puede otorgar a esta 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-admin-serviceaccount"
    

  • Opción 2: si no puede hacer que la cuenta de servicio se ejecute como contenedor con privilegios, debe preparar cada nodo manualmente ejecutando el siguiente comando como raíz:
    sysctl -w vm.max_map_count=262144
    

Después de preparar los nodos, debe indicarle al script de implementación que no ejecute contenedores con privilegios, de la siguiente forma:

• Vaya al archivo /setup/.install/arcgis-enterprise/arcgis-enterprise.properties.
• Actualice la cadena "ALLOWED_PRIVILEGED_CONTAINERS=${ALLOWED_PRIVILEGED_CONTAINERS:-true}" a "ALLOWED_PRIVILEGED_CONTAINERS=${ALLOWED_PRIVILEGED_CONTAINERS:-false}".
• Guarde el archivo.

El script de implementación no ejecutará el contenedor inicial con privilegios.

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 del espacio de nombres predeterminado utilizan el nombre de host kubernetes.default.svc para las consultas al servidor API.

Red

Entre los requisitos de red se incluyen un nombre de dominio y un equilibrador de carga totalmente calificados. Se proporcionan detalles para cada uno.

Nombre de dominio totalmente calificado

ArcGIS Enterprise on Kubernetes requiere un nombre de dominio totalmente calificado (FQDN) (por ejemplo, map.company.com). Puede utilizar su 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, pero 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 ninguna 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 y Classic 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.

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.

Nota:

El plug-in Azure CNI en AKS no es compatible con esta versión.

Almacenamiento

ArcGIS Enterprise on 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, vSphereVolume, etc.

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:

• 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: almacenamiento para registros e índices, y para datos de entidades alojados para permitir la visualización y el análisis de datos en tiempo real y big data.
• Visor métrico de uso: almacena cuadros de mando predeterminados y personalizados que muestran el uso del servicio SIG.
• Datos métricos de uso: almacena los datos de uso del servicio SIG.

Tenga en cuenta los requisitos de almacenamiento para las necesidades 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 siguientes especificaciones y etiquetas.

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	4	12
queue-volume	1	2	2
relational-volume	2	2	2
spatiotemporal-and-index-volume	1	3	5
usage-metric-volume	1	1	1
usage-metric-viewer-volume	1	1	1

Al configurar una organización con el asistente de configuración, se utilizan las siguientes especificaciones (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 (predeterminada)
in-memory-volume	16	ReadWriteOnce	arcgis/tier=storage, arcgis/app=ignite
item-packages-volume	16	ReadWriteOnce	arcgis/tier=api, arcgis/app=sharing
object-volume	16	ReadWriteOnce	arcgis/tier=storage, arcgis/app=minio
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
usage-metric-viewer-volume	1	ReadWriteOnce	arcgis/tier=storage, arcgis/app=grafana

PV dinámicos

Para el aprovisionamiento dinámico, se requiere una StorageClass. Al configurar la organización con el asistente de instalación, el nombre predeterminado de StorageClass es arcgis-storage-default.

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 con shell de Bash.

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 OpenShift

Certificado TLS

ArcGIS Enterprise on 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 usar un certificado firmado por una autoridad certificadora o un certificado autofirmado, pero se recomienda encarecidamente un certificado firmado por una autoridad certificadora, por motivos de seguridad. 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 on 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 Enterprise on Kubernetes y ArcGIS Pro

Se requiere ArcGIS Pro 2.7 o posterior para consumir servicios de ArcGIS Enterprise on Kubernetes. No se admiten las versiones anteriores.

Se requiere ArcGIS Pro 2.8 o posterior para publicar servicios en ArcGIS Enterprise on Kubernetes.

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. El número de versión de la geodatabase es una combinación de los números de ArcGIS Enterprise y ArcGIS Pro.

Las geodatabases empresariales creadas desde ArcMap no pueden registrarse como elementos de datos.