PriorityClass

Kubernetes PriorityClass

Les PriorityClass sont des objets API de niveau cluster qui définissent une hiérarchie d’importance pour les Pods. Ils influencent directement deux mécanismes critiques du cycle de vie d’un Pod : l’ordonnancement (Scheduling) et l’éviction (Preemption).

1. Concepts Fondamentaux

• Value : Un entier 32 bits (jusqu’à 1 milliard). Plus le nombre est élevé, plus la priorité est importante. Les valeurs supérieures à 1 milliard sont réservées aux composants système critiques (ex: system-cluster-critical).
• PreemptionPolicy :
  • PreemptLowerPriority (défaut) : Permet d’évincer des Pods moins prioritaires.
  • Never : Le Pod attendra s’il n’y a pas de place, sans chasser personne.
• GlobalDefault : Si mis à true, cette priorité s’applique à tout Pod n’ayant pas de priorityClassName spécifié. (Un seul objet peut être par défaut dans le cluster).

2. Fonctionnement technique

A. Scheduling (Ordonnancement)

Le kube-scheduler maintient une file d’attente (scheduling queue). Les Pods sont triés par priorité. Un Pod avec une PriorityClass élevée passera devant les autres pour être traité en premier.

B. Preemption (Éviction)

Si un Pod à haute priorité ne peut pas être placé par manque de ressources (CPU/RAM), le scheduler tente d’évincer (supprimer) des Pods ayant une priorité plus faible sur un nœud pour libérer de l’espace.

3. Exemple de Manifeste YAML

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority-apps
value: 1000000
globalDefault: false
preemptionPolicy: PreemptLowerPriority
description: "Priorité pour les microservices critiques de production."

4. Utilisation dans un Pod:

spec:
  priorityClassName: high-priority-apps
  containers:
  - name: my-app
    image: nginx

5. Objets d’affectation

L’affectation de la priorité ne se fait pas directement sur la PriorityClass elle-même, mais en y faisant référence dans les ressources suivantes :

A. Le Pod (Niveau de base)

C’est l’objet principal. On utilise le champ spec.priorityClassName. Tous les autres objets (Deployment, StatefulSet, etc.) ne font que transmettre cette configuration au template du Pod.

B. Contrôleurs de ressources (Indirect)

Pour que vos applications bénéficient de la priorité, vous l’ajoutez dans le template des objets suivants :

• Deployments & ReplicaSets : Pour les applications stateless.
• StatefulSets : Pour les bases de données ou applications avec état.
• DaemonSets : Pour s’assurer que les agents (logs, monitoring) ne soient pas évincés par des apps moins critiques.
• Jobs & CronJobs : Pour prioriser des tâches de traitement de données.

C. ResourceQuota (Limitation)

Il est possible de limiter la consommation de ressources par niveau de priorité au sein d’un Namespace.

• On peut créer un ResourceQuota qui restreint par exemple le nombre de Pods pouvant utiliser la priorityClassName: high-priority.

6. Bonnes pratiques

• Ne pas abuser du GlobalDefault : Cela peut rendre l’éviction imprévisible si tous les Pods deviennent “hautement prioritaires” par défaut.
• Éviction critique : Réservez les plus hautes valeurs aux composants d’infrastructure (DNS, Ingress Controller) pour éviter que le cluster ne devienne instable lors d’une saturation de ressources.