L’infrastructure et la configuration matérielle minimales requises pour exécuter ArcGIS Enterprise on Kubernetes 11.3 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 :
- Red Hat OpenShift Container Platform (RHOS)
- Amazon Elastic Kubernetes Service (EKS)
- Google Kubernetes Engine (GKE)
- Microsoft Azure Kubernetes Service (AKS)
- Rancher Kubernetes Engine (RKE et RKE2)
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 :
Pour garantir une compatibilité et un support complets, confirmez que votre version Kubernetes se trouve dans la plage prise en charge avant de mettre à niveau ArcGIS Enterprise on Kubernetes.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 sur le Cloud (AKS, EKS, GKE) Red Hat OpenShift Container Platform(notamment ROSA et ARO) [4.14] RKE et RKE2 | 1.27 - 1.29 |
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’organisation Hub Docker 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. Des nœuds worker supplémentaires sont requis pour prendre en charge l’évolution des charges de travail et l’activation des fonctionnalités dans votre organisation.
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.
| Profil d’architecture | Nombre minimal de nœuds worker/agent | Nombre minimal total de processeurs | Quantité 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 (FQDN) et un équilibrage de la charge ou un proxy inverse qui distribue le trafic depuis les clients via le port HTTPS standard (443) vers les cibles back-end configurées. 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 service DNS (système de noms de domaine) existant pour créer un enregistrement CNAME ou A, ou encore intégrer le service DNS d’un fournisseur Cloud tel qu’Amazon Route 53. Vous pouvez créer l’enregistrement DNS après le déploiement, mais vous devez fournir le nom de domaine complet 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 peut être utilisé pour distribuer le trafic vers votre déploiement ArcGIS Enterprise on Kubernetes. Vous pouvez approvisionner les équilibreurs de charge des couches 4 et 7 à partir du script de déploiement sans configuration manuelle. Les équilibreurs de charge qui sont intégrés dans votre déploiement à partir du script de déploiement dirigent le trafic directement vers le pod de contrôleur Ingress NGINX dans le cluster.
Alternativement, vous pouvez utiliser ArcGIS Enterprise on Kubernetes Web Adaptor pour diriger le trafic vers votre déploiement, ce qui demande que le trafic entrant soit envoyé vers les nœuds worker du déploiement sur un port spécifique.
Les équilibreurs de charge suivants de la couche 4 peuvent être approvisionnés à partir du script de déploiement sans 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.
Les équilibreurs de charge spécifiés ci-dessus peuvent être personnalisés à l’aide d’annotations sur l’objet de service Kubernetes sous-jacent. Par exemple, vous pouvez activer l’équilibrage de charge inter-zones sur un équilibreur de la charge réseau dans AWS ou placer un équilibreur de charge Azure Blob dans un groupe de ressources spécifique. Le fichier de modèle deploy.properties inclut dans le script de déploiement contient des exemples illustrant comment ces annotations peuvent être spécifiées pendant le déploiement silencieux.
Le script de déploiement peut être utilisé pour utiliser les fonctionnalités d’équilibrage de charge de la couche 7, telles qu’un pare-feu d’applications Web ou pour répondre à d’autres exigences de l’organisation concernant les Ingress sur l’application déployée à l’aide d’un contrôleur Ingress préexistant. Les équilibreurs de charge suivants de la couche 7 peuvent être déployés ou intégrés directement à partir du script de déploiement :
- Équilibreur de charge applicatif AWS
Remarque :
Le complément AWS Load Balancer Controller est nécessaire pour créer les équilibreurs de charge applicatifs dans un sous-réseau public ou privé.
- Azure Application Gateway
- Équilibreur de charge applicatif Google Cloud Platform
Un contrôleur Ingress implementé au niveau du cluster utilisera ces équilibreurs de charge pour implémenter les règles Ingress au niveau du cluster afin de diriger le trafic entrant vers un déploiement ArcGIS Enterprise on Kubernetes. Pour implémenter ces équilibreurs de charge à partir du script de déploiement avant d’effectuer le déploiement silencieux, vous pouvez modifier un fichier YAML de modèle dans le dossier layer-7-templates, l’enregistrer sur le poste de travail client et spécifier cet emplacement pour le paramètre CLUSTER_INGRESS_CONTROLLER_YAML_FILENAME. Reportez-vous à la rubrique Contrôleurs Ingress au niveau du cluster pour de plus amples informations.
Lors de l’utilisation d’un équilibreur de charge autogéré ou d’un proxy inverse tel que NGINX, l’en-tête X-Forwarded-Host doit être défini sur la valeur d’en-tête de l’hôte de l’URL côté client pour s’assurer que le trafic est correctement dirigé vers l’URL de votre organisation ArcGIS Enterprise. Dans NGINX, utilisez la directive suivante : proxy_set_header X-Forwarded-Host $host;.
Remarque :
ArcGIS Enterprise ne prend pas en charge le déchargement SSL via un proxy inverse/équilibreur de charge. Si votre configuration utilise un proxy inverse, celui-ci doit rediriger le trafic vers ArcGIS Web Adaptor ou directement vers l’organisation via HTTPS.
Exigences relatives aux adresses IP
Il est essentiel de planifier à l’avance votre réseau de clusters pour garantir la réussite du déploiement, répondre aux exigences applicables en matière de mise à l’échelle et assurer le bon déroulement des mises à niveau. À l’origine, ArcGIS Enterprise on Kubernetes déploie 47 à 66 pods selon le profil d’architecture choisi. Le nombre de pods augmente lorsque des fonctionnalités supplémentaires sont ajoutées, lors de la mise à l’échelle du déploiement et au cours du processus de mise à niveau.
Chaque pod se voit attribuer une adresse IP unique et, selon la configuration du réseau de clusters, les pods peuvent recevoir leur adresse IP soit d’un espace d’adressage logiquement différent de celui du réseau hôte (un réseau superposé), soit d’un sous-réseau hôte. Par exemple, si vous configurez votre cluster pour utiliser kubenet dans Azure (par défaut), les pods reçoivent leur adresse IP d’un espace d’adressage logiquement différent et peuvent atteindre les ressources Azure via la traduction d’adresses réseau (NAT pour Network Address Translation).
Kubernetes prend en charge l’interface réseau de conteneur (CNI pour Container Network Interface) et les plateformes telles qu’AKS et EKS, qui utilisent des plug-ins CNI spécifiques à la plateforme pour la mise en réseau des clusters. Par exemple, les clusters EKS utilisent par défaut le plug-in CNI du Cloud privé virtuel (VPC pour Virtual Private Cloud). Si le cluster est configuré avec un plug-in CNI, les pods reçoivent leur adresse IP du sous-réseau hôte et d’un pool correspondant d’adresses IP disponibles sur le VPC/VNet.
Si vous ne disposez pas d’un nombre suffisant d’adresses IP disponibles dans les sous-réseaux hôtes, soit le déploiement échoue, soit il vous sera impossible de mettre à l’échelle le déploiement. Par exemple, si un cluster EKS est configuré avec deux sous-réseaux et un préfixe d’adresse IPv4 de /26 (64 adresses IPv4 disponibles pour chacun des sous-réseaux), 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 serez pas en mesure de mettre à l’échelle le déploiement pour disposer de 80 pods de service d’entités car l’exigence en matière de mise à l’échelle entraînerait le dépassement du nombre d’adresses IP disponibles.
Stockage système
Pour le stockage système, ArcGIS Enterprise on Kubernetes requiert 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 de travail 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 par blocs offrant une faible latence, tels que les volumes EBS avec EKS, les volumes Azure Disks avec AKS, les disques persistants avec GKE et les volumes vSphereVolume ou Longhorn dans le cadre d’un déploiement sur des clusters autogérés.
Comme ces volumes persistants stockent les données et les paramètres de votre organisation, vous devez les protéger en appliquant des stratégies de sécurité restrictives. Pour les volumes persistants basés sur un stockage de fichiers réseau, tels que NFS, Azure Files et GlusterFS, veillez à ce que les autorisations soient définies de façon à empêcher tout accès non autorisé. Pour les stockages par blocs, tels que les volumes EBS, Azure Disk, vSphereVolume et Longhorn, assurez-vous que l’accès aux volumes de stockage est strictement limité aux utilisateurs qui en ont besoin.
Voici une description des volumes de stockage et de leur objectif :
Remarque :
Les exigences relatives aux volumes persistants sont indiquées pour la version 11.3 et peuvent différer des exigences applicables aux versions précédentes.
- In-memory (En mémoire) : stocke les ressources système temporaires.
- Item packages (Paquetages d’éléments) : stocke les téléchargements et paquetages volumineux pour permettre la prise en charge des processus de publication.
- Object (Objet) : stocke les contenus chargés et enregistrés, les caches des couches de scène, d’images et de tuiles hébergées, ainsi que les sorties de géotraitement.
- Queue (File d’attente) : stocke les tâches de géotraitement asynchrones.
- Relational (Relationnel) : stocke les données d’entités hébergées et les éléments d’administration tels que les paramètres de personnalisation et de configuration. Deux volumes sont nécessaires pour le déploiement.
- Spatiotemporal and index (Spatiotemporel et index) : stocke les journaux et les index, ainsi que les données d’entités hébergées.
Remarque :
Les couches d’entités hébergées spatiotemporelles ne sont pas prises en charge dans cette version.
- Usage metric data (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 distant. L’utilisateur qui exécute les scripts doit disposer d’un accès en lecture et en écriture afin que les scripts puissent écrire 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 devez disposer des éléments suivants lors de la configuration de votre poste de travail client (les liens de téléchargement sont fournis) :
- Kubectl
- Une interface de ligne de commande (CLI pour Command Line Interface) spécifique à l’environnement utilisé
Kubectl est une condition requise pour l’exécution du script de déploiement. Reportez-vous aux instructions figurant sur la page Installer et configurer kubectl pour télécharger l’outil en ligne de commande Kubernetes.
Remarque :
La version du client kubectl ne doit pas différer de plus d’une version mineure de la version du serveur de l’API Kubernetes. Par exemple, kubectl 1.28 est compatible avec les versions 1.27 à 1.29 des clusters Kubernetes.
Lors de la gestion de votre déploiement, vous pouvez utiliser des outils en ligne de commande spécifiques à votre environnement. Utilisez les liens suivants pour télécharger une interface de ligne de commande spécifique à l’environnement utilisé :
Certificat TLS
ArcGIS Enterprise on Kubernetes utilise un contrôleur Ingress basé sur NGINX. La portée de ce contrôleur Ingress est limitée à l’espace de noms et le contrôleur est déployé de sorte à écouter exclusivement le trafic entrant pour l’espace de noms ArcGIS Enterprise. Un certificat TLS (Transport Layer Security) avec le nom de domaine complet (FQDN) dans le nom courant (CN pour Common Name) et l’autre nom d’objet (SAN pour Subject Alternative Name) du certificat est requis. Vous pouvez utiliser un certificat signé par une autorité de certification ou un certificat autosigné. 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 de certificat suivantes sont disponibles dans le script de déploiement afin d’appliquer un certificat TLS pour le trafic entrant :
- Un secret TLS existant contenant une clé privée et un certificat
- Un fichier .pfx contenant une clé privée et un certificat
- Une clé privée au format PEM et un certificat
- Un certificat autosigné
ArcGIS Enterprise on Kubernetes prend en charge l’utilisation d’un certificat TLS pour le contrôleur Ingress. Ce certificat est émis et géré par le gestionnaire de certificats Kubernetes (cert-manager). Ce certificat doit être stocké dans un secret TLS se trouvant dans le même espace de noms qu’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
- La version ArcGIS Pro 3.3 est celle qui accompagne la version ArcGIS Enterprise on Kubernetes 11.3. Pour bénéficier des fonctionnalités les plus récentes, utilisez ArcGIS Pro 3.3.
- Pour publier des services sur ArcGIS Enterprise on Kubernetes, ArcGIS Pro 2.8 ou version ultérieure est requis.
- Pour utiliser des services depuis ArcGIS Enterprise on Kubernetes, ArcGIS Pro 2.7 ou version ultérieure est requis.
Lorsque vous inscrivez un élément de data store à partir d’une géodatabase d’entreprise, la géodatabase doit se trouver à la version 10.9.0.2.8 ou à une 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.3.0Pour plus d’informations, reportez-vous à la page Compatibilité client/géodatabase.
Vous avez un commentaire à formuler concernant cette rubrique ?