Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

2.6. Inclure la priorité pod dans les décisions relatives à la programmation des pod

Dans votre cluster, vous pouvez activer la priorité de pod et la préemption. La priorité des pod indique l’importance d’un pod par rapport aux autres gousses et file d’attente sur la base de cette priorité.

Afin d’utiliser la priorité et la préemption, faites référence à une classe de priorité dans la spécification de pod pour appliquer ce poids à l’horaire.

2.6.1. Comprendre la priorité des pod
Copier lien

Lorsque vous utilisez la fonction Pod Priority and Preemption, les commandes de planificateurs en attente par leur priorité, et un pod en attente est placé en avance sur d’autres pods en attente avec une priorité inférieure dans la file d’attente. En conséquence, le pod de priorité plus élevé pourrait être programmé plus tôt que les pods avec une priorité moindre si ses exigences en matière de planification sont respectées. Dans le cas où une gousse ne peut pas être programmée, le programmeur continue de planifier d’autres gousses de priorité inférieure.

2.6.1.1. Classes prioritaires de pod
Copier lien

Il est possible d’attribuer des pods à une classe de priorité, qui est un objet non-namespace qui définit un mappage d’un nom à la valeur entière de la priorité. La valeur est élevée, plus la priorité est élevée.

L’objet de classe prioritaire peut prendre n’importe quelle valeur entière 32 bits inférieure ou égale à 1000000000 (un milliard). Le nombre de réserves est supérieur ou égal à un milliard pour les gousses critiques qui ne doivent pas être prévenues ou expulsées. Le Red Hat OpenShift Service sur AWS dispose par défaut de deux classes de priorité réservées aux modules de système critiques afin d’avoir une planification garantie. 

$ oc get priorityclasses
Copy to Clipboard Toggle word wrap

Exemple de sortie

NAME                      VALUE        GLOBAL-DEFAULT   AGE
system-node-critical      2000001000   false            72m
system-cluster-critical   2000000000   false            72m
openshift-user-critical   1000000000   false            3d13h
cluster-logging           1000000      false            29s
Copy to Clipboard Toggle word wrap

  • critique du nœud système - Cette classe prioritaire a une valeur de 2000001000 et est utilisée pour toutes les gousses qui ne devraient jamais être expulsées d’un nœud. Des exemples de gousses qui ont cette classe prioritaire sont ovnkube-node, et ainsi de suite. La classe de priorité critique par défaut comprend un certain nombre de composants critiques, par exemple:

    • le maître-api
    • le maître-contrôleur
    • le maître-etcd
    • les ovn-kubernetes
    • la synchronisation

  • cette classe prioritaire a une valeur de 2000000000 (deux milliards) et est utilisée avec des gousses qui sont importantes pour le cluster. Les pods de cette classe prioritaire peuvent être expulsés d’un nœud dans certaines circonstances. À titre d’exemple, les pods configurés avec la classe de priorité critique du nœud système peuvent prendre la priorité. Cependant, cette classe prioritaire assure une planification garantie. Des exemples de gousses qui peuvent avoir cette classe de priorité sont des composants fluides, des composants complémentaires comme un programmeur, et ainsi de suite. La classe de priorité critique par défaut comprend un certain nombre de composants critiques, par exemple:

    • Fluentd
    • métriques-serveur
    • Descheduler
  • critique d’OpenShift - Vous pouvez utiliser le champ prioritéClassName avec des pods importants qui ne peuvent pas lier leur consommation de ressources et n’ont pas un comportement prévisible de consommation de ressources. Les pods Prometheus sous les espaces de noms openshift-monitoring et openshift-user-workload-monitoring utilisent l’openshift-user-responsable prioritéClassName. Les charges de travail de surveillance utilisent le système critique comme première classe prioritaire, mais cela pose des problèmes lorsque la surveillance utilise une mémoire excessive et que les nœuds ne peuvent pas les expulser. En conséquence, la surveillance laisse tomber la priorité pour donner de la flexibilité au programmeur, en déplaçant de lourdes charges de travail pour maintenir les nœuds critiques en fonctionnement.
  • cluster-logging - Cette priorité est utilisée par Fluentd pour s’assurer que les gousses Fluentd sont programmées pour les nœuds sur d’autres applications.

2.6.1.2. Les noms de priorité pod
Copier lien

Après avoir une ou plusieurs classes prioritaires, vous pouvez créer des pods qui spécifient un nom de classe prioritaire dans une spécification Pod. Le contrôleur d’admission prioritaire utilise le champ de nom de la classe de priorité pour remplir la valeur entière de la priorité. Lorsque la classe de priorité nommée n’est pas trouvée, le pod est rejeté.

2.6.2. Comprendre la préemption de la gousse
Copier lien

Lorsqu’un développeur crée un pod, le pod entre dans une file d’attente. Lorsque le développeur a configuré le pod pour la priorité ou la préemption de la pod, le planificateur choisit un pod dans la file d’attente et essaie de programmer le pod sur un nœud. Lorsque le planificateur ne trouve pas d’espace sur un nœud approprié qui satisfait à toutes les exigences spécifiées de la gousse, la logique de préemption est déclenchée pour la gousse en attente.

