SupportConsoleDéveloppeursCommencer un essaiContact

3.9. Éviction des pods à l'aide de l'ordonnanceur

Alors que le planificateur est utilisé pour déterminer le nœud le plus approprié pour héberger un nouveau pod, le déscheduler peut être utilisé pour évincer un pod en cours d'exécution afin qu'il puisse être reprogrammé sur un nœud plus approprié.

3.9.1. À propos du déschedulateur

Vous pouvez utiliser l'ordonnanceur pour expulser les pods sur la base de stratégies spécifiques afin que les pods puissent être replanifiés sur des nœuds plus appropriés.

Vous pouvez bénéficier de la désimplantation des pods en cours d'exécution dans des situations telles que les suivantes :

  • Les nœuds sont sous-utilisés ou surutilisés.
  • Les exigences relatives aux pods et aux affinités entre nœuds, telles que les taches ou les étiquettes, ont changé et les décisions d'ordonnancement initiales ne sont plus appropriées pour certains nœuds.
  • En cas de défaillance d'un nœud, les pods doivent être déplacés.
  • De nouveaux nœuds sont ajoutés aux grappes.
  • Les pods ont été redémarrés trop souvent.
Important

L'ordonnanceur ne planifie pas le remplacement des pods expulsés. Le planificateur effectue automatiquement cette tâche pour les pods évincés.

Lorsque l'ordonnanceur décide d'expulser des pods d'un nœud, il utilise le mécanisme général suivant :

  • Les pods des espaces de noms openshift-* et kube-system ne sont jamais expulsés.
  • Les pods critiques dont la valeur de priorityClassName est system-cluster-critical ou system-node-critical ne sont jamais expulsés.
  • Les pods statiques, en miroir ou autonomes qui ne font pas partie d'un contrôleur de réplication, d'un ensemble de réplicas, d'un déploiement ou d'un travail ne sont jamais expulsés car ces pods ne seront pas recréés.
  • Les pods associés aux ensembles de démons ne sont jamais expulsés.
  • Les pods disposant d'un stockage local ne sont jamais expulsés.
  • Les pods "best effort" sont éliminés avant les pods "burstable" et "guaranteed".
  • Tous les types de pods ayant l'annotation descheduler.alpha.kubernetes.io/evict sont éligibles à l'expulsion. Cette annotation est utilisée pour passer outre les contrôles qui empêchent l'expulsion, et l'utilisateur peut choisir le pod qui sera expulsé. Les utilisateurs doivent savoir comment et si le pod sera recréé.
  • Les pods soumis au budget de perturbation des pods (PDB) ne sont pas expulsés si la désynchronisation viole leur budget de perturbation des pods (PDB). Les pods sont expulsés en utilisant la sous-ressource d'expulsion pour gérer le PDB.

3.9.2. Profils du déschedulateur

Les profils suivants sont disponibles :

AffinityAndTaints

Ce profil expulse les pods qui violent l'anti-affinité inter-pods, l'affinité des nœuds et les taches des nœuds.

Il permet de mettre en œuvre les stratégies suivantes :

  • RemovePodsViolatingInterPodAntiAffinity: élimine les pods qui violent l'anti-affinité inter-pods.
  • RemovePodsViolatingNodeAffinity: supprime les pods qui ne respectent pas l'affinité des nœuds.

  • RemovePodsViolatingNodeTaints: supprime les pods qui violent NoSchedule taints sur les nœuds.

    Les pods dont le type d'affinité de nœud est requiredDuringSchedulingIgnoredDuringExecution sont supprimés.

TopologyAndDuplicates

Ce profil expulse les pods afin de répartir uniformément les pods similaires ou les pods du même domaine topologique entre les nœuds.

Il permet de mettre en œuvre les stratégies suivantes :

  • RemovePodsViolatingTopologySpreadConstraintil détecte les domaines topologiques déséquilibrés et tente d'expulser les pods des domaines les plus vastes lorsque les contraintes de DoNotSchedule sont violées.
  • RemoveDuplicates: garantit qu'il n'y a qu'un seul pod associé à un ensemble de répliques, à un contrôleur de réplication, à un déploiement ou à un travail s'exécutant sur le même nœud. S'il y en a plus, ces pods dupliqués sont évincés pour une meilleure distribution des pods dans un cluster.
LifecycleAndUtilization

Ce profil permet d'expulser les pods qui fonctionnent depuis longtemps et d'équilibrer l'utilisation des ressources entre les nœuds.

