Configuration du système

L’infrastructure et la configuration matérielle minimum requises pour exécuter ArcGIS Enterprise on Kubernetes 10.9.1 sont décrites ci-dessous.

Environnements pris en charge

La configuration système requise et les spécifications s’appliquent à tous les environnements pris en charge sauf mention contraire. Dans cette version préliminaire, les environnements suivants sont pris en charge :

• Centre de données sur site
  • Red Hat OpenShift Container Platform 4.6 - 4.8
• Services Kubernetes gérés sur le Cloud
  • Amazon Elastic Kubernetes Service (EKS)
  • Google Kubernetes Engine (GKE)
  • Microsoft Azure Kubernetes Service (AKS)

Registre de conteneur

Les images de conteneur pour ArcGIS Enterprise on Kubernetes sont accessibles depuis un référentiel Hub Docker privé. Esri permet aux personnes qui déploient ArcGIS Enterprise on Kubernetes d’accéder à ce référentiel.

Obtenir des licences Esri

Pour autoriser votre organisation ArcGIS Enterprise durant le déploiement, vous devez avoir un fichier de licence de type utilisation au format JSON (fichier .json) et un fichier de licence serveur au format ECP ou PRVC (fichier .ecp ou .prvc). Pour obtenir ces fichiers de licence, consultez My Esri avec les privilèges « Agir sur les licences » et procédez comme suit :

1. Connectez-vous à My Esri.
2. Sélectionnez My Organizations (Mes organisations) > Licensing (Licences).
3. Sous License Esri Products (Licences pour les produits Esri), cliquez sur Start (Démarrer).
4. Pour Product (Produit), sélectionnez ArcGIS Enterprise. Pour Version, sélectionnez la version ArcGIS Enterprise appropriée et dans la liste License type (Type de licence), suivez les étapes de génération des fichiers de licence pour ArcGIS Server et Portal for ArcGIS, y compris les rôles de serveur, types d’utilisateurs et applications, le cas échéant.

Cluster Kubernetes

Pour déployer ArcGIS Enterprise on Kubernetes, vous devez avoir un cluster Kubernetes sur l’un des environnements mentionnés ci-dessus. Pour chaque environnement pris en charge, les versions de cluster Kubernetes suivantes sont prises en charge.

Version ArcGIS Enterprise on Kubernetes	Version de cluster Kubernetes prise en charge
10.9.1	1.19 - 1.21

Remarque :

Lorsque vous créez un cluster dans GKE, vous devez utiliser le mode de fonctionnement Standard. Le mode de pilotage automatique n’est pas pris en charge.

Espace de noms

ArcGIS Enterprise on Kubernetes a besoin d’un espace de noms dédié. L’espace de noms doit être créé avant d’exécuter le script de déploiement. Chaque déploiement de ArcGIS Enterprise on Kubernetes a également besoin d’un espace de noms dédié.

Processeur et mémoire

ArcGIS Enterprise on Kubernetes est déployé avec l’un des trois profils d’architecture. Les recommandations liées aux limites et demandes de ressources (processeur et mémoire) ainsi qu’aux exigences de calcul global varient selon le profil sélectionné. Voici les recommandations pour chaque profil.

Vous trouverez ci-dessous la configuration minimale requise concernant les nœuds pour chaque profil d’architecture. Il est recommandé que chaque nœud Worker/Agent dispose d’un minimum de 8 processeurs et de 32 Gio de mémoire.

Profil d’architecture	Nœuds Worker/Agent minimum	Capacité de processeur totale minimum	Capacité de mémoire totale minimum
Standard availability (Disponibilité standard)	3	24	96
Enhanced availability (Disponibilité améliorée)	4	32	128
Développement	2	16	64

Remarque :

ArcGIS Enterprise on Kubernetes n’est pris en charge que sur des processeurs conformes à l’architecture x86_64 (64 bits).

Les pods dans le déploiement ArcGIS Enterprise on Kubernetes sont distribués sur les nœuds Worker dans l’agrégat. Lors de l’adaptation du déploiement ou de l’ajout d’un autre déploiement ArcGIS Enterprise dans l’agrégat, vous devez provisionner le matériel comme il convient. Cela peut nécessiter une augmentation du nombre maximal par défaut de pods par nœud. Le nombre de pods qui sont créés à l’origine varie avec chaque profil d’architecture. Le nombre de pods augmente en cas d’adaptation horizontale ou d’ajout de nouvelles fonctions.

