Contrôleurs Ingress au niveau du cluster

Il est possible que les organisations aient des exigences spécifiques pour gérer le trafic client qui est acheminé vers un déploiement ArcGIS Enterprise on Kubernetes. Ces exigences peuvent nécessiter l’utilisation de fonctionnalités avancées proposées par des solutions d’équilibrage de la charge propres à certains fournisseurs et qui s’appliquent à la couche 7 (L7) du modèle OSI, par exemple des fonctionnalités WAF (Web Application Firewall), un acheminement basé sur l’hôte ou sur le chemin ou tout autre comportement d’acheminement déterministe basé sur les en-têtes de requête du client.

En tant qu’administrateur, vous pouvez utiliser un contrôleur Ingress au niveau du cluster pour acheminer le trafic entrant vers votre déploiement ArcGIS Enterprise on Kubernetes. Ces contrôleurs Ingress au niveau du cluster permettent aux organisations de bénéficier de ces fonctionnalités. Les contrôleurs Ingress convertissent les objets Ingress Kubernetes en règles d’acheminement fonctionnelles sur les implémentations de l’équilibreur de charge L7 respectives. La spécification au sein d’un objet Ingress contient un ensemble de règles d’acheminement vers un ou plusieurs objets de service back-end au sein de l’espace de noms Kubernetes.

Ces objets Ingress sont finalement actualisés via des équilibreurs de charge tenant compte de la couche 7 sur des fournisseurs Cloud gérés tels que Amazon Elastic Kubernetes Service (EKS), Microsoft Azure Kubernetes Service (AKS) et Google Kubernetes Engine. La création d’objets Ingress avec des annotations spécifiques et des noms ingressClass peut déclencher le provisionnement et la configuration des équilibreurs de charge, y compris des écouteurs front-end et back-end et des paramètres de groupes cibles. Ces contrôleurs Ingress au niveau du cluster gèrent l’acheminement du trafic depuis le bord d’un cluster vers les services exposés en interne.

Pour savoir comment un contrôleur Ingress au niveau du cluster peut servir à acheminer le trafic vers un déploiement ArcGIS Enterprise, consultez les ressources suivantes :

• Utiliser un équilibrage de la charge des applications sur EKS
• Utiliser le contrôleur Ingress Application Gateway sur AKS
• Utiliser GKE Ingress pour les équilibreurs de charge Application Load Balancer

Pour chaque plateforme de déploiement, des données YAML sont fournies pour autoriser le déploiement initial et la configuration des équilibreurs de charge de la couche 7 via la création d’objets Ingress Kubernetes. Vous pouvez compléter la configuration de ces objets Ingress conformément aux objectifs de votre organisation, par exemple en leur appliquant des annotations supplémentaires. Il est possible d’ajouter des annotations au service du contrôleur Ingress NGINX au sein du cluster lorsque cela est nécessaire. Des instructions expliquent comment effectuer ces annotations.

Remarque :

Certains fournisseurs peuvent exiger l’actualisation du déploiement arcgis-ingress-controller pour établir une connexion adéquate via l’objet Ingress récemment créé. Si vous recevez une erreur lors de l’accès à ArcGIS Enterprise Manager après la création de l’objet Ingress, essayez d’exécuter ce qui suit :

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

Conditions requises

Lors du déploiement initial de ArcGIS Enterprise on Kubernetes, vous devez indiquer que vous souhaitez utiliser un contrôleur Ingress au niveau du cluster pour acheminer le trafic vers votre déploiement. La procédure correspondante dépend du mode d’exécution du script de déploiement :

• Si vous exécutez le script en mode silencieux, vous devez définir INGRESS_SERVICE_USE_CLUSTER_IP=true dans votre fichier deploy.properties. Cette propriété remplace la valeur définie pour le paramètre INGRESS_TYPE.
• Si vous exécutez le script en mode interactif, vous devez répondre no à la question vous demandant si vous souhaitez provisionner un équilibreur Cloud, puis répondre yes à la question vous demandant si vous allez utiliser un contrôleur Ingress au niveau du cluster pour acheminer le trafic vers votre déploiement. Cela permettra au service du contrôleur Ingress NGINX au sein du cluster, qui autorise l’acheminement approprié du trafic client vers les points de terminaison ArcGIS Enterprise demandés, d’être créé en tant que type ClusterIP.

L’équilibreur de charge de la couche 7 servira de point d’accès pour le trafic client vers les services au sein du cluster. Pour ArcGIS Enterprise on Kubernetes, le contrôleur Ingress au niveau du cluster doit être configuré de façon à transmettre le trafic au contrôleur Ingress incorporé qui est déployé dans le cadre de l’application.

Remarque :

Avant ArcGIS Enterprise 11.2, la possibilité de créer un service de contrôleur Ingress au sein du cluster en tant que type ClusterIP était proposée via l’option permettant de spécifier si un OpenShift Route sera utilisé pour acheminer le trafic vers le déploiement. Cette question a été modifiée dans le script de déploiement en vue de demander si un contrôleur Ingress au niveau du cluster sera utilisé pour acheminer le trafic vers le déploiement. Si cette option est définie sur true, le service de contrôleur Ingress est créé en tant que type ClusterIP, que la propriété INGRESS_TYPE pour le déploiement ait été définie sur NodePort ou sur LoadBalancer.

Conditions générales concernant le contrôleur Ingress

Vous pouvez utiliser un contrôleur Ingress sur une plateforme qui n’a pas été spécifiée dans ce document. Pour ce faire, les conditions préalables générales indiquées ci-dessus sont également valables. Tenez également compte des points suivants :

• Vérifiez que le service arcgis-ingress-nginx au sein du cluster est utilisé comme cible back-end vers laquelle le trafic client sera acheminé lors de la configuration de l’objet Ingress afin d’acheminer le trafic vers un déploiement ArcGIS Enterprise on Kubernetes.
• Vérifiez que le protocole TLS est utilisé lors de la transmission du trafic à partir de l’équilibreur de charge qui est géré par le contrôleur Ingress vers le contrôleur Ingress NGINX back-end au sein du cluster.

Voici un exemple généralisé de données YAML Ingress qui ne sont pas propres à un fournisseur et qui contiennent les valeurs nécessaires pour acheminer le trafic vers un déploiement ArcGIS Enterprise on Kubernetes :

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

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

Remarque :

L’exemple ci-dessus suppose qu’un secret TLS contenant des informations de certificat a été créé dans l’espace de noms du déploiement et qu’il sera utilisé pour configurer un certificat TLS avec le contrôleur Ingress. Certains fournisseurs permettent de spécifier ces informations via une annotation, qui peut également être utilisée.