Configuration système requise

L’infrastructure et la configuration matérielle minimales requises pour exécuter ArcGIS Enterprise on Kubernetes 11.2 sont décrites ci-dessous. Ces exigences s’appliquent également au déploiement dans un environnement déconnecté.

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, les environnements suivants sont pris en charge :

Il est recommandé de désactiver la mise à niveau automatique sur votre cluster Kubernetes. Lorsque la mise à niveau automatique est activée sur votre cluster, les nœuds sont automatiquement mis à jour avec la dernière version de Kubernetes. Or, il se peut que ces versions futures ne soient pas encore prises en charge pour ArcGIS Enterprise.

Attention :
Lors de la mise à niveau de votre environnement, vous devez mettre à niveau ArcGIS Enterprise on Kubernetes avant de procéder à la mise à niveau de Kubernetes vers une version prise en charge.

Les versions suivantes de chaque environnement ont été testées et sont prises en charge :

Environnement pris en chargeVersion de Kubernetes prise en charge

Services Kubernetes gérés sur le Cloud (AKS, EKS, GKE)

Red Hat OpenShift Container Platform

(notamment ROSA et ARO) [4.12 – 4.14]

RKE et RKE2

1.25 – 1.28

Remarque :

ArcGIS Enterprise on Kubernetes est pris en charge uniquement sur des processeurs basés sur l’architecture x86_64 (64 bits). Les nœuds worker doivent être basés sur Linux.

Registre de conteneurs

Les images de conteneur d’ArcGIS Enterprise on Kubernetes sont accessibles depuis une organisationDocker Hub privée. Esri accorde l’accès aux référentiels de cette organisation aux personnes qui déploient ArcGIS Enterprise on Kubernetes. Lors du déploiement dans un environnement déconnecté, vous devez transférer les images de l’organisationDocker Hub privée vers votre propre registre de conteneurs privé accessible depuis votre cluster.

Obtenir une licence Esri

Pour autoriser votre organisation ArcGIS Enterprise lors du déploiement, vous devez disposer d’un fichier de licence ArcGIS Enterprise on Kubernetes au format JSON (fichier .json). Pour obtenir ce fichier de licence, rendez-vous sur My Esri et assurez-vous de disposer des privilèges requis pour agir sur les licences.

Nœuds worker

ArcGIS Enterprise on Kubernetes est déployé avec l’un des trois profils d’architecture disponibles. Les recommandations concernant les limites et demandes de ressources (processeur et mémoire), ainsi que les exigences globales relatives aux capacités de calcul, varient selon le profil sélectionné. Voici les recommandations pour chaque profil.

Vous trouverez ci-dessous les exigences minimales requises applicables aux nœuds pour chaque profil d’architecture. Il est recommandé que chaque nœud worker/agent dispose d’au moins 8 processeurs et 32 Gio de mémoire. Pour permettre le téléchargement des images de conteneur associées à ArcGIS Enterprise on Kubernetes, il est également recommandé de disposer d’une taille de disque racine d’au moins 100 Gio.

Si vous attribuez des licences pour des fonctionnalités Premium dans votre organisation, vous devez ajouter un nœud worker supplémentaire pour la prise en charge des fonctionnalités ajoutées quel que soit le profil d’architecture utilisé.

Profil d’architectureNombre minimal de nœuds worker/agentNombre minimal total de processeursQuantité minimale totale de mémoire (Gio)

Enhanced availability (Disponibilité optimisée)

5

40

160

Standard availability (Disponibilité standard)

4

32

128

Development (Développement)

3

24

96

Les pods dans le déploiement ArcGIS Enterprise on Kubernetes sont distribués sur les nœuds worker dans le cluster. Les horloges des nœuds worker doivent être synchronisées avec une source commune afin que les dates/heures soient cohérentes dans le cluster. Lors de la mise à l’échelle du déploiement ou de l’ajout d’un autre déploiement ArcGIS Enterprise au cluster, vous devez provisionner le matériel en conséquence. Une augmentation du nombre maximal par défaut de pods par nœud peut s’avérer nécessaire. Le nombre de pods créés à l’origine est différent selon le profil d’architecture sélectionné. Le nombre de pods augmente en cas de mise à l’échelle horizontale ou d’ajout de fonctionnalités.

