2.10. Prise en compte de la priorité des pods dans les décisions d'ordonnancement des pods
Vous pouvez activer la priorité et la préemption des pods dans votre cluster. La priorité des pods indique l'importance d'un pod par rapport aux autres pods et met les pods en file d'attente en fonction de cette priorité. La préemption des pods permet au cluster d'expulser, ou de préempter, les pods de priorité inférieure afin que les pods de priorité supérieure puissent être planifiés s'il n'y a pas d'espace disponible sur un nœud approprié. La priorité des pods affecte également l'ordre de planification des pods et l'ordre d'expulsion en cas d'absence de ressources sur le nœud.
Pour utiliser la priorité et la préemption, vous devez créer des classes de priorité qui définissent le poids relatif de vos modules. Ensuite, faites référence à une classe de priorité dans la spécification du pod pour appliquer ce poids à la planification.
2.10.1. Comprendre la priorité des pods
Lorsque vous utilisez la fonctionnalité de priorité et de préemption des pods, l'ordonnanceur classe les pods en attente en fonction de leur priorité, et un pod en attente est placé devant d'autres pods en attente ayant une priorité inférieure dans la file d'attente d'ordonnancement. Par conséquent, le pod le plus prioritaire peut être programmé plus tôt que les pods moins prioritaires si ses besoins de programmation sont satisfaits. Si un module ne peut pas être programmé, l'ordonnanceur continue à programmer d'autres modules moins prioritaires.
2.10.1.1. Classes de priorité pour les pods
Vous pouvez attribuer aux pods une classe de priorité, qui est un objet sans espace de noms définissant une correspondance entre un nom et la valeur entière de la priorité. Plus la valeur est élevée, plus la priorité est importante.
Un objet de classe de priorité peut prendre n'importe quelle valeur entière de 32 bits inférieure ou égale à 1000000000 (un milliard). Réservez les nombres supérieurs ou égaux à un milliard aux pods critiques qui ne doivent pas être préemptés ou évincés. Par défaut, OpenShift Container Platform a deux classes de priorité réservées pour les pods système critiques afin de garantir l'ordonnancement.
$ oc get priorityclasses
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
system-node-critical - Cette classe de priorité a une valeur de 2000001000 et est utilisée pour tous les pods qui ne doivent jamais être expulsés d'un nœud. Les exemples de pods ayant cette classe de priorité sont
sdn-ovs,sdn, et ainsi de suite. Un certain nombre de composants critiques incluent la classe de prioritésystem-node-criticalpar défaut, par exemple :- master-api
- maître-contrôleur
- master-etcd
- sdn
- sdn-ovs
- synchronisation
system-cluster-critical - Cette classe de priorité a une valeur de 2000000000 (deux milliards) et est utilisée avec les pods qui sont importants pour le cluster. Les modules de cette classe de priorité peuvent être expulsés d'un nœud dans certaines circonstances. Par exemple, les modules configurés avec la classe de priorité
system-node-criticalpeuvent être prioritaires. Toutefois, cette classe de priorité garantit la planification. Les pods qui peuvent avoir cette classe de priorité sont par exemple fluentd, des composants complémentaires comme descheduler, etc. Un certain nombre de composants critiques incluent la classe de prioritésystem-cluster-criticalpar défaut, par exemple :- fluentd
- serveur de métrologie
- déscheduler
-
openshift-user-critical - Vous pouvez utiliser le champ
priorityClassNameavec des pods importants qui ne peuvent pas lier leur consommation de ressources et qui n'ont pas de comportement prévisible en matière de consommation de ressources. Les pods Prometheus sous les espaces de nomsopenshift-monitoringetopenshift-user-workload-monitoringutilisent le champopenshift-user-criticalpriorityClassName. Les charges de travail de surveillance utilisentsystem-criticalcomme premierpriorityClass, mais cela pose des problèmes lorsque la surveillance utilise trop de mémoire et que les nœuds ne peuvent pas les expulser. Par conséquent, la surveillance perd sa priorité pour donner de la flexibilité au planificateur, qui déplace les charges de travail lourdes pour maintenir les nœuds critiques en fonctionnement. - cluster-logging - Cette priorité est utilisée par Fluentd pour s'assurer que les pods Fluentd sont programmés sur les nœuds avant les autres applications.
2.10.1.2. Noms de priorité des pods
Une fois que vous avez une ou plusieurs classes de priorité, vous pouvez créer des pods qui spécifient un nom de classe de priorité dans une spécification Pod. Le contrôleur d'admission des priorités utilise le champ du nom de la classe de priorité pour remplir la valeur entière de la priorité. Si la classe de priorité nommée n'est pas trouvée, le pod est rejeté.
2.10.2. Comprendre la préemption des pods
Lorsqu'un développeur crée un module, celui-ci est placé dans une file d'attente. Si le développeur a configuré le module pour une priorité ou une préemption, l'ordonnanceur sélectionne un module dans la file d'attente et tente de le programmer sur un nœud. Si l'ordonnanceur ne trouve pas d'espace sur un nœud approprié qui réponde à toutes les exigences du module, la logique de préemption est déclenchée pour le module en attente.
Lorsque l'ordonnanceur préempte un ou plusieurs pods sur un nœud, le champ nominatedNodeName du spec Pod de priorité supérieure est défini sur le nom du nœud, ainsi que sur le champ nodename. L'ordonnanceur utilise le champ nominatedNodeName 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.
Une fois que l'ordonnanceur a préempté un module de priorité inférieure, il respecte la période de terminaison gracieuse du module. Si un autre nœud devient disponible pendant que l'ordonnanceur attend la fin du pod de priorité inférieure, l'ordonnanceur peut programmer le pod de priorité supérieure sur ce nœud. Par conséquent, les champs nominatedNodeName et nodeName de la spécification Pod peuvent être différents.
De même, si l'ordonnanceur préempte des pods sur un nœud et attend la fin, et qu'un pod ayant une priorité plus élevée que le pod en attente doit être programmé, l'ordonnanceur peut programmer le pod ayant la priorité la plus élevée à la place. Dans ce cas, l'ordonnanceur efface le site nominatedNodeName du pod en attente, rendant le pod éligible pour un autre nœud.
La préemption ne supprime pas nécessairement tous les modules de priorité inférieure d'un nœud. L'ordonnanceur peut programmer un module en attente en supprimant une partie des modules de priorité inférieure.
L'ordonnanceur ne considère un nœud pour la préemption de pods que si le pod en attente peut être programmé sur le nœud.
2.10.2.1. Classes de priorité non prioritaires (Technology Preview)
Les modules dont la politique de préemption est définie sur Never sont placés dans la file d'attente d'ordonnancement avant les modules de priorité inférieure, mais ils ne peuvent pas préempter d'autres modules. Un pod non préempté en attente d'ordonnancement reste dans la file d'attente d'ordonnancement jusqu'à ce que des ressources suffisantes soient disponibles et qu'il puisse être ordonnancé. Les modules non préemptés, comme les autres modules, sont soumis à l'arrêt de l'ordonnanceur. Cela signifie que si l'ordonnanceur tente sans succès de programmer ces modules, ils sont relancés à une fréquence moindre, ce qui permet à d'autres modules moins prioritaires d'être programmés avant eux.
Les pods non préemptés peuvent toujours être préemptés par d'autres pods à priorité élevée.
2.10.2.2. Préemption des pods et autres paramètres de l'ordonnanceur
Si vous activez la priorité et la préemption des pods, tenez compte des autres paramètres de votre ordonnanceur :
- Priorité aux pods et budget de perturbation des pods
- Un budget d'interruption de pod spécifie le nombre ou le pourcentage minimum de répliques qui doivent être opérationnelles à un moment donné. Si vous spécifiez des budgets de perturbation de pods, OpenShift Container Platform les respecte lors de la préemption de pods à un niveau de meilleur effort. L'ordonnanceur tente de préempter des pods sans violer le budget de perturbation des pods. Si aucun pod n'est trouvé, les pods de priorité inférieure peuvent être préemptés malgré leurs exigences en matière de budget de perturbation des pods.
- Priorité et affinité des pods
- L'affinité des pods exige qu'un nouveau pod soit programmé sur le même nœud que d'autres pods ayant la même étiquette.
Si un pod en attente a une affinité inter-pods avec un ou plusieurs pods de priorité inférieure sur un nœud, l'ordonnanceur ne peut pas préempter les pods de priorité inférieure sans violer les exigences d'affinité. Dans ce cas, l'ordonnanceur recherche un autre nœud pour planifier le module en attente. Cependant, il n'est pas garanti que l'ordonnanceur puisse trouver un nœud approprié et le module en attente peut ne pas être programmé.
Pour éviter cette situation, configurez soigneusement l'affinité des pods avec des pods de priorité égale.
2.10.2.3. Fin gracieuse des pods préemptés
Lorsqu'il préempte un module, l'ordonnanceur attend l'expiration de la période de terminaison gracieuse du module, ce qui permet au module de terminer son travail et de quitter le système. Si le module ne se termine pas à l'issue de cette période, l'ordonnanceur tue le module. Ce délai d'expiration crée un décalage entre le moment où l'ordonnanceur préempte le module et le moment où le module en attente peut être programmé sur le nœud.
Pour réduire cet écart, configurez une petite période de terminaison gracieuse pour les pods de moindre priorité.
2.10.3. Configuration de la priorité et de la préemption
Vous appliquez la priorité et la préemption des pods en créant un objet de classe de priorité et en associant les pods à la priorité à l'aide de priorityClassName dans vos spécifications Pod.
Exemple d'objet de classe de priorité
apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority 1 value: 1000000 2 preemptionPolicy: PreemptLowerPriority 3 globalDefault: false 4 description: "This priority class should be used for XYZ service pods only." 5
- 1
- Le nom de l'objet de la classe de priorité.
- 2
- La valeur de priorité de l'objet.
- 3
- Champ facultatif indiquant si cette classe de priorité est préemptable ou non préemptable. La politique de préemption est définie par défaut sur
PreemptLowerPriority, ce qui permet aux pods de cette classe de priorité de préempter les pods de priorité inférieure. Si la politique de préemption est définie surNever, les pods de cette classe de priorité ne sont pas préemptés. - 4
- Champ facultatif indiquant si cette classe de priorité doit être utilisée pour les pods sans nom de classe de priorité spécifié. Ce champ vaut
falsepar défaut. Il ne peut y avoir qu'une seule classe de priorité avecglobalDefaultdéfini surtruedans le cluster. S'il n'y a pas de classe de priorité avecglobalDefault:true, la priorité des modules sans nom de classe de priorité est zéro. L'ajout d'une classe de priorité avecglobalDefault:truen'affecte que les modules créés après l'ajout de la classe de priorité et ne modifie pas les priorités des modules existants. - 5
- Chaîne de texte arbitraire facultative décrivant les pods que les développeurs doivent utiliser avec cette classe de priorité.
Procédure
Pour configurer votre cluster afin d'utiliser la priorité et la préemption :
Créer une ou plusieurs classes de priorité :
- Spécifiez un nom et une valeur pour la priorité.
-
Il est possible de spécifier le champ
globalDefaultdans la classe de priorité et une description.
Créez un spec
Podou modifiez les pods existants pour inclure le nom d'une classe de priorité, comme suit :Exemple de
Podspec avec le nom de la classe de prioritéapiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent priorityClassName: high-priority 1- 1
- Spécifiez la classe de priorité à utiliser avec ce pod.
Créer la capsule :
oc create -f <nom-de-fichier>.yaml
Vous pouvez ajouter le nom de la priorité directement à la configuration du module ou à un modèle de module.
