Implementar un Red Hat OpenShift Container Platform

Antes de implementar ArcGIS Enterprise on Kubernetes en RedHat OpenShift (RHOS), debe preparar un clúster de RHOS que cumpla los requisitos del sistema de ArcGIS Enterprise.

La preparación de un clúster de RedHat OpenShift incluye pasos comunes a todos los entornos compatibles, como la configuración del clúster de Kubernetes y los nodos correspondientes, y pasos específicos del entorno, como la creación de una restricción de contexto de seguridad (SCC) dedicada y la gestión de la entrada a la aplicación.

Revise los siguientes pasos y consulte la documentación de RedHat OpenShift para obtener instrucciones más detalladas sobre cómo preparar su entorno.

  1. Cree un clúster de RedHat OpenShift.

    Existen numerosos métodos para implementar un clúster de RHOS. Para implementaciones en sus instalaciones, consulte la documentación de RedHat. Para implementaciones basadas en la nube, consulte la documentación de RedHat OpenShift en AWS (ROSA) o Azure RedHat OpenShift.

  2. Actualice la configuración de oc (kubectl).

    Después de crear el clúster, la interfaz de línea de comandos (CLI) de OpenShift se puede utilizar para extraer la información de conexión de usuario autenticado en su archivo kubeconfig. Puede hacerlo con el siguiente comando:

    oc login https://<serverName>:<serverPort>
    
  3. Cree clases de almacenamiento.

    Para adaptar las propiedades de reclaimPolicy yallowVolumeExpansion a las necesidades de su organización y cargas de trabajo, se recomienda crear una clase de almacenamiento que haga referencia a uno de los aprovisionadores compatibles, como Cinder, Manila o vSphere Volume. El archivo YAML pertinente debe aplicarse al clúster mediante el siguiente comando:

    oc apply -f <storageClass.yaml>
    
    Consulte un ejemplo de clase de almacenamiento YAML predeterminada y un ejemplo de clase de almacenamiento YAML de copia de seguridad para obtener más información.
  4. Administre las restricciones del contexto de seguridad.

    En OpenShift, los SCC actúan como un controlador de admisión personalizado para los pods antes de la programación. De forma predeterminada, todos los pods se admiten basándose en los SCC restricted o restricted-v2 ya que el grupo permitido es system:authenticated.

    Dependiendo de su configuración, puede que tenga que permitir privilegios adicionales para cumplir los requisitos de ArcGIS Enterprise. Revise lo siguiente:
    1. Permita que los pods se ejecuten con un fsGroup específico.

      Las cargas de trabajo de ArcGIS Enterprise tienen un valor de fsGroup codificado para inicializar los permisos de volumen en volúmenes persistentes de almacenamiento en bloques recién aprovisionados. Este fsGroup debe ser permitido por un SCC ya que de forma predeterminada se ejecuta como un rango arbitrario. Para ello, debe actualizarse una copia del SCC restricted o restricted-v2 con la siguiente sección:

      fsGroup:
         ranges: 
           - max: 117932853
             min: 117932853
         type: MustRunAs
         groups:
            - 'system:serviceaccounts:<deployment-project>'
      

    2. Permita la vinculación en puertos privilegiados para el controlador de entrada.

      En las versiones de OpenShift anteriores a la 4.11, el contexto restringido no permite añadir la capacidad NET_BIND_SERVICE a los pods, necesaria para el controlador de entrada. Debe clonarse un nuevo SCC de la política restringida y añadirse la siguiente sección:

      allowedCapabilities: 
         - NET_BIND_SERVICE
      

      Este SCC debería permitir que la cuenta de servicio de arcgis-ingress-serviceaccount permita que el controlador de entrada se inicie correctamente.

      oc adm policy add-scc-to-user restricted-esri system:serviceaccount:<deployment-project>:arcgis-ingress-serviceaccount
      

      Para OpenShift versión 4.11 y posteriores, el SCC de restricted-v2 ya tiene la capacidad requerida permitida.

    3. Aumente las áreas máximas del mapa de memoria.

      El StatefulSet espaciotemporal requiere que el nodo subyacente tenga un valor incrementado para vm.max_map_count. Esto se habilita de forma predeterminada mediante un contenedor init, pero el comando requiere acceso privilegiado al host subyacente para ejecutarse:

      sysctl -w vm.max_map_count=262144
      

      Los nodos trabajadores pueden alterarse al arrancar haciendo modificaciones en el archivo de configuración de Ignition para ejecutar ese comando durante el arranque (bootstrap). La propiedad para ALLOW_PRIVILEGED_CONTAINERS debe establecerse en falso en el script de implementación.

      Consulte la Documentación de RedHat OpenShift para obtener más detalles.

      Alternativamente, debe dar a la cuenta de servicio de arcgis-elastic-serviceaccount permiso para ejecutar un contenedor privilegiado para permitir que el contenedor init ejecute el comando sysctl requerido.

      oc adm policy add-scc-to-user privileged-esri system:serviceaccount:<deployment-project>:arcgis-elastic-serviceaccount
      

    Revise los archivos SCC YAML de ejemplo para obtener más información.

  5. Configure Red Hat OpenShift Routes.

    OpenShift incluye un controlador de entrada listo para usar que se puede utilizar junto con el controlador de entrada suministrado con ArcGIS Enterprise on Kubernetes. Si se crea una OpenShift Route a través de la línea de comandos, se puede crear utilizando el yaml de ejemplo. Para configurar una ruta a través de la consola de OpenShift, primero se debe ejecutar el script de despliegue y, a continuación, se puede crear una ruta para hacer referencia al objetivo de servicio interno.

    Al responder yes a la pregunta de OpenShift Route en el script de despliegue, el servicio arcgis-ingress-controller no se expondrá fuera de la subred del clúster y se creará como el tipo ClusterIP.

    Dependiendo de dónde prefiera finalizar el cliente SSL, la ruta segura debería usar re-encrypt o passthrough como modo de finalización. Si se selecciona re-encrypt, se requerirá un certificado TLS como entrada para la ruta, mientras que passthrough presentará a los clientes externos el certificado TLS definido durante la fase de implementación.