Configuration du système

L’infrastructure et la configuration matérielle minimum requises pour exécuter ArcGIS Enterprise on Kubernetes dans la version 10.9 sont décrits 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 ou version ultérieure
• Services Kubernetes gérés sur le Cloud
  • Microsoft Azure Kubernetes Service (AKS)
  • Amazon Elastic Kubernetes Service (EKS)

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. Contactez votre représentant Esri pour en savoir plus.

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 ».

• Connectez-vous à My Esri.
• Sélectionnez My Organizations (Mes organisations) > Licensing (Licences).
• Sous License Esri Products (Licences pour les produits Esri), cliquez sur Start (Démarrer).
• Pour Product (Produit), sélectionnez ArcGIS Enterprise ; pour Version, sélectionnez la version de ArcGIS Enterprise souhaité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 vos rôles de serveur, types d’utilisateurs et applications, le cas échéant.

Cluster Kubernetes

Pour déployer ArcGIS Enterprise on Kubernetes, vous devez détenir un agrégat Kubernetes sur l’une des plateformes mentionnées ci-dessus. Pour chaque environnement pris en charge, la version de votre agrégat Kubernetes doit être 1.19 ou ultérieure.

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é.

Calculer

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.

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.

Il est recommandé de réserver au moins 10 % 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 ci-dessous 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é actuels.

Profil de disponibilité standard :

spec: 
    hard: 
      limits.cpu: "120" 
      limits.memory: 196Gi 
      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: "86" 
      limits.memory: 154Gi 
      requests.cpu: "14" 
      requests.memory: 58Gi

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 rcgis-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
    

Après avoir préparé les nœuds, vous devez indiquer au script de déploiement de ne pas exécuter les conteneurs privilégiés, comme suit :

• Accédez au fichier /setup/.install/arcgis-enterprise/arcgis-enterprise.properties.
• Mettez à jour la chaîne "ALLOWED_PRIVILEGED_CONTAINERS=${ALLOWED_PRIVILEGED_CONTAINERS:-true}" sur "ALLOWED_PRIVILEGED_CONTAINERS=${ALLOWED_PRIVILEGED_CONTAINERS:-false}".
• Enregistrez le fichier.

Le script de déploiement n’exécute pas le conteneur init en tant que conteneur privilégié.

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 dans l’espace de noms par défaut utilisent le nom d’hôte kubernetes.default.svc pour interroger le serveur d’API.

Réseau

Parmi les exigences réseau figurent un nom de domaine complet et un équilibrage de la charge. Voici les détails de chaque critère.

Nom de domaine complet

ArcGIS Enterprise on Kubernetes requiert un nom de domaine complet (FQDN) (map.entreprise.com, par exemple). Vous pouvez utiliser votre 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 et classique (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.

Remarque :

Le plug-in CNI Azure dans AKS n’est pas pris en charge dans cette version.

Stockage

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, vSphereVolume, etc.

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 :

• 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 : stockage des fichiers journaux, 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.
• Visionneuse des mesures d’utilisation : stocke les tableaux de bord par défaut et personnalisés qui affichent des statistiques d’utilisation des services SIG.
• Données des mesures d’utilisation : stocke les données d’utilisation des services SIG.

Étudiez les exigences en matière de stockage selon les besoins 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 suivantes 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
usage-metric-viewer-volume	1	1	1

Lorsque vous configurez une organisation avec l’assistant de configuration, les spécifications suivantes (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	Étiquette (par défaut)
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
usage-metric-viewer-volume	1	ReadWriteOnce	arcgis/tier=storage, arcgis/app=grafana

Volumes persistants dynamiques

Pour le provisionnement dynamique, une classe StorageClass est requise. Lorsque vous configurez l’organisation avec l’assistant de configuration, le nom par défaut de StorageClass est arcgis-storage-default.

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 (azure disk) ou managed-premium. Dans EKS, il s’agit d’une classe de stockage GP2.

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 avec la commande shell bash.

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 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é, mais pour des raisons de sécurité, il est fortement 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 d’ArcMap ne peuvent pas être inscrites en tant qu’éléments de données.