Sécurité

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

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

Le contrôle d’accès basé sur les rôles (RBAC pour Role-Based Access Control) doit être activé sur le cluster Kubernetes. Pour déployer ArcGIS Enterprise on Kubernetes, il n’est pas nécessaire que vous disposiez des privilèges d’administrateur de cluster (cluster-admin). Lorsque l’utilisateur qui effectue le déploiement ne dispose pas des privilèges d’administrateur de cluster, il doit détenir les privilèges minimaux d’administration des espaces de noms. Vous pouvez attribuer à l’utilisateur un rôle de cluster (ClusterRole) par défaut en créant une liaison de rôle (RoleBinding) dans l’espace de noms. Pour plus d’informations, reportez-vous à la ressource sur les rôles RBAC.

Inscrire un dossier de données

Pour publier des éléments à l’aide de données basées sur un fichier (par exemple, des éléments publiés à partir d’une géodatabase fichier), vous devez placer les données dans un emplacement partagé NFS. Ce partage NFS doit être inscrit auprès de l’organisation ArcGIS Enterprise pour éviter la copie des données sur le serveur lors de la publication. Pour inscrire le dossier partagé, vous devez accorder des autorisations d’accès en lecture au niveau des fichiers aux autres utilisateurs. Vous pouvez sécuriser le partage NFS au niveau du réseau ou de l’infrastructure en autorisant l’accès réseau à la plage d’adresses IP des pods.

Réseau

Parmi les exigences relatives au réseau figurent un nom de domaine complet et un équilibreur de charge. Des informations détaillées sur ces deux exigences 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 noms 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, le nom de domaine complet ne peut pas être modifié après le déploiement.

Équilibreur de charge