Remarque :

ArcGIS Enterprise on Kubernetes ne prend pas en charge les images nœuds Windows Server dans les environnements GKE.

Objet de quota de ressources

Les pods ArcGIS Enterprise on Kubernetes ont défini des demandes et des limites quant au processeur et à la mémoire. Si l’espace de noms a un objet ResourceQuota, le quota doit être supérieur à la somme de toutes les demandes et limites des pods. Ces valeurs varient selon le profil d’architecture que vous avez sélectionné, comme décrit ci-dessous.

Remarque :

Si vous mettez à niveau le logiciel pour passer à la version 10.9.1, vous devez d’abord mettre à jour les valeurs de quota des ressources dans l’espace de noms selon la configuration requise de la version 10.9.1.

Il est recommandé de réserver au moins 10 pour cent des ressources de demande pour que les nœuds de l’agrégat fonctionnent correctement.

Les recommandations suivantes en termes de quota pour chaque profil tiennent compte des réserves susmentionnées. Les limites illustrées sont des emplacements réservés et doivent être configurées conformément à vos critères d’évolutivité :

Profil de disponibilité standard :

spec: 
    hard: 
      limits.cpu: "128" 
      limits.memory: 228Gi 
      requests.cpu: "22" 
      requests.memory: 86Gi

Profil de disponibilité avancé :

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

Profil de développement :

spec: 
    hard: 
      limits.cpu: "96" 
      limits.memory: 164Gi 
      requests.cpu: "14" 
      requests.memory: 72Gi

Sécurité

Les conditions requises en matière de sécurité pour ArcGIS Enterprise on Kubernetes sont décrites ci-dessous.

Contrôle d’accès basé sur le rôle

Le contrôle d’accès basé sur le rôle doit être activé sur le cluster Kubernetes. Pour déployer ArcGIS Enterprise on Kubernetes, vous n’avez pas besoin de privilèges d’administration de cluster. En l’absence de tels privilèges, l’utilisateur doit disposer des privilèges d’administration d’espaces de noms minimum. Vous pouvez affecter le rôle d’agrégat par défaut admin à l’utilisateur en créant un RoleBinding dans l’espace de noms.

Stratégie de sécurité des pods (contraintes relatives au contexte de sécurité dans OpenShift) et mémoire virtuelle

ArcGIS Enterprise on Kubernetes déploie Elasticsearch pour prendre en charge différentes fonctionnalités de l’organisation ArcGIS Enterprise. Par défaut, Elasticsearch utilise un répertoire mmapfs pour stocker les index requis. Les limites du système d’exploitation par défaut fixées à mmap peuvent être insuffisantes pour le déploiement. Elasticsearch recommande une valeur par défaut vm.max_map_count égale à 262 144. Pour changer la valeur par défaut, un privilège (racine) élevé est requis sur chaque nœud.

Selon que l’agrégat Kubernetes autorise l’exécution des conteneurs en tant que conteneurs privilégiés ou non, les actions suivantes s’imposent :

• Exécuter en mode privilégié : ArcGIS Enterprise on Kubernetes applique un conteneur init privilégié sur le nœud exécutant Elasticsearch ; aucune autre action n’est nécessaire.
• Exécuter en mode non privilégié : si la sécurité des pods de l’agrégat Kubernetes est définie et n’autorise pas l’exécution des conteneurs en mode privilégié, les options suivantes s’appliquent :
  • Option 1 : le script de déploiement ArcGIS Enterprise on Kubernetes crée un compte de service sous son espace de noms pour exécuter les conteneurs. Le compte de service par défaut est arcgis-admin-serviceaccount. Si l’agrégat inclut une stratégie de sécurité des pods, vous devez autoriser le compte de service à exécuter les conteneurs en mode privilégié. Dans OpenShift, vous pouvez accorder l’accès du compte de service aux contraintes du contexte de sécurité privilégié en ajoutant les éléments suivants dans la section utilisateur :
    “-system:serviceaccount: <Namespace>:arcgis-admin-serviceaccount"
    

  • Option 2 : si vous ne pouvez pas accorder le droit au compte de service de fonctionner comme un conteneur privilégié, vous devez préparer manuellement chaque nœud en exécutant la commande suivante à la racine :
    sysctl -w vm.max_map_count=262144
    

