Dépannage des classes de priorité Kubernetes avec exemples pratiques

Introduction

Les classes de priorité Kubernetes régissent l'ordre dans lequel les pods sont planifiés et quels pods sont évincés lorsqu'un cluster manque de ressources. Lorsque les paramètres de priorité sont mal configurés, les résultats peuvent être subtils : des charges de travail critiques privées de ressources, des pods de priorité inférieure supprimés de manière inattendue, ou la préemption ne fonctionnant pas du tout. Ce guide propose une approche pratique pour résoudre les problèmes liés aux classes de priorité. Nous nous concentrons sur les modèles de défaillance courants, les modifications de configuration sûres, les commandes de vérification et les étapes de récupération. À la fin, vous serez en mesure de diagnostiquer et de corriger les problèmes liés aux priorités en toute confiance.

Nous commençons par recueillir les détails nécessaires de l'environnement, puis nous discutons des chemins de configuration sûrs avant de plonger dans le diagnostic et la récupération. Tout au long, nous incluons des commandes concrètes et les sorties attendues, afin que vous puissiez suivre dans votre propre cluster. N'oubliez pas : un pilote étroit et mesurable est la meilleure façon de valider le comportement de priorité avant de passer à l'échelle.

Inventaire des versions et de l'environnement

Avant de modifier quoi que ce soit, rassemblez des informations sur votre cluster et les classes de priorité actuelles. Cela établit une base de référence et aide à identifier les comportements spécifiques à la version.

Prérequis

• kubectl installé et configuré avec accès au cluster cible.
• Autorisations pour afficher et modifier les objets PriorityClass (généralement cluster-admin).
• La version Kubernetes du cluster (les fonctionnalités de priorité ont évolué au fil des versions).

Récupérer la version du cluster

Exécutez la commande suivante pour vérifier les versions client et serveur :

kubectl version --short

Sortie attendue (exemple) :

Client Version: v1.25.3
Server Version: v1.25.3

Notez la version du serveur. La classe de priorité est stable depuis la v1.14, mais le comportement autour de la préemption et de l'admission de la priorité des pods peut varier légèrement. Par exemple, les versions antérieures à la v1.14 ne prennent pas du tout en charge la classe de priorité. À partir de la v1.24, le drapeau --short est déconseillé, mais la commande fonctionne encore en cas de besoin. Dans les versions plus récentes, utilisez kubectl version sans --short pour des détails complets.

Lister les classes de priorité existantes

kubectl get priorityclass

Exemple de sortie :

NAME                      VALUE        GLOBAL-DEFAULT   AGE
system-cluster-critical   2000000000   false            2d
system-node-critical      2000001000   false            2d
high-priority             1000         false            1h
default                   0            true             2d

La colonne VALUE est la priorité ; les nombres plus élevés signifient une priorité plus élevée. La colonne GLOBAL-DEFAULT indique si cette classe est appliquée aux pods sans priorityClassName.

Inspecter les pods en cours d'exécution et leurs priorités

Vérifiez la priorité actuelle des pods en cours d'exécution dans tous les espaces de noms :

kubectl get pods -A -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,PRIORITY:.spec.priority,PRIORITYCLASS:.spec.priorityClassName,STATUS:.status.phase

Exemple de sortie (tronquée) :

NAMESPACE     NAME                              PRIORITY     PRIORITYCLASS            STATUS
default       nginx-deployment-6d4cf56db-abcde  0            default                  Running
kube-system   coredns-558bd4d5db-xyz12         2000000000   system-cluster-critical  Running

Cela montre quels pods utilisent quelle classe de priorité et leur priorité effective. Si un pod n'a pas de priorityClassName et qu'aucune valeur par défaut globale n'est définie, sa priorité est 0.

Notes de topologie

Le comportement de priorité peut être influencé par la capacité des nœuds, les demandes de ressources et les teintes. Notez le nombre de nœuds et leurs ressources allouables si la préemption est impliquée. Un résumé rapide :

kubectl get nodes -o custom-columns=NAME:.metadata.name,ALLOCATABLE_CPU:.status.allocatable.cpu,ALLOCATABLE_MEMORY:.status.allocatable.memory

Gardez ces informations à portée de main ; vous les référencerez lors de la vérification des décisions de préemption. Par exemple, si un nœud a 2 CPU allouables et que vous essayez de planifier un pod demandant 2 CPU, une préemption peut être nécessaire si d'autres pods occupent cette capacité.

