Controladores de entrada a nivel de clúster

Las organizaciones pueden tener requisitos específicos para la gestión del tráfico de clientes que se enruta a una implementación de ArcGIS Enterprise on Kubernetes. Estos requisitos pueden hacer necesario el uso de funciones avanzadas ofrecidas por soluciones de equilibrio de carga específicas del proveedor que operan en la capa 7 (L7) del modelo OSI, como funciones de firewall de aplicaciones web, enrutamiento basado en rutas y hosts, u otro comportamiento de enrutamiento determinista basado en las cabeceras de las solicitudes de los clientes.

Como administrador, puede utilizar un controlador de entrada a nivel de clúster para enrutar el tráfico de entrada a su implementación de ArcGIS Enterprise on Kubernetes. Los controladores de entrada traducen los objetos de Kubernetes Ingress a reglas de enrutamiento funcionales en las respectivas implementaciones del equilibrador de carga L7. La especificación dentro de un objeto Ingress o de entrada contiene un conjunto de reglas de enrutamiento a uno o más objetos de servicio backend dentro de un espacio de nombres de Kubernetes.

Estos objetos Ingress se actualizan en última instancia a través de equilibradores de carga con la capa 7 habilitada en proveedores de la nube administrada como Amazon Elastic Kubernetes Service (EKS), Microsoft Azure Kubernetes Service (AKS) y Google Kubernetes Engine. La creación de objetos Ingress con anotaciones específicas y nombres ingressClass puede desencadenar el aprovisionamiento y la configuración de los equilibradores de carga, incluidos los agentes de escucha del front-end y back-end y la configuración del grupo objetivo. Estos controladores de entrada a nivel de clúster administran el enrutamiento del tráfico desde el borde de un clúster hasta los servicios expuestos internamente.

Para obtener más información sobre cómo se puede utilizar un controlador de entrada a nivel de clúster para enrutar el tráfico a una implementación de ArcGIS Enterprise on Kubernetes en diferentes plataformas, consulte lo siguiente:

• Utilizar equilibrio de carga de aplicaciones en EKS
• Utilizar el controlador de entrada de la pasarela de aplicaciones en AKS
• Utilizar GKE Ingress para equilibradores de carga de aplicaciones

Se proporcionan datos YAML de entrada generales y específicos de la plataforma que permitirán la implementación y configuración iniciales de los equilibradores de carga de capa 7 mediante la creación de objetos de entrada de Kubernetes. Los datos YAML de entrada se proporcionan en la documentación y como plantillas en la carpeta layer-7-templates. Puede seguir configurando estos objetos de entrada para que se adecuen a las necesidades de la organización al proporcionar anotaciones de objetos de entrada adicionales. También se pueden realizar anotaciones al servicio de controlador de entrada NGINX existente en el clúster cuando sea necesario, y se proporcionan instrucciones sobre cómo realizar estas anotaciones.

Nota:

Algunos proveedores pueden requerir que se actualice la implementación de arcgis-ingress-controller para realizar una conexión adecuada a través de la entrada recién creada. Si recibe un error al acceder a ArcGIS Enterprise Manager después de crear el Ingress, intente ejecutar lo siguiente:

kubectl rollout restart deployment/arcgis-ingress-controller -n <deploymentNamespace>

Requisitos de entrada generales

Si utiliza un controlador de entrada en una plataforma que no se haya especificado en este documento, tenga en cuenta los siguientes requisitos generales:

• Asegúrese de que el servicio arcgis-ingress-nginx en el clúster se utiliza como objetivo back-end al que se enrutará el tráfico del cliente cuando configure el objeto Ingress para enrutar el tráfico a una implementación de ArcGIS Enterprise on Kubernetes.
• Asegúrese de que se utiliza el protocolo TLS al pasar el tráfico desde el equilibrador de carga administrado por el controlador de entrada al controlador de entrada NGINX back-end en el clúster.
• La etiqueta id: custom ingress resource es necesaria y no debe eliminarse. Se utiliza en la secuencia de comandos de implementación para gestionar el objeto de entrada durante la implementación y la desimplementación.

A continuación se muestra un ejemplo generalizado de un YAML de entrada que no es específico de un proveedor y contiene los valores necesarios para enrutar el tráfico a una implementación de ArcGIS Enterprise on Kubernetes:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: arcgis-enterprise-ingress
  namespace: <deploymentNamespace>
  annotations:

  labels:
    id: custom-ingress-resource
spec:
  tls:
    - hosts:
        - <deploymentFQDN>
      secretName: <tlsSecretName>
  rules:
    - host: <deploymentFQDN>
      http:
        paths:
          - backend:
             service:
               name: arcgis-ingress-nginx
               port:
                 number: 443
            path: /<context>
            pathType: Prefix

Nota:

El ejemplo anterior asume que se ha creado un secreto TLS que contiene información de certificado dentro del espacio de nombres de implementación y que se utilizará para configurar un certificado TLS con el controlador de entrada. Algunos proveedores permiten especificar esta información mediante una anotación, que también puede utilizarse.

Requisitos de implementación

Al realizar la implementación de ArcGIS Enterprise on Kubernetes inicialmente, debe indicar que desea utilizar un controlador de entrada a nivel de clúster para enrutar el tráfico a su implementación. La forma de hacerlo dependerá del modo en que ejecute la secuencia de comandos de implementación:

• Si ejecuta la secuencia de comandos en modo automático, configure INGRESS_SERVICE_USE_CLUSTER_IP = true en su archivo deploy.properties. Esta propiedad anulará cualquier valor que se establezca para el parámetro INGRESS_TYPE. Si decide crear el objeto de entrada durante la ejecución de la secuencia de comandos de implementación, configure CLUSTER_INGRESS_CONTROLLER_YAML_FILENAME en la ubicación del archivo YAML de entrada. La creación del objeto de entrada al ejecutar la secuencia de comandos de implementación solo se admite en el caso del equilibrador de carga de aplicaciones AWS, la pasarela de aplicaciones de Azure y el equilibrador de carga de aplicaciones de Google Cloud Platform.
• Si ejecuta el script en modo interactivo, responda no cuando se le pregunte si desea aprovisionar un equilibrador de la nube y yes cuando se le pregunte si va a utilizar un controlador de entrada a nivel de clúster para enrutar el tráfico a su implementación. Esto permitirá que se cree el servicio de controlador de entrada NGINX en el clúster, que permite el enrutamiento adecuado del tráfico del cliente a los extremos de ArcGIS Enterprise solicitados, como tipo ClusterIP.

El equilibrador de carga de capa 7 servirá como punto de acceso para el tráfico del cliente a los servicios dentro del clúster. En ArcGIS Enterprise on Kubernetes, el controlador de entrada a nivel de clúster debe configurarse para pasar tráfico al controlador de entrada integrado implementado como parte de la aplicación.

Nota:

Antes de ArcGIS Enterprise 11.2, la capacidad de crear un servicio de controlador de entrada en el clúster como tipo ClusterIP se proporcionó mediante la opción de especificar si se utilizaría una ruta OpenShift para enrutar el tráfico a la implementación. Esta pregunta se ha modificado en la secuencia de comandos de implementación para preguntar si se utilizará un controlador de entrada a nivel de clúster para enrutar el tráfico a la implementación. Si esta opción está establecida en true, el servicio del controlador de entrada se creará como tipo ClusterIP independientemente de si el INGRESS_TYPE para la implementación se ha establecido en NodePort o LoadBalancer.