Si vous utilisez Kubernetes NetworkPolicies, vérifiez que les communications pod vers pod et pod vers service ininterrompues sont autorisées dans l’espace de noms ArcGIS Enterprise.

Vérifiez en outre que les pods dans l’espace de noms ont accès au serveur d’API Kubernetes. Le serveur d’API est accessible via un service nommé Kubernetes dans l’espace de noms par défaut. Les pods ArcGIS Enterprise utilisent le nom de domaine complet kubernetes.default.svc.cluster.local pour interroger le serveur d’API.

Remarque :

cluster.local est le domaine par défaut de l’agrégat.

Remarque :

Les pods dans le cluster doivent être autorisés à s’exécuter avec un identifiant FSGroup et un ID SupplementalGroup égal à 117932853.

Réseau

Parmi les exigences réseau figurent un nom de domaine complet et un équilibrage de la charge. Des informations détaillées sur chacun sont fournies ci-dessous.

Nom de domaine complet

ArcGIS Enterprise on Kubernetes requiert un nom de domaine complet (map.entreprise.com, par exemple). Vous pouvez utiliser un système de nom de domaine (DNS) existant pour en créer un ou utiliser un service DNS Cloud tel qu’Amazon Route 53. Vous pouvez créer l’enregistrement DNS après le déploiement, mais vous devez fournir sa valeur au cours du déploiement. Dans cette version préliminaire, le FQDN ne peut pas être modifié après déploiement.

Equilibreur de charge

Un équilibreur de charge est nécessaire pour faire transiter le trafic par chaque nœud worker. Lorsque vous utilisez AKS ou EKS, vous pouvez provisionner les systèmes d’équilibrage de la charge suivants à partir du script de déploiement, ceci sans aucune configuration manuelle :

• Équilibreur de charge Azure (public ou interne) : une adresse IP publique statique préprovisionnée et une étiquette DNS peuvent être spécifiées dans le script de déploiement.
• Équilibreur de charge de réseau AWS (internet ou interne) : d’autres services d’équilibrage de la charge peuvent être utilisés. Toutefois, ils doivent être configurés manuellement pour chaque nœud du cluster.

Dans une plateforme de conteneurs OpenShift, les routes peuvent être configurées lorsqu’elles sont dirigées sur le service du contrôleur ingress.

Vous pouvez utiliser un équilibreur de charge auto-géré pointant vers les nœuds worker sur le service du contrôleur ingress NodePort. Pour en savoir plus, lisez la description des paramètres dans le guide de déploiement relative à l’équilibrage de la charge.

Lors de l’utilisation d’un équilibreur de charge de réseau auto-géré ou d’un proxy inverse tel que NGINX, spécifiez la connexion suivante : proxy_set_header X-Forwarded-Host $host;. Cet en-tête est nécessaire pour s’assurer que le trafic est correctement acheminé vers l’URL de votre organisationArcGIS Enterprise.

Stockage système

ArcGIS Enterprise on Kubernetes requiert des volumes persistants pour le stockage système. Ils peuvent être provisionnés comme des volumes dynamiques ou statiques. Lors de la création de volumes persistants d’un autre type, vous pouvez utiliser des tailles sur mesure (taille supérieure) et des étiquettes. Les charges applicatives avec état de ArcGIS Enterprise incluent des systèmes de gestion de bases de données relationnelles et des bases de données NoSQL. Il est recommandé d’utiliser des périphériques de stockage de blocs qui offrent une faible latence, tels que les volumes EBS, Azure Disk ou vSphereVolume.

Comme ces volumes persistants stockent des données et des paramètres, ils doivent faire l’objet de mesures de sécurité particulières. Pour les volumes persistants basés sur le stockage de fichiers, tels que NFS, Azure File ou Gluster, vérifiez que les autorisations sur ces répertoires sont définies de façon à empêcher tout accès non autorisé. Pour le stockage de blocs, tels que les volumes EBS, Azure Disk et iSCSI, vérifiez que l’utilisation des périphériques est limitée aux utilisateurs qui ont besoin d’y accéder.