Chemin de configuration sûr

Lors de la modification des classes de priorité, suivez une approche sûre et limitée. Évitez de modifier la valeur par défaut globale ou les classes système sauf en cas de nécessité absolue. Créez plutôt de nouvelles classes ou ajustez celles existantes avec une intention claire.

Comprendre les champs de la classe de priorité

Un objet PriorityClass ressemble à ceci :

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000
globalDefault: false
description: "Utilisé pour les charges de travail utilisateur critiques"

Champs clés :

• value : Priorité entière. Une valeur plus élevée signifie une priorité plus élevée. La plage est généralement de 1 à 1 000 000 000, mais peut être personnalisée via la configuration d'admission.
• globalDefault : Si vrai, les pods sans priorityClassName obtiennent cette priorité. Un seul peut être défaut global.
• description : Explication lisible par l'homme.

Changement sûr : créer ou mettre à jour une classe de priorité non par défaut

Commencez par créer une nouvelle classe de priorité avec une valeur claire au lieu de modifier celles existantes :

cat <<EOF | kubectl apply -f -
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: medium-priority
value: 500
globalDefault: false
description: "Priorité moyenne pour les tâches par lots"
EOF

Sortie attendue :

priorityclass.scheduling.k8s.io/medium-priority created

Application à un pod

Référencez la nouvelle classe dans la spécification d'un pod :

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  priorityClassName: medium-priority
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]
    resources:
      requests:
        memory: "64Mi"
        cpu: "100m"

Appliquez et vérifiez la priorité attribuée :

kubectl apply -f test-pod.yaml
kubectl get pod test-pod -o jsonpath='{.spec.priority}'

Sortie attendue :

500

Modifier une classe de priorité existante

Si vous devez modifier une valeur, sachez que les pods existants conservent la priorité qui leur a été attribuée à l'admission. Seuls les nouveaux pods obtiennent la valeur mise à jour. Par exemple, pour changer medium-priority à 600 :

kubectl patch priorityclass medium-priority -p '{"value":600}'

Ensuite, vérifiez :

kubectl get priorityclass medium-priority -o jsonpath='{.value}'

Sortie :

600

Les pods existants utilisant medium-priority afficheront toujours leur ancienne priorité jusqu'à ce qu'ils soient recréés. Vérifiez avec :

kubectl get pods -l priorityclass=medium-priority -o custom-columns=NAME:.metadata.name,PRIORITY:.spec.priority

Cette caractéristique est souvent source de confusion. Redémarrez toujours les pods pour adopter de nouvelles valeurs de priorité si nécessaire. Pour les déploiements, un redémarrage progressif peut être déclenché par :

kubectl rollout restart deployment <deployment-name> -n <namespace>

Choix d'implémentation limités

• Utilisez des classes de priorité distinctes pour différents niveaux de charge de travail (par exemple, high, medium, low) avec des plages de valeurs claires.
• Évitez de définir globalDefault: true à moins d'avoir une priorité par défaut délibérée pour tous les pods. La priorité par défaut pour les pods sans classe est 0.
• Ne modifiez pas system-cluster-critical ou system-node-critical ; ils sont réservés aux composants système Kubernetes et ont des valeurs très élevées (2 000 000 000 et plus). Les modifier peut compromettre la stabilité du cluster.

Après avoir apporté des modifications, passez à la vérification du comportement.

Vérification et diagnostic

La vérification implique de contrôler l'attribution de la priorité des pods, les événements de préemption et les journaux du planificateur si nécessaire. Nous allons passer en revue les contrôles courants.

Confirmer l'attribution de la priorité des pods

Pour tout pod, vous pouvez vérifier sa priorité et son priorityClassName :

kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.spec.priority} {.spec.priorityClassName}'

Exemple :

500 medium-priority

Si le pod n'affiche aucune priorité, il utilise peut-être la valeur par défaut globale. Vérifiez la classe par défaut globale :

kubectl get priorityclass -o json | jq '.items[] | select(.globalDefault==true) | .metadata.name'

Simuler le comportement de préemption

Pour tester la préemption, créez un pod de haute priorité lorsque le cluster est plein. Tout d'abord, remplissez un nœud avec des pods de faible priorité. Ensuite, soumettez un pod de haute priorité et observez les événements.