Un équilibreur de charge est nécessaire pour distribuer le trafic entre les nœuds workers. Vous pouvez provisionner les équilibreurs de charge suivants à partir du script de déploiement, ceci sans aucune configuration manuelle :

  • Azure Load Balancer (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.
  • AWS Network Load Balancer (accessible sur 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.
    Remarque :

    Le complément AWS Load Balancer Controller est nécessaire pour créer les équilibreurs de charge Network Load Balancer dans un sous-réseau public ou privé.

  • Équilibreur de charge TCP de la plateforme Google Cloud (accessible sur Internet ou interne) : une adresse IP publique statique préprovisionnée peut être spécifiée dans le script de déploiement.

Pour implémenter les fonctionnalités d’équilibrage de la charge de la couche 7, telles que WAF (Web Application Firewall) ou pour répondre aux exigences d’autres organisations concernant l’objet Ingress sur l’application déployée à l’aide d’un contrôleur Ingress préexistant, suivez la procédure de déploiement sur l’intégration avec un contrôleur Ingress au niveau du cluster.

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.

Remarque :

ArcGIS Enterprise ne prend pas en charge le déchargement SSL via un proxy inverse/équilibrage de charge. Si votre configuration utilise un proxy inverse, il doit rediriger vers ArcGIS Web Adaptor ou directement vers l’organisation via HTTPS.

Exigences relatives aux adresses IP

Il est essentiel de planifier à l’avance votre cluster pour réussir le déploiement, bénéficier d’exigences appropriées en matière d’évolution ainsi que de capacités de mise à niveau. À l’origine, ArcGIS Enterprise on Kubernetes créé 47 à 66 pods selon le profil d’architecture. Le nombre de pods augmente au fur et à mesure que des capacités additionnelles sont ajoutées, le déploiement montant en charge durant le processus de mise à niveau.

Chaque pod reçoit une adresse IP unique et, selon la configuration de réseau du cluster, les pods peuvent obtenir leur adresse IP soit d’un espace d’adresse logiquement différent de celui du réseau hôte (un réseau de superposition), soit d’un sous-réseau hôte. Si, par exemple, vous configurez votre cluster pour utiliser kubenet dans Azure (par défaut), les pods reçoivent une adresse IP d'un espace d’adresses logiquement différent et sont en mesure d’atteindre les ressources Azure à l’aide de NAT.

Kubernetes prend en charge l’interface de réseau de conteneur (CNI) et les plateformes comme AKS et EKS qui utilisent des plug-ins CNI propres à la plateforme pour la mise en réseau du cluster. Par exemple, les clusters EKS utilisent la CNI du Virtual Private Cloud (VPC) par défaut. Si le cluster est configuré avec un plug-in CNI, les pods reçoivent des adresses IP du sous-réseau hôte et un pool correspondant d’adresses IP disponibles sur le VPC/VNet.

Si vous n’avez pas un nombre suffisant d’adresses IP disponibles dans les sous-réseaux hôte, le déploiement échoue ou bien vous n’êtes pas en mesure de faire évoluer le déploiement. Si, par exemple, un cluster EKS est configuré avec deux sous-réseaux et un préfixe d’adresse IPv4 /26 (64 adresses IPv4 disponibles chacun), il ne peut pas y avoir plus de 126 adresses IP disponibles pour les pods. Bien qu’il soit possible de déployer ArcGIS Enterprise on Kubernetes dans ce cluster, vous ne pourrez pas faire évoluer le déploiement pour disposer de 80 pods de services d’entités, car cette spécification de montée en charge dépasserait le nombre d’adresses IP disponibles.

Stockage système

ArcGIS Enterprise on Kubernetes requiert pour le stockage système des volumes persistants, qui peuvent être provisionnés de manière dynamique via une classe de stockage ou de manière statique par un administrateur avant la création de l’organisation. En savoir plus sur le provisionnement statique et le provisionnement dynamique.

Les charges applicatives avec état d’ArcGIS Enterprise incluent des systèmes de gestion de bases de données relationnelles et des bases de données NoSQL. Il est recommandé de provisionner les volumes persistants sur des périphériques de stockage de blocs qui offrent une faible latence, tels que les volumes EBS avec EKS, les disques Azure avec AKS, les disques persistants avec GKE et les volumes vSphereVolume ou Longhorn dans le cadre d’un déploiement sur des clusters auto-gérés.

Parce que ces volumes persistants stockent les données et les paramètres de votre organisation, vous devez les protéger à l’aide de mesures de sécurité restrictives. Pour les volumes persistants basés sur le stockage de fichiers, tels que NFS, Azure File et GlusterFS, vérifiez que les autorisations sont définies de façon à empêcher tout accès non autorisé. Pour le stockage de blocs, tel que les volumes EBS, Azure Disk, vSphereVolume et Longhorn, assurez-vous que l’accès aux volumes de stockage est limité aux utilisateurs en ayant besoin.

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 11.2 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 de scènes, d’images et de tuiles hébergées et les sorties de géotraitement qui ont été chargés et enregistrés.
  • 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.
  • Spatiotemporel et index : stocke les journaux et les index, ainsi que les données d’entité hébergées.
    Remarque :

    Les couches d’entités hébergées spatiotemporelles ne sont pas prises en charge dans cette version.

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

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. L’utilisateur exécutant les scripts doivent disposer d’un accès en lecture et en écriture afin que les scripts écrivent des fichiers de ressources temporaires dans les sous-répertoires.

Remarque :

En raison de problèmes de compatibilité connus, les émulateurs Linux ne sont pas pris en charge pour déployer ArcGIS Enterprise on Kubernetes.

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.

Remarque :

La version du client kubectl doit être une version mineure de la version du serveur Kubernetes. Par exemple, kubectl 1.24 est compatible avec les versions 1.23 à 1.25 des clusters 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 :

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 Pro

  • ArcGIS Pro 3.2 est la version qui accompagne ArcGIS Enterprise on Kubernetes 11.2. Pour bénéficier des fonctionnalités les plus récentes, utilisez ArcGIS Pro 3.2.
  • Pour publier les services sur ArcGIS Enterprise on Kubernetes, ArcGIS Pro 2.8 ou version ultérieure est nécessaire.
  • Pour utiliser des services depuis ArcGIS Enterprise on Kubernetes, ArcGIS Pro 2.7 ou version ultérieure est nécessaire.

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.

Remarque :
Pour bénéficier des fonctionnalités les plus récentes, mettez à niveau votre géodatabase vers la version 11.2.0.3.2.

Le numéro de version de la géodatabase est une combinaison des numéros de version ArcGIS Enterprise et ArcGIS Pro. Pour plus d’informations, reportez-vous à la compatibilité client/géodatabase.