Voici une description des volumes de stockage et de leur objectif :

Remarque :

Les exigences liées au volume persistant sont indiquées pour la version 10.9.1 et peuvent différer des versions précédentes.

• En mémoire : stocke temporairement les ressources système.
• Paquetage d’éléments : stocke des charges et des paquetages volumineux pour prendre en charge les processus de publication.
• Objet : stocke les contenus, les caches de couches d’images et de tuiles hébergées et les sorties de géotraitement qui ont été chargés et enregistrés. Quatre volumes sont nécessaires au déploiement.
• File d’attente : stocke les tâches de géotraitement asynchrones.
• Relationnel : stocke les données d’entité hébergées et les aspects administratifs, tels que les paramètres de personnalisation et de configuration. Deux volumes sont nécessaires au déploiement.
• Spatio-temporel et index : stocke des fichiers journaux, des index ainsi que des données d’entité hébergées afin de prendre en charge les visualisations et analyses de Big Data en temps réel.
• Données des mesures d’utilisation : stocke les données d’utilisation des services SIG.

Étudiez les exigences en matière de stockage de votre organisation et définissez la taille de chaque volume persistant en conséquence.

Volumes persistants statiques

Si vous provisionnez des volumes persistants statiques avant le déploiement, les spécifications et les étiquettes décrites ci-dessous sont recommandées.

Le nombre de volumes persistants requis pour chaque profil d’architecture est fourni.

Volume	Profil Development (Développement)	Profil Standard availability (Disponibilité standard)	Profil Enhanced availability (Disponibilité améliorée)
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

Lorsque vous configurez une organisation avec l’assistant de configuration, les spécifications telles que celles qui suivent (nom du volume, taille, application et niveau) servent à la liaison du volume, mais vous pouvez les personnaliser comme il convient :

Volume	Taille en Gio (minimum)	Mode d’accès	Etiqueter
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

Volumes persistants dynamiques

Pour le provisionnement dynamique, une classe StorageClass est requise.

Le paramètre reclaimPolicy dans la classe StorageClass doit être défini sur retain.

Remarque :

Tous les types de machine virtuelle ne prennent pas en charge les disques Premium dans Azure. Utilisez un disque Premium lorsque le type de machine virtuelle le prend en charge.

• Pour ce qui concerne AKS, voici un exemple de définition StorageClass avec un disque Premium Azure :
  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
  

• Pour ce qui concerne EKS, voici un exemple de définition StorageClass avec des volumes EBS de type 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
  

Vous pouvez également utiliser les classes de stockage par défaut fournies avec un cluster AKS ou EKS. Dans AKS, il s’agit des classes de stockage par défaut (disque Azure) ou managed-premium. Dans EKS, il s’agit d’une classe de stockage GP2.

Conditions requises pour le stockage post-déploiement

Des conditions supplémentaires pour le stockage post-déploiement s’appliquent aux volumes persistants de paquetage d’éléments afin d’effectuer des mises à niveau et de mettre à l’échelle le déploiement de l’API du portail comme indiqué ci-dessous.

Le type de stockage provisionné que vous configurez durant le déploiement détermine les conditions requises des mises à niveau et de la mise à l’échelle :

• Volumes persistants dynamiques : le stockage est mis à l’échelle et ajusté par le logiciel dans la mesure où le stockage suffisant est disponible et que les spécifications de classe de stockage sont satisfaites.
• Volumes persistants statiques : un administrateur devra provisionner des volumes persistants de paquetage d’élément selon les mêmes spécifications (étiquettes, taille et mode d’accès) que celles qui ont été indiquées durant le déploiement pour la prise en charge des workflows de mise à niveau et de mise à l’échelle.

Mises à niveau

Avant toute mise à niveau, chaque pod dans le déploiement de l’API du portail de l’organisation a été configuré avec un volume persistant de paquetage d’élément. En préparation d’une mise à niveau, chaque pod inclus dans le déploiement de l’API du portail doit être configuré avec un volume persistant supplémentaire.