Créez une classe de faible priorité (si elle n'existe pas) avec la valeur 0 :

kubectl create priorityclass low-priority --value=0 --global-default=false

Créez plusieurs pods qui demandent suffisamment de CPU pour remplir un nœud. Pour un nœud avec 2 CPU, vous pouvez créer deux pods demandant chacun 1 CPU, ou un pod demandant 2 CPU. Exemple de spécification de pod de faible priorité :

apiVersion: v1
kind: Pod
metadata:
  name: low-pod-1
spec:
  priorityClassName: low-priority
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]
    resources:
      requests:
        cpu: "1000m"

Appliquez plusieurs de ces pods jusqu'à ce que le nœud soit plein. Ensuite, créez un pod de haute priorité qui demande plus de CPU que disponible :

apiVersion: v1
kind: Pod
metadata:
  name: high-priority-pod
spec:
  priorityClassName: high-priority
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]
    resources:
      requests:
        cpu: "1500m"

Remarque : Le pod de haute priorité doit être planifié sur le même nœud. Pour forcer cela, vous pouvez utiliser un sélecteur de nœud ou vous assurer qu'un seul nœud est disponible.

Surveillez les événements :

kubectl get events --sort-by=.lastTimestamp

Recherchez des messages comme Preempted to accommodate higher priority pod. Exemple d'événement :

LAST SEEN   TYPE     REASON      OBJECT              MESSAGE
2m          Normal   Preempted   pod/low-pod-1       Preempted by high-priority-pod on node node-1

Cela confirme que la préemption fonctionne.

Vérifier les décisions du planificateur

Si la préemption ne se produit pas, inspectez les journaux du planificateur. Si vous avez accès au plan de contrôle, vous pouvez rechercher des journaux liés à la priorité :

kubectl logs -n kube-system <scheduler-pod-name> | grep -i priority

Sinon, si vous utilisez un cluster géré (par exemple, EKS, GKE, AKS), vous devrez peut-être vous fier aux événements et à l'état des pods car les journaux du plan de contrôle ne sont pas directement accessibles. Dans ce cas, décrivez le pod en attente et recherchez les messages du planificateur.

Diagnostiquer « Le pod est en attente » avec des problèmes de priorité

Un pod en attente peut ne pas être planifié car aucune préemption n'a eu lieu en raison de certaines conditions. Décrivez le pod :

kubectl describe pod <pod-name> -n <namespace>

Recherchez des événements. Raisons courantes :

• Insufficient cpu sans mention de préemption : Le planificateur peut ne pas préempter si la priorité du pod n'est pas suffisamment élevée par rapport aux pods existants.
• Preemption is not helpful for scheduling : Cela se produit lorsque la priorité du pod est trop faible pour évincer les pods existants.

Assurez-vous que la priorité du pod est effectivement plus élevée que les pods qui seraient évincés. Par exemple, si le pod en attente a une priorité de 1000 et que les pods en cours d'exécution ont une priorité de 2000, aucune préemption ne se produira.

Vérifier que les valeurs de la classe de priorité sont dans la plage

Les valeurs de priorité doivent être dans la plage autorisée par le contrôleur d'admission. Par défaut, la plage valide est de 1 à 1 000 000 000 (1 milliard). Les valeurs supérieures peuvent être rejetées. Vérifiez les événements du pod pour des erreurs telles que :

Error creating: pods "test" is forbidden: spec.priority: Invalid value: 2000000000: must be less than or equal to 1000000000

Si vous avez des configurations d'admission personnalisées, vérifiez la plage autorisée. Par exemple, certains clusters définissent une priorité maximale inférieure à 1 milliard pour éviter des priorités élevées accidentelles.

Vérifier la liaison de la classe de priorité aux pods

Parfois, un pod fait référence à une classe de priorité inexistante. Le pod sera rejeté avec une erreur telle que :

Error from server (Forbidden): error when creating "pod.yaml": pods "test" is forbidden: no PriorityClass with name nonexistent-priority was found

Corrigez en créant la classe ou en corrigeant la spécification du pod.

Pièges courants et comment les éviter

Les mauvaises configurations de la classe de priorité proviennent souvent de quelques erreurs récurrentes. Comprendre ces pièges peut vous faire gagner des heures de débogage.

