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. Lorsque vous avez différents types de nœuds dans votre cluster, il peut être important d’exercer un contrôle sur les nœuds sur lesquels les pods sont programmés. Il existe quatre outils que vous pouvez utiliser pour le placement des pods de contrôle :
Des étiquettes de nœud sont appliquées à un nœud pour spécifier des informations sur ce nœud. Une étiquette peut être une clé ou une paire clé/valeur.
L’affinité des nœuds est appliquée à un pod pour contraindre ce pod à s’exécuter sur des nœuds avec une étiquette spécifiée.
Des altérations sont appliquées à un nœud pour empêcher que des pods ne soient programmés sur ce nœud.
Des tolérances sont appliquées à un pod pour permettre à ce pod d’ignorer des altérations spécifiques.
Pour en savoir plus sur les étiquettes de nœuds, l’affinité des nœuds, les altérations et les tolérances de manière générale, reportez-vous à la documentation Kubernetes. Pour plus d’informations sur l’application de l’affinité et des tolérances de nœuds aux pods dans ArcGIS Enterprise on Kubernetes, reportez-vous à la rubrique Gérer le placement des pods.
Avantages
Les étiquettes de nœuds et l’affinité des nœuds garantissent qu’un pod est planifié sur le nœud approprié. Les altérations et les tolérances garantissent qu’un nœud dispose uniquement des pods appropriés programmés sur lui. Les combiner vous aide à améliorer l’isolement, optimiser l’allocation des ressources et respecter efficacement les exigences de conformité au sein de votre cluster Kubernetes :
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.
Gérer le placement des pods
Il est recommandé d’appliquer des étiquettes de nœuds avant l’affinité des nœuds. Cela empêche les pods de rester bloqués dans un état en attente, car les nœuds n’ont pas encore l’étiquette correspondante. De même, il est recommandé d’appliquer des tolérances avant d’altérer les nœuds. Cela permet d’éviter d’exclure malencontreusement des pods qui ne disposent pas encore de tolérances correspondantes et de provoquer une interruption de vos services.
Dans la plupart des environnements, vous pouvez regrouper vos charges de travail à l’aide de pools de nœuds ou de groupes de nœuds. Il est recommandé d’appliquer des étiquettes et des altérations à des groupes de nœuds plutôt qu’à des nœuds individuels.
Dans ArcGIS Enterprise on Kubernetes, vous pouvez utiliser ArcGIS Enterprise Manager pour définir l’affinité des nœuds et les tolérances pour les déploiements suivants :
Configuration de l’affinité des nœuds
Pour configurer une règle d’affinité des nœuds, définissez les valeurs suivantes :
Type : type d’affinité des nœuds. Les types suivants sont disponibles :
Preferred (Préférentielle) (
PreferredDuringSchedulingIgnoredDuringExecution) : le pod préfère être planifié sur un nœud respectant la règle.Required (Obligatoire) (
RequiredDuringSchedulingIgnoredDuringExecution) : le pod doit être planifié sur un nœud respectant la règle.
Key (Clé) : clé de l’étiquette de nœud ou de l’annotation à laquelle la règle doit correspondre.
Operator (Opérateur) : opérateur de la règle. Les opérateurs suivants sont disponibles :
In (Dans) : l’étiquette de nœud ou l’annotation doit se trouver dans la liste de valeurs spécifiée.
Not in (Pas dans) : l’étiquette de nœud ou l’annotation ne doit pas se trouver dans la liste de valeurs spécifiée.
Exists (Existe) : le nœud doit comporter l’étiquette ou l’annotation spécifiée.
Does not exist (N’existe pas) : le nœud ne doit pas comporter l’étiquette ou l’annotation spécifiée.
Value (Valeur) : liste de valeurs à mettre en correspondance avec l’étiquette de nœud ou l’annotation. Non disponible lorsque l’opérateur Exists (Existe) ou Does not existe (N’existe pas) est sélectionné.
Configuration des tolérances
Pour configurer une tolérance, définissez les valeurs suivantes :
Effect (Effet) : effet d’altération auquel doit correspondre la tolérance. Les effets suivants sont disponibles :
No schedule (Ne pas planifier) : les nouveaux pods ne sont pas planifiés sur le nœud altéré sans tolérance correspondante.
Prefer no schedule (Éviter de planifier) : les nouveaux pods essaient d’éviter d’être planifiés sur le nœud altéré sans tolérance correspondante, mais cela n’est pas garanti.
No Execute (Ne pas exécuter) : n’importe quel pod sans tolérance correspondante est expulsé immédiatement après l’altération du nœud. Les nouveaux pods ne sont pas planifiés sur le nœud altéré sans tolérance correspondante.
Key (Clé) : clé de l’altération à laquelle doit correspondre la tolérance.
Operator (Opérateur) : opérateur à utiliser pour la tolérance. Les opérateurs suivants sont disponibles :
Equal (Égal) : le pod tolère une altération avec la clé et la valeur spécifiées.
Exists (Existe) : le pod tolère une altération avec la clé spécifiée.
Value (Valeur) : valeur de l’altération à laquelle doit correspondre la tolérance si l’opération est définie sur Equal (Égal). Non disponible lorsque l’opérateur Exists (Existe) est sélectionné.
Remarque :
Les charges de travail d’analyse raster et de service de notebook qui doivent exécuter des nœuds compatibles avec les GPU nécessitent des paramètres d’affinité des nœuds et de tolérance spécifiques. Pour plus d’informations sur ces paramètres, reportez-vous aux rubriques Configurer des nœuds compatibles avec les processeurs graphiques (GPU) pour les charges de travail d’analyse raster et Consulter et mettre à jour les runtimes pour les charges de travail de service de notebook.
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 :
Ajouter l’étiquette clé/valeur high-performance: true aux nœuds avec de ressources CPU et mémoire élevées.
Appliquer des règles d’affinité des nœuds pour prioriser la planification des pods de service de carte sur les nœuds disposant de ressources CPU et mémoire élevées. Cela garantit que le service de carte peut traiter la progression du trafic :
Type : Preferred (Préférentielle)
Key (Clé) : high-performance
Operator (Opérateur) : Exists (Existe)
Value (Valeur) : true (vrai)
Applique une tolérance aux pods pour le service de carte critique, permettant de les planifier sur des nœuds altérés pour des charges de travail hautes performances.
Effect (Effet) : NoSchedule
Key (Clé) : workload
Operator (Opérateur) : Equal (Égal)
Value (Valeur) : high-performance
Altère les nœuds hautes performances avec workload=high-performance:NoSchedule pour empêcher que des pods moins critiques sans la tolérance correspondante ne soient programmés sur le nœud. Cela garantit qu’il y aura de la place sur les nœuds à performances élevées pour programmer les pods lors des services liés à l’événement.
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 :
Ajoute l’étiquette clé/valeur gpu: true aux nœuds avec GPU.
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 une tolérance aux pods d’analyse, permettant de les planifier 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 sans la tolérance correspondante sur le nœud. Cela garantit que les machines coûteuses équipées de GPU ne sont utilisées que pour les pods d’analyse qui en ont besoin.
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. Le cluster contient des nœuds premium qui garantissent une qualité de service pour les services à haute priorité et des nœuds à faible disponibilité des ressources pour les services à faible priorité. Pour s’assurer que ces services d’entités à faible priorité soient préférentiellement planifiés sur les nœuds les moins coûteux, l’administrateur de l’organisation :
Configure les nœuds avec une disponibilité de ressources plus faible avec la clé resource-constrained.
Applique les règles d’affinité des nœuds aux pods de service d’entités 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 avec une disponibilité des ressources moins élevée 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 avec état gérés par le système s’exécutent crée toutefois un risque d’interruption d’ArcGIS Enterprise. Pour éviter ces éventuelles perturbations, l’administrateur de l’organisation :
Crée un groupe de nœuds séparé.
Ajoute l’étiquette clé/valeur data-store: true à chaque nœud du groupe.
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 une tolérance aux pods du Data Store avec état pour leur permettre 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
Altère les nœuds de Data Store avec workload=data-store:NoSchedule pour empêcher que des pods sans état et sans la tolérance correspondante ne soient programmés sur le nœud. Cela garantit qu’il y a de la place sur les nœuds de Data Store pour planifier tous les pods de Data Store avec état.
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. Étant donné que tous les pods de Data Store avec état se trouvent dans ce groupe de nœuds, ils ne sont pas affectés par la réduction du nombre de nœuds des autres groupes de nœuds.