A continuación, se describen el hardware y la infraestructura mínimos necesarios para ejecutar ArcGIS Enterprise on Kubernetes en la versión 11.3. 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:
- Red Hat OpenShift Container Platform (RHOS)
- Amazon Elastic Kubernetes Service (EKS)
- Google Kubernetes Engine (GKE)
- Microsoft Azure Kubernetes Service (AKS)
- Rancher Kubernetes Engine (RKE y RKE2)
Se recomienda que deshabilite la actualización automática en su clúster Kubernetes. Cuando su clúster esté habilitado con la actualización automática, los nodos se actualizarán automáticamente con la última versión de Kubernetes y es posible que estas versiones futuras aún no sean compatibles con ArcGIS Enterprise.
Precaución:
Para garantizar una compatibilidad y un soporte completos, confirme que su versión de Kubernetes se encuentra dentro del rango admitido antes de actualizar ArcGIS Enterprise on Kubernetes.Las siguientes versiones han sido probadas y son compatibles para cada entorno:
| Entorno compatible | Versión de Kubernetes compatible |
|---|---|
Servicios Kubernetes administrados en la nube (AKS, EKS, GKE) Red Hat OpenShift Container Platform(incluidos ROSA y ARO) [4.14] RKE y RKE2 | 1.27 - 1.29 |
Nota:
ArcGIS Enterprise on Kubernetes solo se puede utilizar en las CPU que se ajusten a la arquitectura x86_64 (64 bits). Los nodos de trabajo deben estar basados en Linux.
Registro de contenedor
Las imágenes de contenedor de ArcGIS Enterprise on Kubernetes son accesibles desde una organización de Docker Hub privado. Esri proporcionará acceso a los repositorios de esta organización a aquellos que implementan ArcGIS Enterprise on Kubernetes. Cuando implemente en un entorno desconectado, necesitará insertar imágenes desde la organización de Docker Hub privado a su propio registro de contenedores privados que está accesible desde su clúster.
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 on Kubernetes en formato JSON (archivo .json). Para obtener este archivo de licencia, visite My Esri con privilegios para realizar una acción de licenciamiento.
Nodos trabajadores
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.
Nota:
A continuación, se indican los requisitos de nodo mínimos para instalar el software. Los requisitos varían en función del perfil de arquitectura seleccionado. Se requieren nodos trabajadores adicionales para compatibilizar el escalado de cargas de trabajo y la habilitación de capacidades en su organización.Se recomienda que cada nodo de trabajador/agente tenga como mínimo 8 CPU y 32 GiB de memoria. Para compensar la descarga de las imágenes de contenedor asociadas a ArcGIS Enterprise on Kubernetes, también se recomienda tener un tamaño mínimo de disco raíz de 100 GiB.
| Perfil de arquitectura | Número mínimo de nodos trabajador/agente | CPU mínimas totales | GiB mínimos totales |
|---|---|---|---|
Disponibilidad mejorada | 5 | 40 | 160 |
Disponibilidad estándar | 4 | 32 | 128 |
Desarrollo | 3 | 24 | 96 |
Los pods de la implementación de ArcGIS Enterprise on Kubernetes se distribuyen entre los nodos de trabajador del clúster. Los relojes de los nodos trabajadores deben sincronizarse con una fuente común para que las horas sean coherentes dentro del clúster. Cuando escale la implementación o agregue otra al implementación de ArcGIS Enterprise al clúster, deberá aprovisionar el 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 con cada perfil de arquitectura. A medida que escala horizontalmente o agrega funcionalidad, el número de pods aumenta.
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 un ClusterRole predeterminado al usuario creando un RoleBinding en el espacio de nombres. Para obtener más información, consulte el recurso de roles RBAC.
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 nombre de dominio (FQDN) y un equilibrador de carga totalmente calificados o un proxy inverso que dirige el tráfico de los clientes a los objetivos del back-end configurados a través del puerto HTTPS estándar (443). A continuación se indican los detalles de cada uno de ellos.
Nombre de dominio totalmente calificado
ArcGIS Enterprise on Kubernetes requiere un FQDN (por ejemplo, map.company.com). Puede utilizar un sistema de nombres de dominio (DNS) existente para crear un registro A o CNAME, o integrar un servicio DNS de un proveedor de nube como Amazon Route 53. Puede crear el registro de DNS después de la implementación; no obstante, el FQDN debe proporcionarse durante el proceso de implementación. En esta versión, el FQDN no se puede modificar después de la implementación.
Equilibrador de carga
Se puede utilizar un equilibrador de carga para dirigir el tráfico a su implementación de ArcGIS Enterprise on Kubernetes. Puede proporcionar los equilibradores de carga de la capa 4 y la capa 7 desde la secuencia de comandos de implementación sin necesidad de configuración manual. Los equilibradores de carga que se integran con su implementación desde la secuencia de comandos de implementación dirigen el tráfico directamente hacia el pod controlador de entrada NGINX en clúster.
Como alternativa, puede utilizar Web Adaptor de ArcGIS Enterprise on Kubernetes para dirigir el tráfico a su implementación, que requiere que el tráfico entrante se envíe a nodos trabajadores de la implementación en un puerto concreto.
Se pueden proporcionar los siguientes equilibradores de carga de la capa 4 desde la secuencia de comandos 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.
- Google Cloud Platform TCP Load Balancer (a través de Internet o interno): se pueden especificar en el script de implementación una dirección IP pública estática proporcionada previamente.
Los equilibradores de carga especificados antes pueden personalizarse utilizando anotaciones en el objeto del servicio Kubernetes subyacente. Por ejemplo, puede habilitar el equilibrado de cargas entre zonas en un equilibrador de carga de red en AWS o situar un equilibrador de carga de Azure BLOB en un grupo de recursos específico. El archivo de plantilla deploy.properties incluido con la secuencia de comandos de implementación contiene ejemplos de cómo pueden especificarse estas anotaciones durante la implementación automática.
La secuencia de comandos de implementación puede utilizarse para emplear las capacidades de equilibrio de carga de capa 7, como un firewall de aplicaciones web, o cumplir los requisitos de la organización para la entrada a la aplicación implementada mediante un controlador de entrada preexistente. Los equilibradores de carga de la capa 7 siguientes pueden implementarse o integrarse directamente desde la secuencia de comandos de implementación:
- Equilibrador de carga de aplicaciones AWS
Nota:
Se requiere el complemento AWS Load Balancer Controller para crear equilibradores de carga de aplicaciones en una subred pública o privada.
- Pasarela de aplicaciones de Azure
- Equilibrador de carga de aplicaciones de Google Cloud Platform
El controlador de entrada implementado en el nivel de clúster utilizará estos equilibradores de carga para implementar reglas de entrada de nivel de clúster con el fin de dirigir el tráfico entrante hacia una implementación de ArcGIS Enterprise on Kubernetes. Para implementar estos equilibradores de carga desde la secuencia de comandos de implementación antes de la implementación automática, puede modificar un archivo YAML de plantilla en la carpeta layer-7-templates, guardarlo en su estación de trabajo de cliente y especificar esta ubicación para el parámetro CLUSTER_INGRESS_CONTROLLER_YAML_FILENAME. Consulte Controladores de entrada a nivel de clúster para obtener más información.
Cuando utilice un balanceador de carga autogestionado o un proxy inverso como NGINX, el encabezado de X-Forwarded-Host debe configurarse en el valor del encabezado del host de la URL orientada al cliente para garantizar que el tráfico se dirija a la URL de su organización de ArcGIS Enterprise de manera adecuada. En NGINX puede lograrse mediante el uso de la directiva siguiente: proxy_set_header X-Forwarded-Host $host;.
Nota:
ArcGIS Enterprise no admite la descarga de SSL por medio de un equilibrador de carga/proxy inverso. Si su configuración usa un proxy inverso, debe redirigir a ArcGIS Web Adaptor o directamente a la organización a través de HTTPS.
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 on 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 dos 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 on 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 on Kubernetes requiere volúmenes persistentes (PV) para el almacenamiento del sistema, que se pueden proporcionar de forma dinámica a través de una clase de almacenamiento o de forma estática a través de un administrador antes de crear la organización. Obtenga más información sobre el aprovisionamiento estático y el aprovisionamiento dinámico.
Las cargas de trabajo con estado de ArcGIS Enterprise incluyen sistemas de administración de bases de datos relacionales y bases de datos NoSQL. Se recomienda aprovisionar los volúmenes persistentes en dispositivos de almacenamiento en bloque que proporcionen baja latencia, como volúmenes EBS cuando se utilice EKS, Azure Disks cuando se utilice AKS, Persistent Disks cuando se utilice GKE y volúmenes vSphereVolume o Longhorn cuando se realice la implementación en clústeres autogestionados.
Puesto que estos volúmenes persistentes almacenan los datos y la configuración de su organización, debe protegerlos mediante políticas de seguridad restrictivas. Para los volúmenes persistentes basados en almacenamiento de archivos de red, como NFS, Azure Files y GlusterFS, asegúrese de que los permisos están configurados para evitar accesos no autorizados. Para el almacenamiento en bloques, como EBS, Azure Disk, vSphereVolume y volúmenes Longhorn, asegúrese de que el acceso a los volúmenes de almacenamiento esté restringido únicamente a los usuarios que lo necesiten.
A continuación, se describen los volúmenes de almacenamiento y sus fines previstos:
Nota:
Se establecen los requisitos de volumen persistente para 11.3 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 escenas y teselas alojadas y salida de geoprocesamiento.
- 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.
Nota:
Las capas de entidades alojadas espaciotemporales no se admiten en esta versión.
- 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.
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. El usuario que ejecuta los scripts debe tener acceso de lectura y escritura para que los scripts puedan escribir archivos de recursos temporales en subdirectorios.
Nota:
Debido a problemas de compatibilidad conocidos, los emuladores de Linux no son compatibles con la implementación de ArcGIS Enterprise on 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.
Nota:
La versión del cliente kubectl debe estar dentro de una versión menor de la versión del servidor de la API de Kubernetes. Por ejemplo, kubectl 1.28 es compatible con las versiones de clúster Kubernetes 1.27-1.29.
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:
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 de seguridad de la capa de transporte (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 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 Pro
- ArcGIS Pro 3.3 es la versión complementaria de ArcGIS Enterprise on Kubernetes 11.3. Para beneficiarse de las últimas funciones disponibles, utilice ArcGIS Pro 3.3.
- Para publicar servicios en ArcGIS Enterprise on Kubernetes, se requiere ArcGIS Pro 2.8 o versiones posteriores.
- Para consumir servicios desde ArcGIS Enterprise on 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.3.0.Para obtener más información, consulte Compatibilidad entre clientes y geodatabases.