Piège 1 : Supposer que les changements de priorité s'appliquent aux pods en cours d'exécution

Pourquoi cela arrive : La priorité est attribuée au moment de l'admission du pod. Lorsque vous mettez à jour la valeur d'une classe de priorité, les pods existants ont déjà une priorité numérique définie et ne se mettent pas à jour automatiquement.

Comment éviter : Après avoir modifié une classe de priorité, redémarrez explicitement les pods affectés ou utilisez une mise à jour progressive. Pour les déploiements, utilisez kubectl rollout restart. Pour les pods autonomes, supprimez-les et recréez-les.

Piège 2 : Définir globalDefault sans test

Pourquoi cela arrive : Définir globalDefault: true sur une classe de priorité affecte chaque pod qui ne spécifie pas explicitement un priorityClassName. Cela peut par inadvertance donner une priorité élevée à des pods qui devraient être de faible priorité, provoquant des préemptions inattendues.

Comment éviter : Ne changez jamais la valeur par défaut globale en production sans d'abord tester dans un espace de noms de bac à sable. Préférez créer de nouvelles classes non par défaut et les attribuer explicitement aux pods.

Piège 3 : Mal comprendre les valeurs de priorité

Pourquoi cela arrive : Les valeurs de priorité sont des entiers arbitraires, mais leur magnitude relative compte. Un pod avec une priorité de 1000 ne préemptera pas un pod avec une priorité de 2000. Cependant, le nombre absolu ne transmet pas l'importance ; seule la comparaison compte.

Comment éviter : Définissez une échelle de priorité claire pour votre organisation. Par exemple, utilisez des plages comme 0-999 pour les tâches par lots, 1000-9999 pour les services standard, et 10000+ pour les services critiques. Documentez cette échelle.

Piège 4 : Oublier les demandes de ressources

Pourquoi cela arrive : La préemption nécessite des demandes de ressources pour déterminer si l'éviction de pods de priorité inférieure libérera suffisamment de capacité pour le pod de priorité supérieure. Si le pod en attente n'a pas de demandes de ressources, le planificateur peut ne pas envisager la préemption.

Comment éviter : Définissez toujours des demandes de ressources pour les pods susceptibles d'avoir besoin de préemption. Sans demandes, le planificateur suppose une utilisation de ressources nulle et peut ne pas préempter même si le nœud est réellement plein.

Piège 5 : Modifier les classes de priorité système

Pourquoi cela arrive : Il est tentant d'ajuster system-cluster-critical ou system-node-critical pour influencer la planification, mais celles-ci sont réservées aux composants système. Modifier leurs valeurs peut perturber la stabilité du cluster.

Comment éviter : Ne touchez jamais à ces classes. Créez plutôt vos propres classes de haute priorité avec des valeurs inférieures aux classes système (par exemple, inférieures à 2 000 000 000).

Piège 6 : Ne pas tester la préemption dans un environnement contrôlé

Pourquoi cela arrive : La préemption peut provoquer des évictions inattendues en production si elle n'est pas testée. Une priorité mal configurée peut évincer des charges de travail critiques.

Comment éviter : Testez toujours la préemption dans un espace de noms dédié ou un cluster de test avant de déployer des changements de priorité en production. Simulez la planification de pods de haute priorité et observez quels pods sont évincés.

Modes de défaillance et récupération

Nous couvrons ici les scénarios de défaillance courants et comment récupérer.

1. Valeur de priorité incorrecte

Symptôme : Les pods sont préemptés de manière inattendue ou pas préemptés du tout.

Diagnostic : Vérifiez la priorité du pod et comparez-la avec la classe de priorité prévue. Utilisez kubectl get priorityclass pour voir les valeurs.

Récupération : Mettez à jour la valeur de la classe de priorité. Pour appliquer immédiatement aux pods en cours d'exécution, redémarrez les pods (par exemple, supprimez-les et laissez le contrôleur les recréer). Pour les pods autonomes, vous devez les recréer.

kubectl delete pod <pod-name> -n <namespace>

2. Mauvaise configuration de la valeur par défaut globale

Symptôme : Les nouveaux pods obtiennent une priorité inattendue. Par exemple, chaque pod obtient la priorité 1000 au lieu de 0.

Diagnostic : Vérifiez quelle classe de priorité a globalDefault: true :