Si, par exemple, avant une mise à niveau, le déploiement de l’API du portail est configuré avec trois pods en cours d’exécution, six volumes persistants au total doivent être provisionnés et configurés selon des spécifications équivalentes à celles qui ont été indiquées durant le déploiement.

Une fois la mise à niveau terminée, le déploiement de l’API du portail utilisera les volumes persistants qui viennent d’être provisionnés et la réclamation de volume persistant ; le jeu d’origine peut être supprimé.

Mettre à l’échelle l’API du portail

Pour mettre à l’échelle le déploiement de l’API du portail (et augmenter le nombre de pods participants), un volume persistant de paquetage d’élément supplémentaire est nécessaire pour chaque pod supplémentaire qui est ajouté au déploiement. Si, par exemple, l’organisation requiet trois pods pour le déploiement de l’API du portail, au moins trois volumes persistants de paquetage d’élément doivent être provisionnés et configurés selon des spécifications équivalentes à celles qui ont été indiquées durant le déploiement.

Poste de travail client

Les scripts de déploiement sont des scripts bash qui peuvent être exécutés sur un poste de travail client à distance.

Remarque :

Le poste de travail client utilisé doit être conforme aux environnements pris en charge.

Vous avez besoin des éléments suivants lors de la configuration de votre poste de travail client (les liens de téléchargement sont fournis) :

• Kubectl
• Interface de ligne de commande spécifique d’un environnement

Kubectl est une condition préalable à l’exécution d’un script de déploiement. Utilisez l’installation et la configuration de Kubectl pour télécharger l’outil de ligne de commande Kubernetes.

Lors de la mise en œuvre de votre déploiement, vous pouvez utiliser les outils de ligne de commande correspondant à votre environnement. Utilisez les liens suivants pour télécharger une interface de ligne de commande spécifique :

• Interface de ligne de commande Azure
• Interface de ligne de commande AWS
• Interface de ligne de commande GKE
• Interface de ligne de commande OpenShift

Certificat TLS

ArcGIS Enterprise on Kubernetes utilise un contrôleur ingress basé sur NGINX. Le contrôleur ingress est un espace de noms à portée limitée et est déployé pour écouter uniquement le trafic ingress de l’espace de noms ArcGIS Enterprise. Un certificat TLS est requis avec le nom du domaine complet (FQDN) dans le nom courant du certificat et l’autre nom de l’objet. Vous pouvez utiliser un certificat signé par une autorité de certification ou un certificat auto-signé. Cependant, pour des raisons de sécurité, il est recommandé d’utiliser un certificat signé par une autorité de certification. Il s’agit du certificat TLS par défaut pour le contrôleur ingress.  Les options du certificat suivantes sont disponibles dans le script de déploiement afin d’appliquer un certificat TLS pour le trafic ingress :

• Un secret TLS existant qui contient une clé privée et un certificat
• Un fichier .pfx qui contient une clé privée et un certificat
• Une clé privée au format PEM et un certificat
• Un certificat auto-signé

ArcGIS Enterprise on Kubernetes prend en charge l’utilisation d’un certificat TLS pour le contrôleur ingress ; il est émis et géré par Kubernetes cert-manager. Ce certificat doit être stocké dans un secret TLS dans le même espace de noms que ArcGIS Enterprise. Le secret TLS peut ensuite être référencé pendant le déploiement ou une fois que l’organisation ArcGIS Enterprise a été créée.

ArcGIS Enterprise on Kubernetes et ArcGIS Pro

ArcGIS Pro 2.7 ou une version ultérieure est requis pour consommer les services de ArcGIS Enterprise on Kubernetes. Les versions antérieures ne sont pas prises en charge.

ArcGIS Pro 2.8 ou une version ultérieure est requis pour publier des services sur ArcGIS Enterprise on Kubernetes.

Lorsque vous inscrivez un élément de data store à partir d’une géodatabase d’entreprise, la version de la géodatabase doit être 10.9.0.2.8 ou version ultérieure. Le numéro de version de la géodatabase est une combinaison des numéros de version ArcGIS Enterprise et ArcGIS Pro.

Les géodatabases d’entreprise créées à partir de ArcMap ne peuvent pas être inscrites en tant qu’éléments de données.