Il permet de mettre en œuvre les stratégies suivantes :

  • RemovePodsHavingTooManyRestarts: supprime les pods dont les conteneurs ont été redémarrés trop souvent.

    Pods où la somme des redémarrages de tous les conteneurs (y compris les conteneurs d'initialisation) est supérieure à 100.

  • LowNodeUtilizationle système de gestion des pods : trouve les nœuds qui sont sous-utilisés et expulse les pods, si possible, des nœuds surutilisés dans l'espoir que la recréation des pods expulsés sera programmée sur ces nœuds sous-utilisés.

    Un nœud est considéré comme sous-utilisé si son utilisation est inférieure à 20 ou à tous les seuils (CPU, mémoire et nombre de pods).

    Un nœud est considéré comme surutilisé si son utilisation est supérieure à 50 ou à l'un des seuils (CPU, mémoire et nombre de pods).

  • PodLifeTime: évince les nacelles trop anciennes.

    Par défaut, les pods datant de plus de 24 heures sont supprimés. Vous pouvez personnaliser la valeur de la durée de vie des pods.

SoftTopologyAndDuplicates

Ce profil est le même que celui de TopologyAndDuplicates, sauf que les pods ayant des contraintes topologiques douces, comme whenUnsatisfiable: ScheduleAnyway, sont également pris en compte pour l'expulsion.

Note

N'activez pas à la fois SoftTopologyAndDuplicates et TopologyAndDuplicates. L'activation des deux entraîne un conflit.

EvictPodsWithLocalStorage
Ce profil permet aux pods disposant d'un stockage local d'être éligibles à l'éviction.
EvictPodsWithPVC
Ce profil permet aux pods ayant des réclamations de volumes persistants d'être éligibles à l'éviction. Si vous utilisez Kubernetes NFS Subdir External Provisioner, vous devez ajouter un espace de noms exclu pour l'espace de noms où le provisionneur est installé.

3.9.3. Installation du déschedulateur

Le descheduler n'est pas disponible par défaut. Pour l'activer, vous devez installer Kube Descheduler Operator depuis OperatorHub et activer un ou plusieurs profils de descheduler.

Par défaut, le descheduler fonctionne en mode prédictif, ce qui signifie qu'il ne fait que simuler les évictions de pods. Vous devez changer le mode en mode automatique pour que le descheduler effectue les évictions de pods.

Important

Si vous avez activé les plans de contrôle hébergés dans votre cluster, définissez un seuil de priorité personnalisé pour réduire le risque d'éviction des pods dans les espaces de noms des plans de contrôle hébergés. Définissez le nom de la classe de seuil de priorité sur hypershift-control-plane, car elle a la valeur de priorité la plus basse (100000000) des classes de priorité du plan de contrôle hébergé.

Conditions préalables

  • Privilèges d'administrateur de cluster.
  • Accès à la console web d'OpenShift Container Platform.

Procédure

  1. Connectez-vous à la console web de OpenShift Container Platform.

  2. Créer l'espace de noms requis pour l'opérateur Kube Descheduler.

    1. Naviguez jusqu'à Administration Namespaces et cliquez sur Create Namespace.
    2. Entrez openshift-kube-descheduler-operator dans le champ Name, entrez openshift.io/cluster-monitoring=true dans le champ Labels pour activer les métriques du déscheduler, et cliquez sur Create.

  3. Installez l'opérateur Kube Descheduler.

    1. Naviguez jusqu'à Operators OperatorHub.
    2. Tapez Kube Descheduler Operator dans le champ de filtre.
    3. Sélectionnez le site Kube Descheduler Operator et cliquez sur Install.
    4. Sur la page Install Operator, sélectionnez A specific namespace on the cluster. Sélectionnez openshift-kube-descheduler-operator dans le menu déroulant.
    5. Ajustez les valeurs de Update Channel et Approval Strategy aux valeurs souhaitées.
    6. Cliquez sur Install.

  4. Créer une instance de déscheduler.

    1. Dans la page Operators Installed Operators, cliquez sur Kube Descheduler Operator.
    2. Sélectionnez l'onglet Kube Descheduler et cliquez sur Create KubeDescheduler.

    3. Modifiez les paramètres si nécessaire.

      1. Pour expulser des pods au lieu de simuler les expulsions, remplacez le champ Mode par Automatic.

      2. Développez la section Profiles pour sélectionner un ou plusieurs profils à activer. Le profil AffinityAndTaints est activé par défaut. Cliquez sur Add Profile pour sélectionner d'autres profils.

        Note

        N'activez pas à la fois TopologyAndDuplicates et SoftTopologyAndDuplicates. L'activation des deux entraîne un conflit.

      3. Optionnel : Développez la section Profile Customizations pour définir des configurations optionnelles pour le déscheduler.

        • Définissez une valeur personnalisée de durée de vie des pods pour le profil LifecycleAndUtilization. Utilisez le champ podLifetime pour définir une valeur numérique et une unité valide (s, m, ou h). La durée de vie par défaut est de 24 heures (24h).

        • Définissez un seuil de priorité personnalisé pour que les pods soient pris en compte pour l'expulsion uniquement si leur priorité est inférieure à un niveau de priorité spécifié. Utilisez le champ thresholdPriority pour définir un seuil de priorité numérique ou utilisez le champ thresholdPriorityClassName pour spécifier un certain nom de classe de priorité.

          Note

          Ne spécifiez pas à la fois thresholdPriority et thresholdPriorityClassName pour le déscheduler.

        • Définissez des espaces de noms spécifiques à exclure ou à inclure dans les opérations du déscheduler. Développez le champ namespaces et ajoutez des espaces de noms à la liste excluded ou included. Vous ne pouvez définir qu'une liste d'espaces de noms à exclure ou une liste d'espaces de noms à inclure. Notez que les espaces de noms protégés (openshift-*, kube-system, hypershift) sont exclus par défaut.

          Important

          La stratégie LowNodeUtilization ne prend pas en charge l'exclusion d'espaces de noms. Si le profil LifecycleAndUtilization est défini, ce qui active la stratégie LowNodeUtilization, aucun espace de noms n'est exclu, même les espaces de noms protégés. Pour éviter les expulsions des espaces de noms protégés lorsque la stratégie LowNodeUtilization est activée, définissez le nom de la classe de priorité sur system-cluster-critical ou system-node-critical.

        • Expérimental : Définir les seuils de sous-utilisation et de surutilisation pour la stratégie LowNodeUtilization. Utilisez le champ devLowNodeUtilizationThresholds pour définir l'une des valeurs suivantes :

          • Low: 10 % sous-utilisés et 30 % surutilisés
          • Medium20% de sous-utilisation et 50% de sur-utilisation (par défaut)
          • High: 40 % sous-utilisés et 70 % surutilisés
          Note

          Ce paramètre est expérimental et ne doit pas être utilisé dans un environnement de production.

      4. En option : Utilisez le champ Descheduling Interval Seconds pour modifier le nombre de secondes entre les exécutions du descheduler. La valeur par défaut est 3600 secondes.
    4. Cliquez sur Create.

Vous pouvez également configurer les profils et les paramètres du descheduler ultérieurement en utilisant le CLI OpenShift (oc). Si vous n'avez pas ajusté les profils lors de la création de l'instance de descheduler depuis la console web, le profil AffinityAndTaints est activé par défaut.

3.9.4. Configuration des profils de désordre

Vous pouvez configurer les profils utilisés par le descheduler pour évincer les pods.

Conditions préalables

  • Privilèges de l'administrateur du cluster

Procédure

  1. Modifiez l'objet KubeDescheduler: 

    $ oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator

  2. Spécifiez un ou plusieurs profils dans la section spec.profiles. 

    apiVersion: operator.openshift.io/v1
kind: KubeDescheduler
metadata:
  name: cluster
  namespace: openshift-kube-descheduler-operator
spec:
  deschedulingIntervalSeconds: 3600
  logLevel: Normal
  managementState: Managed
  operatorLogLevel: Normal
  mode: Predictive                                     1
  profileCustomizations:
    namespaces:                                        2
      excluded:
      - my-namespace
    podLifetime: 48h                                   3
    thresholdPriorityClassName: my-priority-class-name 4
  profiles:                                            5
  - AffinityAndTaints
  - TopologyAndDuplicates                              6
  - LifecycleAndUtilization
  - EvictPodsWithLocalStorage
  - EvictPodsWithPVC
    1
    Facultatif : Par défaut, le descheduler n'expulse pas les pods. Pour évincer les modules, définissez mode sur Automatic.
    2
    Facultatif : Définissez une liste d'espaces de noms créés par l'utilisateur à inclure ou à exclure des opérations de déscheduler. Utilisez excluded pour définir une liste d'espaces de noms à exclure ou utilisez included pour définir une liste d'espaces de noms à inclure. Notez que les espaces de noms protégés (openshift-*, kube-system, hypershift) sont exclus par défaut.
    Important

    La stratégie LowNodeUtilization ne prend pas en charge l'exclusion d'espaces de noms. Si le profil LifecycleAndUtilization est défini, ce qui active la stratégie LowNodeUtilization, aucun espace de noms n'est exclu, même les espaces de noms protégés. Pour éviter les expulsions des espaces de noms protégés lorsque la stratégie LowNodeUtilization est activée, définissez le nom de la classe de priorité sur system-cluster-critical ou system-node-critical.

    3
    Facultatif : Activez une valeur personnalisée de durée de vie du pod pour le profil LifecycleAndUtilization. Les unités valides sont s, m, ou h. La durée de vie du pod par défaut est de 24 heures.
    4
    Facultatif : Spécifiez un seuil de priorité pour que les pods soient pris en compte pour l'expulsion uniquement si leur priorité est inférieure au niveau spécifié. Utilisez le champ thresholdPriority pour définir un seuil de priorité numérique (par exemple, 10000) ou utilisez le champ thresholdPriorityClassName pour spécifier un certain nom de classe de priorité (par exemple, my-priority-class-name). Si vous spécifiez un nom de classe de priorité, il doit déjà exister ou le descheduler lancera une erreur. Ne définissez pas à la fois thresholdPriority et thresholdPriorityClassName.
    5
    Ajouter un ou plusieurs profils à activer. Profils disponibles : AffinityAndTaints, TopologyAndDuplicates, LifecycleAndUtilization, SoftTopologyAndDuplicates, EvictPodsWithLocalStorage, et EvictPodsWithPVC.
    6
    N'activez pas à la fois TopologyAndDuplicates et SoftTopologyAndDuplicates. L'activation des deux entraîne un conflit.

    Vous pouvez activer plusieurs profils ; l'ordre dans lequel les profils sont spécifiés n'est pas important.

  3. Enregistrez le fichier pour appliquer les modifications.

3.9.5. Configuration de l'intervalle de déschedulation

Vous pouvez configurer le temps qui s'écoule entre deux exécutions du Descheduler. La valeur par défaut est de 3600 secondes (une heure).

Conditions préalables

  • Privilèges de l'administrateur du cluster

Procédure

  1. Modifiez l'objet KubeDescheduler: 

    $ oc edit kubedeschedulers.operator.openshift.io cluster -n openshift-kube-descheduler-operator

  2. Mettez à jour le champ deschedulingIntervalSeconds avec la valeur souhaitée : 

    apiVersion: operator.openshift.io/v1
kind: KubeDescheduler
metadata:
  name: cluster
  namespace: openshift-kube-descheduler-operator
spec:
  deschedulingIntervalSeconds: 3600 1
...
    1
    Définit le nombre de secondes entre les exécutions du planificateur. Une valeur de 0 dans ce champ permet d'exécuter le descheduler une fois et de le quitter.
  3. Enregistrez le fichier pour appliquer les modifications.

3.9.6. Désinstallation du déscheduler

Vous pouvez supprimer le descheduler de votre cluster en supprimant l'instance du descheduler et en désinstallant Kube Descheduler Operator. Cette procédure nettoie également l'espace de noms KubeDescheduler CRD et openshift-kube-descheduler-operator.

Conditions préalables

  • Privilèges d'administrateur de cluster.
  • Accès à la console web d'OpenShift Container Platform.

Procédure

  1. Connectez-vous à la console web de OpenShift Container Platform.

  2. Supprime l'instance du déscheduler.

    1. Sur la page Operators Installed Operators, cliquez sur Kube Descheduler Operator.
    2. Sélectionnez l'onglet Kube Descheduler.
    3. Cliquez sur le menu Options kebab à côté de l'entrée cluster et sélectionnez Delete KubeDescheduler.
    4. Dans la boîte de dialogue de confirmation, cliquez sur Delete.

  3. Désinstaller l'opérateur Kube Descheduler.

    1. Naviguez jusqu'à Operators Installed Operators.
    2. Cliquez sur le menu Options kebab à côté de l'entrée Kube Descheduler Operator et sélectionnez Uninstall Operator.
    3. Dans la boîte de dialogue de confirmation, cliquez sur Uninstall.

  4. Supprimer l'espace de noms openshift-kube-descheduler-operator.

    1. Naviguez jusqu'à Administration Namespaces.
    2. Saisissez openshift-kube-descheduler-operator dans le champ de filtre.
    3. Cliquez sur le menu Options kebab à côté de l'entrée openshift-kube-descheduler-operator et sélectionnez Delete Namespace.
    4. Dans la boîte de dialogue de confirmation, saisissez openshift-kube-descheduler-operator et cliquez sur Delete.

  5. Supprimer le CRD KubeDescheduler.

    1. Naviguez jusqu'à Administration Custom Resource Definitions.
    2. Saisissez KubeDescheduler dans le champ de filtre.
    3. Cliquez sur le menu Options kebab à côté de l'entrée KubeDescheduler et sélectionnez Delete CustomResourceDefinition.
    4. Dans la boîte de dialogue de confirmation, cliquez sur Delete.
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.