kubectl get priorityclass -o json | jq '.items[] | select(.globalDefault==true) | {name: .metadata.name, value: .value}'

Récupération : Définissez globalDefault: false sur cette classe et éventuellement sur une autre. N'oubliez pas qu'une seule peut être la valeur par défaut globale. Si vous désactivez toutes, les pods sans priorité obtiennent la priorité 0 (implicite).

kubectl patch priorityclass <name> -p '{"globalDefault":false}'

3. La préemption ne fonctionne pas comme prévu

Symptôme : Les pods de haute priorité restent en attente même si des pods de faible priorité sont en cours d'exécution.

Causes possibles :

• La priorité du pod de haute priorité n'est pas supérieure aux priorités des pods de faible priorité. Calculez les valeurs.
• La logique de préemption du planificateur peut être désactivée ou limitée par des portes de fonctionnalités. Vérifiez la configuration du planificateur.
• Les demandes de ressources ne sont pas définies sur le pod en attente ; la préemption nécessite des demandes de ressources pour déterminer l'éviction.
• Les sélecteurs de nœuds ou les teintes peuvent limiter la planification.

Récupération : Assurez-vous que le pod en attente a des demandes de ressources appropriées et une priorité suffisamment élevée. Ensuite, vérifiez les événements :

kubectl describe pod <pending-pod>

Recherchez des messages comme Preempting to accommodate higher priority pod. S'il n'y en a pas, examinez les journaux du planificateur (si accessibles).

4. Le pod ne peut pas être créé en raison d'une classe de priorité invalide

Symptôme : La création du pod échoue avec une erreur faisant référence à la classe de priorité.

Récupération : Créez la classe de priorité manquante ou corrigez la spécification du pod. Après la création, le pod sera admis si la priorité est dans la plage.

5. Classe de priorité supprimée alors qu'elle est utilisée

Symptôme : Les pods existants fonctionnent toujours, mais les nouveaux pods référençant cette classe échouent.

Diagnostic : kubectl get priorityclass montre qu'elle est manquante. Les pods avec ce priorityClassName ne pourront pas être créés.

Récupération : Recréez la classe de priorité avec le même nom et une valeur appropriée. Les pods existants conserveront leur priorité attribuée, mais les nouveaux fonctionneront.

Procédures de retour en arrière

Ayez toujours un plan de retour en arrière. Si un changement cause des problèmes, vous pouvez :

• Revenir au manifeste de la classe de priorité à la version précédente en utilisant kubectl apply.
• Supprimer la classe de priorité (si elle a été nouvellement ajoutée) et mettre à jour les pods pour supprimer la référence.
• Pour globalDefault, restaurer le paramètre précédent.

Documentez les changements à l'avance pour faciliter un retour en arrière rapide.

Liste de contrôle opérationnelle avec responsabilités et fréquence de révision

Utilisez cette liste de contrôle comme procédure reproductible lors de la gestion des classes de priorité. Chaque étape inclut un rôle responsable et une fréquence de révision.

Rappels supplémentaires :

• Évitez de modifier les classes de priorité système.
• Gardez les valeurs de priorité dans la plage autorisée.
• Utilisez des noms et des champs de description descriptifs.
• Testez avant d'appliquer en production.

Conclusion

Le dépannage des classes de priorité nécessite une vérification méthodique et des modifications prudentes. En suivant ce guide, vous pouvez diagnostiquer les problèmes courants tels que les priorités incorrectes, les échecs de préemption et les valeurs par défaut globales mal configurées. Commencez par un pilote étroit, vérifiez le comportement avec des commandes concrètes et planifiez toujours un retour en arrière. Avec la liste de contrôle et les étapes de récupération, vous pouvez maintenir une planification fiable des pods et une préemption des ressources dans vos clusters Kubernetes.

Prochaines étapes vérifiées :

• Inventoriez vos classes de priorité actuelles et les affectations de pods.
• Implémentez une nouvelle classe de priorité non par défaut pour une charge de travail de test.
• Testez le comportement de préemption dans un espace de noms sûr.
• Surveillez les événements et les journaux du planificateur pour tout comportement inattendu.
• Déployez progressivement les paramètres de priorité vers les charges de travail de production avec des plans de retour en arrière clairs.

En institutionnalisant ces pratiques, vous transformez la gestion des classes de priorité en une routine opérationnelle reproductible.