Placement des pods

Dans Kubernetes, les pods récemment créés et non planifiés sont automatiquement planifiés sur les nœuds répondant à leurs exigences. En utilisant l’affinité des nœuds, les altérations et les tolérances, vous pouvez mieux contrôler les nœuds sur lesquels les pods sont planifiés.

L’affinité des nœuds vous permet de spécifier les règles qui contraignent les pods à s’exécuter sur certains nœuds étiquetés. Les altérations sont appliquées aux nœuds pour repousser les pods, tandis que les tolérances sont appliquées aux pods pour tolérer les altérations. Pour en savoir plus sur l’affinité des nœuds, les altérations et les tolérances de manière générale, reportez-vous à la documentation Kubernetes. Reportez-vous à la rubrique Gérer le placement des pods pour plus d’informations sur l’application de l’affinité des nœuds et les tolérances aux pods dans ArcGIS Enterprise on Kubernetes.

La combinaison de l’affinité des nœuds, des altérations et des tolérances vous permet d’affiner le placement des charges de travail afin d’améliorer l’isolement, d’optimiser l’allocation des ressources et de respecter efficacement les exigences de conformité au sein de votre clusterKubernetes :

• Isolez les charges de travail avec des exigences spécifiques : utilisez des étiquettes et des règles d’affinité des nœuds pour vous assurer que certains pods sont planifiés sur des nœuds dédiés. Utilisez des altérations pour marquer les nœuds possédant des caractéristiques spécifiques, tels que des exigences élevées en matière d’UC ou de mémoire, en tant que nœuds dédiés aux charges de travail ArcGIS. Appliquez des tolérances sur les pods de service pour vous assurer qu’ils sont planifiés sur des nœuds dotés des ressources nécessaires.
• Optimisez l’allocation des ressources : appliquez des altérations sur les nœuds disposant de ressources limitées pour empêcher la surcharge des ressources, et définissez des tolérances sur les pods de service pour apparier les contraintes de ressources sur ces nœuds : Combinez l’affinité des nœuds avec les altérations et les tolérances pour garantir que les pods de service sont uniquement planifiés sur les nœuds correspondant à leurs exigences en matière de ressources.
• Planification basée sur la géolocalisation : pour les applications qui nécessitent la localité des données ou l’adhésion à des réglementations spécifiques, utilisez l’affinité des nœuds pour planifier des pods de service en fonction de la localisation géographique des nœuds. Altérez les nœuds en fonction de leur emplacement physique ou des réglementations en matière de souveraineté des données, puis appliquez des tolérances sur les pods de service pour vous assurer qu’ils sont planifiés sur des nœuds et respectent les contraintes de localisation requises.

La mise à l’échelle automatique améliore l’utilisation de l’affinité des nœuds et des tolérances en ajustant automatiquement le nombre de pods en fonction des demandes de charge de travail. Cette mise à l’échelle dynamique garantit que les pods sont planifiés efficacement sur les nœuds qui respectent des critères spécifiques ou disposent des ressources nécessaires, en optimisant l’allocation des ressources. En combinant la mise à l’échelle automatique avec l’affinité des nœuds et les tolérances, les clusters Kubernetes peuvent améliorer l’utilisation des ressources, les performances et l’évolutivité, en s’adaptant aux fluctuations de la charge de travail tout en respectant les contraintes et les préférences de nœud. Pour en savoir plus sur la mise à l’échelle automatique, consultez la rubrique Évolution des services.

Scénarios

Pour mieux comprendre la façon dont votre organisation peut tirer parti de la gestion du placement des pods sur les services, consultez les scénarios suivants.

Scénario 1 : Progression du trafic saisonnier pour les services publics de cartographie

Un organisme public connaît une forte hausse du trafic pendant un festival local. Les utilisateurs qui accèdent à la carte Web pour consulter les informations relatives à l’événement subissent des retards en raison de la forte demande sur le service de carte sous-jacent. Pour y remédier, l’administrateur de l’organisation effectue les tâches suivantes :

• Il configure les nœuds disposant de ressources élevées en matière d’UC et de mémoire avec la paire clé-valeur high-performance: true.
• Il applique les règles d’affinité des nœuds pour garantir que les pods de service de carte sont planifiés sur des nœuds dotés de ressources élevées en matière d’UC et de mémoire :
  • Type : Preferred (Préférentielle)
  • Key (Clé) : high-performance
  • Operator (Opérateur) : Exists (Existe)
  • Value (Valeur) : true (vrai)

