Préparer l’agrégat

Passez en revue les instructions suivantes sur la préparation de votre agrégat avant de déployer ArcGIS Enterprise on Kubernetes.

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. L’exécution de plusieurs déploiements d’ArcGIS Enterprise on Kubernetes dans un seul agrégat nécessite un espace de noms unique pour chaque déploiement.

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. Si les licences que vous attribuez à votre organisation permettent d’ajouter des fonctions Premium, vous devez augmenter les valeurs de quota des ressources de 10 pour cent supplémentaires afin de prendre en charge les fonctionnalités ajoutées.

Remarque :

Si vous effectuez une mise à niveau vers la version 11.2, 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.2.

Les valeurs recommandées suivantes constituent la configuration minimale requise pour chaque profil d’architecture. Sachez que vous devrez peut-être augmenter ces valeurs pour répondre aux besoins d’évolutivité de votre organisation.

Profil de disponibilité avancé :

spec: 
    hard: 
      limits.cpu: "230" 
      limits.memory: 394Gi 
      requests.cpu: "36" 
      requests.memory: 188Gi

Profil de disponibilité standard :

spec: 
    hard: 
      limits.cpu: "218" 
      limits.memory: 359Gi 
      requests.cpu: "32" 
      requests.memory: 130Gi

Profil de développement :

spec: 
    hard: 
      limits.cpu: "144" 
      limits.memory: 249Gi 
      requests.cpu: "20" 
      requests.memory: 86Gi

Exigences réseau liées aux espaces de noms

Si vous utilisez KubernetesNetworkPolicies, 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 :

cluter.local est le domaine par défaut de l’agrégat.

Normes de sécurité de pod

Les normes de sécurité de pod sont une fonctionnalité Kubernetes qui permet aux administrateurs d’appliquer un ensemble de règles de sécurité pour les pods avant que ceux-ci ne soient planifiés dans l’agrégat. Trois niveaux sont disponibles par défaut : privileged, baseline et restricted. L’avertissement et l’application de ces normes sont contrôlés par espace de noms.

Lorsque le niveau baseline ou restricted est appliqué, les pods ne répondant pas aux exigences de sécurité de ce niveau ne sont pas autorisés à s’exécuter. Pour en savoir plus sur chacun de ces niveaux, reportez-vous aux rubriques suivantes :

• Privileged : la norme Privileged est une norme de sécurité de pod sans restriction qui autorise un accès illimité à un vaste éventail d’autorisations. ArcGIS Enterprise peut s’exécuter sous ce niveau sans aucun changement de configuration. Parce que ce niveau autorise des réaffectations de privilèges connus dans l’agrégat, il n’est pas conseillé de l’appliquer.
• Baseline : la norme Baseline est une norme de sécurité de pod plus limitée qui empêche d’accéder au système de fichiers hôte à partir des pods et comprend des restrictions sur les types des autres volumes et les fonctionnalités. ArcGIS Enterprise peut s’exécuter avec le niveau Baseline en modifiant les nœuds d’opérateur sous-jacents en dehors du contexte de l’application en cours d’exécution et en définissant la propriété ALLOW_PRIVILEGED_CONTAINERS sur false dans le fichier de propriétés de déploiement avant le déploiement.

  Pour refléter l’élasticité des groupes de nœuds d’opérateur, un administrateur doit utiliser un processus scripté pour augmenter le paramètre vm.max_map_count à 262144 sur chaque nœud nouvellement provisionné en modifiant directement le modèle de lancement.

• Restricted : la norme de sécurité de pod Restricted apporte les limites les plus strictes sur la sécurité de pod et nécessite qu’une majorité de propriétés securityContext soient définies de manière explicite. Dans cette version, ArcGIS Enterprise ne peut pas s’exécuter au niveau Restricted.

Pour plus d’informations, reportez-vous aux rubriques Admission de sécurité de pod et Normes de sécurité de pod.

Serveur de métriques

Pour bénéficier de la mise à l’échelle automatique horizontale de pod dans ArcGIS Enterprise on Kubernetes, le serveur de métriques est nécessaire afin de retirer des métriques de consommation de ressources de pod du processus kubelet sur chaque nœud en cours d’exécution. Pour plus d’informations, reportez-vous à la rubrique Serveur de métriques Kubernetes.