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.

Remarque :

Si vous mettez à niveau le logiciel pour passer à la version 11.1, 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.1.

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: "198" 
      limits.memory: 326Gi 
      requests.cpu: "32" 
      requests.memory: 130Gi

Profil de développement :

spec: 
    hard: 
      limits.cpu: "144" 
      limits.memory: 226Gi 
      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.

Stratégies de sécurité de pod

Remarque :

PodSecurityPolicy a été supprimé dans Kubernetes version 1.25.

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: 117932853
        max: 117932853
  
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 117932853
        max: 117932853
  

Remarque :

Les pods dans le cluster doivent être autorisés à s’exécuter avec un identifiant FSGroup et un ID SupplementalGroup égal à 117932853.

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.