L’infrastructure et la configuration matérielle minimum requises pour exécuter ArcGIS Enterprise on Kubernetes 11.1 sont décrits ci-dessous. Ces conditions 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 préliminaire, les environnements suivants sont pris en charge :
- Centre de données sur site
- Red Hat OpenShift Container Platform
- Services Kubernetes gérés dans le Cloud
- Amazon Elastic Kubernetes Service (EKS)
- Google Kubernetes Engine (GKE)
- Microsoft Azure Kubernetes Service (AKS)
Il vous est fortement recommandé de désactiver la mise à niveau automatique dans votre agrégat Kubernetes. Lorsque votre agrégat est activé avec la mise à niveau automatique, les nœuds sont automatiquement mis à jour avec la dernière version de Kubernetes et ces versions futures ne sont peut-être 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 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 charge | Version de Kubernetes prise en charge |
|---|---|
Services Kubernetes gérés dans le Cloud (AKS, EKS, GKE) | 1.23 - 1.25 |
| Red Hat OpenShift Container Platform | 4.10 - 4.12 |
Remarque :
ArcGIS Enterprise on Kubernetes n’est pris en charge que sur des processeurs conformes à l’architecture x86_64 (64 bits). Les nœuds Worker doivent être de type Linux.
Registre de conteneur
Les images de conteneur d’ArcGIS Enterprise on Kubernetes sont accessibles depuis une organisation Hub Docker privée. Esri permet aux personnes qui déploient ArcGIS Enterprise on Kubernetes d’accéder aux référentiels de cette organisation. Lors du déploiement dans un environnement déconnecté, vous devez extraire les images de l’organisation Hub Docker privée vers le registre de conteneur de votre organisation accessible à partir de votre cluster.
Obtenir une licence Esri
Pour autoriser votre organisation ArcGIS Enterprise durant le déploiement, vous devez avoir un fichier de licence ArcGIS Enterprise on Kubernetes au format JSON (fichier .json). Pour obtenir ce fichier de licence, consultez My Esri avec les privilèges « Agir sur les licences ».
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 |
|---|---|---|---|
Enhanced availability (Disponibilité améliorée) | 5 | 40 | 160 |
Standard availability (Disponibilité standard) | 4 | 32 | 128 |
Développement | 3 | 24 | 96 |
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.
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 à l’utilisateur en créant un RoleBinding dans l’espace de noms.
Inscrire un dossier de données
Pour publier des éléments à l’aide de données basées sur un fichier, tels que 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 devrez accorder des autorisations de lecture au niveau des fichiers aux autres utilisateurs. Vous pouvez sécuriser le partage NFS sur le réseau ou l’infrastructure en autorisant l’accès réseau à la plage d’adresses IP des pods.
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. 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.
Remarque :
Le complément AWS Load balancer (Équilibreur de charge AWS) est obligatoire pour créer les équilibreurs de charge du réseau dans le sous-réseau public ou privé.
- Équilibreur de charge TCP Google Cloud Platform (orienté sur Internet ou interne) : une adresse IP publique statique préprovisionnée peut être spécifiée dans le script de déploiement.
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.
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 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-in 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. 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 ou Azure Disk avec AKS, les disques persistants avec GKE et les volumes vSphereVolume ou Longhorn dans le cadre d’un déploiement sur site.
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.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.
- 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.
- 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 Enhanced availability (Disponibilité améliorée) | Profil Standard availability (Disponibilité standard) | Profil Development (Développement) |
|---|---|---|---|
in-memory-volume | 1 | 1 | 1 |
item-packages-volume | 2 | 2 | 1 |
object-volume | 8 | 3 | 1 |
queue-volume | 2 | 2 | 1 |
relational-volume | 2 | 2 | 2 |
spatiotemporal-and-index-volume | 5 | 3 | 1 |
usage-metric-volume | 1 | 1 | 1 |
Si vous configurez votre organisation pour utiliser des volumes persistants statiques existants, les valeurs suivantes de chaque réclamation PVC (Persistent Volume Claim) sont utilisées pour la relier aux volumes persistants via la sélection d’étiquettes : size, access mode et labels. Vous pouvez personnaliser ces valeurs dans l’assistant de configuration ou le fichier de propriétés de configuration pour apparier les volumes persistants pré-provisionnés à chaque spécification d’ensemble avec état.
| 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 | 32 | ReadWriteOnce | arcgis/tier=storage, arcgis/app=ozone |
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 |
Autres éléments à prendre en compte pour les volumes persistants statiques
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ù un stockage suffisant est disponible et que les spécifications de classe de stockage sont satisfaites.
- Volumes persistants statiques : si vous effectuez le provisionnement en vue de votre déploiement, vous devrez 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 processus de mise à l’échelle et de mise à niveau.
Créer des volumes persistants supplémentaires pour mettre à l’échelle le déploiement de 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 requiert trois pods supplémentaires pour le déploiement de l’API du portail, au moins trois volumes persistants de paquetage d’élément supplémentaires doivent être provisionnés et configurés selon des spécifications équivalentes à celles qui ont été indiquées durant le déploiement.
Volumes persistants dynamiques
Pour le provisionnement dynamique, une classe StorageClass est requise.
Le paramètre reclaimPolicy de la classe de stockage peut être défini sur Delete pour simplifier l’administration. Cela aura pour effet de nettoyer le volume persistant associé lorsqu’un PVC est supprimé (par exemple, lorsque vous annulez le déploiement du logiciel).
Une classe de stockage séparée doit être utilisée pour la configuration de backup store hébergé avec son paramètre reclaimPolicy défini sur Retain, de sorte que le volume persistant soit conservé lorsque vous annulez le déploiement et redéployez.
Le paramètre allowVolumeExpansion de la classe de stockage peut être défini sur true si votre fournisseur de stockage prend en charge l’expansion des volumes persistants.
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 :
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: arcgis-storage-default provisioner: disk.csi.azure.com parameters: kind: Managed storageaccounttype: Premium_LRS reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer - Pour ce qui concerne EKS, voici un exemple de définition StorageClass avec des volumes EBS de type GP3 :
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: arcgis-storage-default provisioner: ebs.csi.aws.com parameters: fsType: ext4 type: gp3 reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer - Pour ce qui concerne GKE, voici un exemple de définition StorageClass avec un disque persistant SSD :
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: arcgis-storage-default provisioner: pd.csi.storage.gke.io parameters: type: pd-ssd reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true
Vous pouvez également utiliser les classes de stockage par défaut fournies avec un cluster EKS (GP2), AKS (managed ou managed-premium) ou GKE (persistentdisk), mais vous aurez peut-être besoin d’installer un pilote CSI pour prendre en charge le provisionnement dans Kubernetes 1.23 ou version ultérieure. Avant de créer l’organisation, vous devez vérifier que les propriétés reclaimPolicy et allowVolumeExpansion répondent à vos besoins.
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 de l’agrégat 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.1 est la version qui accompagne ArcGIS Enterprise on Kubernetes 11.1. Pour bénéficier des fonctionnalités les plus récentes, utilisez ArcGIS Pro 3.1.
- 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, effectuez une mise à niveau de votre géodatabase vers la version 11.1.0.3.1.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.
Exigences liées à la mise à niveau et à la mise à jour
Avant de procéder à une mise à niveau, vous devez respecter plusieurs exigences, notamment les suivantes :
- Lors de la mise à niveau de votre environnement, vous devez mettre à niveau ArcGIS Enterprise on Kubernetes avant la mise à niveau de Kubernetes vers une version prise en charge.
- Si une mise à jour requise est disponible, vous devez l’appliquer avant de migrer vers cette version. Consultez les notes de publication pour en savoir plus sur la dernière mise à jour requise.
- Vous devez disposer d’une licence ArcGIS Enterprise on Kubernetes unifiée pour cette version.
- Vous devez mettre à jour les valeurs de quota des ressources dans votre espace de noms selon la configuration requise de la version.
- Avant de procéder à la mise à niveau, vérifiez que votre environnement répond aux normes de sécurité de pod telles que les normes d’admission de sécurité de pod.
- Si votre environnement se trouve dans Red Hat OpenShift Container Platform, vérifiez qu’il répond aux contraintes de contexte de sécurité actuelles.
- Si vous avez provisionné les volumes persistants statiques, vous devez provisionner davantage de stockage pour vous conformer à la configuration de mise à niveau requise. Pour plus d’informations, consultez la section Ajuster les volumes persistants statiques pour la mise à niveau.
- Si vous avez provisionné les volumes persistants dynamiques, vous devez vous assurer que vous disposez d’un stockage suffisant pour accueillir les paquetages d’éléments, le volume d’objet et le volume de file d’attente supplémentaires.
- Exécutez le script de pré-mise à niveau. Ce script détecte et traite les exigences fonctionnelles pour se conformer à la configuration requise par la version logicielle actuelle.
- Si vous avez configuré un Web Adaptor avec votre organisation, consultez les spécifications requises en matière d’installation et de mise à niveau.
- Si votre organisation figure dans un environnement déconnecté, procédez comme suit pour appliquer une mise à niveau ou une mise à jour dans ce type d’environnement.
- Si vous avez utilisé le registre de conteneur de votre organisation lors du déploiement de ArcGIS Enterprise on Kubernetes, vous devez copier les images de conteneur requises à partir du référentiel Esri vers le registre de votre organisation avant de procéder à la mise à jour ou à la mise à niveau.
Ajuster les volumes persistants statiques pour la mise à niveau
Avant une 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.
Par exemple, avant une mise à niveau, si le déploiement de l’API du portail est configuré avec trois pods en cours d’exécution, trois volumes persistants supplémentaires 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é.
Vous avez un commentaire à formuler concernant cette rubrique ?