Lorsque le planificateur préempte un ou plusieurs pods sur un nœud, le champ nodeName nominé de la spécification Pod à priorité supérieure est défini sur le nom du nœud, ainsi que le champ nodename. Le planificateur utilise le champ nominatifNodeName pour garder une trace des ressources réservées aux pods et fournit également des informations à l’utilisateur sur les préemptions dans les clusters.

Après que le planificateur préempte un pod de priorité inférieure, le planificateur honore la période de résiliation gracieuse du pod. Lorsqu’un autre nœud devient disponible pendant que le planificateur attend la fin de la pod de priorité inférieure, le planificateur peut programmer la pod de priorité plus élevée sur ce nœud. En conséquence, le champ nominatifNodeName et le champ nodeName du Pod spec peuvent être différents.

En outre, si le planificateur préempte les pods sur un nœud et attend la résiliation, et un pod avec un pod de priorité plus élevé que la gousse en attente doit être programmé, le programmeur peut planifier la pod de priorité plus élevée à la place. Dans un tel cas, le planificateur annule le nom nodeNodeName de la gousse en attente, ce qui rend la gousse éligible à un autre nœud.

La préemption n’enlève pas nécessairement toutes les gousses de priorité inférieure d’un nœud. Le programmeur peut programmer une pod en attente en supprimant une partie des gousses de priorité inférieure.

Le planificateur ne considère un nœud pour la prévention de la gousse que si la gousse en attente peut être programmée sur le nœud.

2.6.2.1. Classes prioritaires non préventives
Copier lien

Les pods avec la politique de préemption définie à Never ne sont jamais placés dans la file d’attente avant les pods de priorité inférieure, mais ils ne peuvent pas préempter d’autres gousses. Dans la file d’attente, une pod non préventive attend d’être programmée jusqu’à ce que des ressources suffisantes soient gratuites et qu’elles puissent être programmées. Les gousses non préventives, comme les autres gousses, sont sujettes à un recul du planning. Cela signifie que si le planificateur essaie sans succès de programmer ces gousses, ils sont récupérés avec une fréquence inférieure, permettant à d’autres gousses avec une priorité inférieure d’être programmées avant eux.

Les gousses non préventives peuvent encore être évitées par d’autres gousses hautement prioritaires.

Lorsque vous activez la priorité et la préemption de pod, considérez vos autres paramètres de planning:

Budget prioritaire de la pod et perturbation des pods
Le budget de perturbation de la pod spécifie le nombre ou le pourcentage minimum de répliques qui doivent être en hausse à la fois. Lorsque vous spécifiez des budgets de perturbation de pod, Red Hat OpenShift Service sur AWS les respecte lorsque vous préemptez les pods au meilleur niveau d’effort. Le planificateur tente de prévenir les pods sans violer le budget de perturbation de la pod. En l’absence de telles gousses, des gousses à priorité inférieure pourraient être évitées malgré leurs besoins budgétaires de perturbation de la pod.
La priorité des pod et l’affinité des pod
L’affinité des gousses exige qu’une nouvelle gousse soit programmée sur le même nœud que les autres gousses portant la même étiquette.

Lorsqu’une gousse en attente a une affinité interpodique avec une ou plusieurs des gousses de priorité inférieures sur un nœud, le planificateur ne peut pas préjuger les pods de priorité inférieure sans enfreindre les exigences en matière d’affinité. Dans ce cas, le planificateur cherche un autre nœud pour programmer le pod en attente. Cependant, il n’y a aucune garantie que le programmeur puisse trouver un nœud approprié et que la gousse en attente pourrait ne pas être programmée.

Afin d’éviter cette situation, configurez soigneusement l’affinité des pods avec des pods de priorité égale.

2.6.2.3. Cessation gracieuse des gousses préemptées
Copier lien

Lors de la préemption d’un pod, le planificateur attend que le délai de résiliation gracieux de la pod expire, permettant à la gousse de terminer le travail et la sortie. Lorsque la gousse ne sort pas après la période, le planificateur tue la gousse. Ce délai de résiliation gracieux crée un écart de temps entre le point que le planificateur préempte le pod et le moment où la gousse en attente peut être programmée sur le nœud.

Afin de minimiser cet écart, configurez un petit délai de résiliation gracieux pour les pods de priorité inférieure.

2.6.3. Configuration de la priorité et de la préemption
Copier lien

Appliquez la priorité pod et la préemption en créant un objet de classe prioritaire et en associant des pods à la priorité en utilisant la prioritéClassName dans vos spécifications de pod.

Note

Il n’est pas possible d’ajouter une classe de priorité directement à une pod existante.

Procédure

Configurer votre cluster pour utiliser la priorité et la préemption:

  1. Définissez une spécification de pod pour inclure le nom d’une classe de priorité en créant un fichier YAML similaire à ce qui suit: 

    apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: system-cluster-critical
    1
    Copy to Clipboard Toggle word wrap
    1
    Indiquez la classe de priorité à utiliser avec ce pod.

  2. Créer le pod: 

    $ oc create -f <file-name>.yaml
    Copy to Clipboard Toggle word wrap

    Il est possible d’ajouter le nom de priorité directement à la configuration du pod ou à un modèle de pod.

Retour au début
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. Découvrez nos récentes mises à jour.

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 le Blog 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.

Theme

© 2025 Red Hat