L’infrastructure et la configuration matérielle minimum requises pour exécuter ArcGIS Enterprise on Kubernetes 11.0 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)
À compter de cette version, les versions suivantes de chaque environnement ont été testées et sont prises en charge :
| ArcGIS Enterprise on Kubernetes | AKS | EKS | GKE | Red Hat OpenShift |
|---|---|---|---|---|
Déployer 11.0 dans un cluster Kubernetes existant | 1.21 à 1.24 | 1.21 à 1.24 | 1.21 à 1.24 | 4.7 - 4.10 |
Mettre à niveau un cluster Kubernetes existant après le déploiement de la version 11.0 | Non pris en charge | Non pris en charge | Non pris en charge | N/D |
Remarque :
Pour activer la mise à l’échelle automatique dans les services SIG, vous avez besoin de Metrics Server afin de collecter les métriques de nœuds. Lors du déploiement dans des environnements EKS, vous devez installer Metrics Server en disposant de privilèges au niveau du cluster dans l’espace de noms kube-system. Metrics Server est installé par défaut dans d’autres environnements pris en charge.
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. Lors du déploiement dans un environnement déconnecté, vous devez utiliser le registre de conteneur de votre organisation.
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 ».
Cluster Kubernetes
Pour déployer ArcGIS Enterprise on Kubernetes, vous devez avoir un cluster Kubernetes sur l’un des environnements mentionnés ci-dessus.
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.
Remarque :
Dans EKS, lors de la création ou de la mise à niveau d’un cluster avec Kubernetes 1.23 et versions ultérieures, vous devez installer le complément Amazon EBS Container Storage Interface (CSI). Pour plus de détails, consultez la documentation Amazon EKS.
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) | 4 | 32 | 128 |
Enhanced availability (Disponibilité améliorée) | 5 | 40 | 160 |
Développement | 3 | 24 | 96 |
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 11.0, vous devez d’abord mettre à jour les valeurs de quota des ressources dans l’espace de noms selon la configuration requise de la version 11.0.
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: "164"
limits.memory: 272Gi
requests.cpu: "24"
requests.memory: 108Gi
Profil de disponibilité avancé :
spec:
hard:
limits.cpu: "192"
limits.memory: 328Gi
requests.cpu: "30"
requests.memory: 156Gi
Profil de développement :
spec:
hard:
limits.cpu: "120"
limits.memory: 188Gi
requests.cpu: "16"
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 sur le nombre de cartes 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 le cluster Kubernetes inclut une stratégie de sécurité des pods et autorise l’exécution des conteneurs en tant que conteneurs privilégiés ou non, les actions suivantes s’imposent :
- Si le cluster Kubernetes n’inclut aucune stratégie de sécurité des pods, mais autorise l’exécution des conteneurs en tant que conteneurs privilégiés, aucune action n’est requise.
- Exécuter en mode privilégié : si la sécurité des pods du cluster Kubernetes est définie et autorise l’exécution des conteneurs en mode privilégié, vous devez autoriser le compte de service Elasticsearch à exécuter les conteneurs en tant que conteneurs privilégiés. Les autres services de compte n’ont pas besoin d’être exécutés en mode privilégié. ArcGIS Enterprise on Kubernetes peut exécuter un conteneur init privilégié sur le nœud exécutant Elasticsearch, ce qui change la valeur vm.max_map_count. Le script de déploiement ArcGIS Enterprise on Kubernetes crée un compte de service sous son espace de noms pour utiliser l’authentification de serveur d’API pour les processus dans les pods. Le pod Elasticsearch utilise son propre compte de service qui n’est pas partagé avec les autres charges de travail. Le compte de service Elasticsearch par défaut est arcgis-elastic-serviceaccount. Vous pouvez accorder l’accès du compte de service à la stratégie de sécurité des pods avec les rôles RBAC et RoleBindings. 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-elastic-serviceaccount" - Exécuter en mode non privilégié : si la sécurité des pods du cluster Kubernetes est définie et n’autorise pas le compte de service ElasticSearch à exécuter les conteneurs en mode 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 avez créé la ressource PodSecurityPolicy, vous devez autoriser les comptes de service suivants dans l’espace de noms ArcGIS Enterprise.
- arcgis-admin-serviceaccount
- arcgis-elastic-serviceaccount
- arcgis-ingress-serviceaccount
- arcgis-prometheus-serviceaccount
- arcgis-queue-serviceaccount
- default
Les conteneurs ArcGIS Enterprise on Kubernetes peuvent être exécutés sans privilèges racine. Toutefois, le contrôle de fsGroup et supplementalGroups de PodSecurityPolicy doit correspondre à RunAsAny ou à une plage qui inclut la valeur 117932853 comme indiqué dans les exemples suivants.
supplementalGroups: rule: 'RunAsAny' fsGroup: rule: 'RunAsAny'supplementalGroups: rule: 'MustRunAs' ranges: # Forbid adding the root group. - min: 1 max: 117932853 fsGroup: rule: 'MustRunAs' ranges: # Forbid adding the root group. - min: 1 max: 117932853
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.
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. 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.
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é.
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.
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 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 11.0 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.
- 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 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 | 3 | 8 |
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 | 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.
Ajuster les volumes persistants statiques 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 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.
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. 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.
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.0 est la version qui accompagne ArcGIS Enterprise on Kubernetes 11.0. Pour bénéficier des fonctionnalités les plus récentes, utilisez ArcGIS Pro 3.0.
- 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.0.0.3.0.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 :
- 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.
- 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.
- Si vous procédez à la mise à niveau depuis la version 10.9.1, vous devez provisionner au moins cinquante pour cent (50 %) du stockage supplémentaire pour accueillir les nouveaux volumes persistants d’object store pour chaque profil d’architecture. Si, par exemple, vous avez alloué 100 Go de stockage pour les volumes persistants d’object store par pod d’object store, vous devez provisionner au moins 150 Go de stockage supplémentaire.
- 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 toute mise à niveau, chaque pod dans le déploiement Queue Store et de l’API du portail de l’organisation a été configuré avec un volume persistant de paquetage d’élément ou de queue-volume, respectivement. En préparation d’une mise à niveau, chaque pod inclus dans le déploiement de l’API du portail et Queue Store doit être configuré avec un volume persistant supplémentaire.
Par exemple, avant une mise à niveau, le déploiement de l’API du portail ou de Queue Store 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 ou de Queue Store utilisera les volumes persistants qui viennent d’être provisionnés et la réclamation de volume persistant ; le jeu d’origine peut être supprimé.
Des volumes persistants statiques supplémentaires doivent être provisionnés pour les déploiements Object Store lors de la mise à niveau selon la table suivante :
| Type de déploiement | Volumes persistants object-volume statiques | Volumes persistants statiques supplémentaires requis pour la mise à niveau |
|---|---|---|
Profil Development (Développement) | 1 | Créer 1 volume persistant supplémentaire |
Profil Standard availability (Disponibilité standard) | 3 | Créer 3 volumes persistants supplémentaires |
Profil Enhanced availability (Disponibilité améliorée) | 8 | Créer 8 volumes persistants supplémentaires |
Vous avez un commentaire à formuler concernant cette rubrique ?