• Il applique des toléances pour permettre aux pods de s’exécuter sur des nœuds altérés pour des charges de travail à performances élevées, en s’assurant que le service de carte peut traiter la progression du trafic :
  • Effect (Effet) : NoSchedule
  • Key (Clé) : workload
  • Operator (Opérateur) : Equal (Égal)
  • Value (Valeur) : high-performance
• Il altère les nœuds à performances élevées avec workload=high-performance:NoSchedule.

Scénario 2 : Traitement des données pour le suivi environnemental

Une agence environnementale exécute une série d’analyses géospatiales pour suivre les modifications de l’utilisation du sol. L’analyse requiert d’importantes ressources de calcul et l’agence a dédié des nœuds avec des processeurs graphiques (GPU) dans ce but. Pour s’assurer que l’analyse géospatiale s’exécute efficacement sans entrer en concurrence avec d’autres services pour l'utilisation des ressources, l’administrateur de l’organisation :

• Configure des nœuds compatibles avec les processeurs graphiques (GPU) avec la paire clé-valeur gpu: true.
• Applique les règles d’affinité des nœuds pour planifier les pods d’analyse sur les nœuds GPU :
  • Type : Required (Obligatoire)
  • Key (Clé) : gpu
  • Operator (Opérateur) : In (Dans)
  • Value (Valeur) : true (vrai)
• Applique des tolérances pour permettre aux pods de s’exécuter sur les nœuds GPU altérés :
  • Effect (Effet) : NoSchedule
  • Key (Clé) : workload
  • Operator (Opérateur) : Equal (Égal)
  • Value (Valeur) : high-resource
• Altère les nœuds GPU avec workload=high-resource:NoSchedule pour empêcher la planification de pods nécessitant moins de ressources.

Scénario 3 : Optimisation des ressources pour les services d’entités partagés

Le service SIG d’une ville dispose de nombreux services d’entités qui ne sont pas fortement utilisés mais qui exercent collectivement une charge sur un seul déploiement de service. Pour permettre au service SIG de maintenir la disponibilité du service sans surcharger le système, l’administrateur de l’organisation :

• Configure les nœuds avec la clé resource-constrained.
• Applique les règles d’affinité des nœuds pour donner la priorité à la planification sur les nœuds avec une disponibilité moindre des ressources :
  • Type : Preferred (Préférentielle)
  • Key (Clé) : resource-constrained
  • Operator (Opérateur) : DoesNotExist (N’existe pas)
• Applique des tolérances sur les pods de service d’entités pour garantir qu’ils sont planifiés sur des nœuds altérés malgré les contraintes :
  • Effect (Effet) : PreferNoSchedule
  • Key (Clé) : resource-constrained
  • Operator (Opérateur) : Exists (Existe)
• Altère les nœuds qui connaissent des contraintes de ressources avec resource-constrained:PreferNoSchedule.

Scénario 4 : Éviter les perturbations dans le data store pendant la mise à l’échelle du cluster

Un gouvernement national dispose d’un modèle d’utilisation de service dans lequel les services sont fortement utilisés pendant la journée. Ce modèle nécessite un grand nombre de nœuds de cluster pour prendre en charge tous les réplicas de pods requis pour ces services. Étant donné que les services ne sont pas utilisés la nuit, l’organisation souhaite diminuer le nombre de nœuds afin de réaliser des économies sur les coûts de calcul sur le cloud. Arrêter des nœuds sur lesquels des pods de data store gérés par le système s’exécutent crée toutefois un risque d’interruption de ces pods. Pour éviter ces éventuelles perturbations, l’administrateur de l’organisation :

• Crée un groupe de nœuds séparé pour les pods de data store, chaque nœud étant étiqueté avec la paire clé-valeur data-store: true.
• Applique les règles d’affinité des nœuds pour garantir que les pods de data store sont planifiés sur des nœuds de ce groupe.
  • Type : Required (Obligatoire)
  • Key (Clé) : data-store
  • Operator (Opérateur) : In (Dans)
  • Value (Valeur) : true (vrai)
• Applique des tolérances pour permettre aux pods de data store de s’exécuter sur les nœuds de data store altérés :
  • Effect (Effet) : NoSchedule
  • Key (Clé) : workload
  • Operator (Opérateur) : Equal (Égal)
  • Value (Valeur) : data-store
• Nœuds de data store altérés avec workload=data-store:NoSchedule.
• Ne réduit pas le groupe de nœuds de data store lors de la réduction du nombre de nœuds de clusters la nuit.