Classes de Qualité de Service (QoS) : Guaranteed, Burstable, BestEffort

Prioriser les Pods : l'objectif des classes de QoS

Maintenant que nous savons comment définir les requêtes (requests) et les limites (limits) pour le CPU et la mémoire de nos conteneurs, il est temps de comprendre comment Kubernetes utilise ces informations pour classifier les Pods et gérer leur priorité, notamment en situation de contention des ressources sur un noeud. C'est le rôle des Classes de Qualité de Service (QoS Classes).

Kubernetes attribue automatiquement l'une des trois classes de QoS suivantes à chaque Pod : Guaranteed, Burstable, ou BestEffort. Cette classification influence principalement deux aspects :

1. La probabilité d'éviction en cas de pression sur les ressources du noeud : Surtout en cas de manque de mémoire (OOM - Out Of Memory), Kubernetes doit décider quels Pods terminer pour libérer des ressources. La classe QoS est un facteur déterminant dans cet ordre d'éviction.
2. Les garanties de performance (implicites) : Bien que principalement liée à l'éviction, la classe QoS reflète aussi le niveau de garantie de ressources que le Pod peut espérer.

Il est crucial de noter que la classe QoS est déterminée au niveau du Pod entier, en se basant sur les `requests` et `limits` définis pour tous les conteneurs qu'il contient.

La classe `Guaranteed` : priorité et prévisibilité maximales

Un Pod se voit attribuer la classe QoS Guaranteed si et seulement si tous les critères suivants sont remplis pour chaque conteneur du Pod :

• Une limite de mémoire (limits.memory) est définie.
• Une requête de mémoire (requests.memory) est définie, et elle est égale à la limite de mémoire.
• Une limite de CPU (limits.cpu) est définie.
• Une requête de CPU (requests.cpu) est définie, et elle est égale à la limite de CPU.

En substance, pour être Guaranteed, chaque conteneur doit explicitement demander une quantité fixe de CPU et de mémoire, et accepter de ne jamais dépasser cette quantité.

Comportement :

• Ces Pods ont la plus haute priorité.
• Ils sont les moins susceptibles d'être terminés par le système en cas de pénurie de ressources sur le noeud. Ils ne seront tués que si les ressources système critiques sont menacées et qu'il n'y a plus de Pods Burstable ou BestEffort à tuer, ou s'ils dépassent eux-mêmes leur propre limite mémoire (ce qui ne devrait pas arriver avec une application bien conçue et des limites correctes).
• Ils ont une garantie ferme sur les ressources définies par leurs `requests` (qui sont égales à leurs `limits`).

Cas d'usage : Idéal pour les charges de travail critiques qui nécessitent une performance stable et prévisible et pour lesquelles l'éviction serait très problématique (ex: bases de données, serveurs d'API critiques, composants du control plane).

La classe `BestEffort` : aucune garantie, priorité minimale

Un Pod se voit attribuer la classe QoS BestEffort si aucun conteneur dans le Pod n'a de requêtes ou de limites définies pour le CPU ou la mémoire.

Comportement :

• Ces Pods ont la plus basse priorité.
• Ils sont les premiers à être terminés par le système en cas de pénurie de ressources (OOMKill) sur le noeud.
• Ils n'ont aucune garantie de ressources CPU ou mémoire. Ils peuvent utiliser les ressources non réclamées par les Pods Guaranteed ou Burstable, mais ces ressources peuvent leur être retirées à tout moment.
• Le Scheduler les place sans tenir compte d'une quelconque demande de ressources, ce qui peut mener à une sur-allocation si de nombreux Pods BestEffort sont placés sur le même noeud.

Cas d'usage : Tâches non critiques, processus batch qui peuvent être redémarrés sans impact majeur, expérimentations, certains outils de développement/test. A éviter absolument pour les applications de production importantes.

La classe `Burstable` : le compromis flexible

Un Pod se voit attribuer la classe QoS Burstable s'il ne remplit ni les conditions pour Guaranteed ni celles pour BestEffort. Concrètement, cela signifie qu'au moins un conteneur dans le Pod a une requête ou une limite de CPU ou de mémoire définie, mais que les conditions strictes de Guaranteed ne sont pas satisfaites pour tous les conteneurs.

Les scénarios courants menant à Burstable incluent :

• Au moins un conteneur a des `requests` mais pas de `limits`.
• Au moins un conteneur a des `limits` mais pas de `requests`.
• Au moins un conteneur a des `requests` et des `limits`, mais `requests.memory` est différent de `limits.memory`, OU `requests.cpu` est différent de `limits.cpu`.
• Les conteneurs du Pod ont des configurations de `requests`/`limits` hétérogènes (certains ont des définitions, d'autres non, ou les égalités request=limit ne sont pas valides pour tous).

Comportement :

• Ces Pods ont une priorité intermédiaire.
• Ils sont protégés contre l'éviction tant qu'il y a des Pods BestEffort sur le noeud et qu'ils ne dépassent pas leurs propres limites (s'ils en ont).
• Ils ont une garantie sur les ressources spécifiées par leurs `requests`.
• Ils peuvent consommer plus de ressources, jusqu'à leurs `limits` (si définies) ou jusqu'à la capacité disponible du noeud (si les `limits` ne sont pas définies), lorsque les ressources ne sont pas utilisées par les Pods Guaranteed. C'est la capacité de 'burst'.
• En cas de pénurie mémoire, ils sont tués avant les Pods Guaranteed mais après les Pods BestEffort. L'ordre d'éviction parmi les Pods Burstable dépend de leur consommation mémoire par rapport à leurs requests.

Cas d'usage : La plupart des applications standards. Offre un bon équilibre entre garanties de ressources et flexibilité pour utiliser les ressources inutilisées, tout en offrant une protection relative contre l'éviction.

Vérifier la classe QoS d'un Pod

Vous pouvez facilement vérifier la classe QoS assignée à un Pod en utilisant `kubectl describe` :

kubectl describe pod  -n 

Dans la sortie, recherchez le champ `QoS Class`. Par exemple :

... # Autres informations
Status:       Running
IP:           192.168.1.15
IPs:
  IP:           192.168.1.15
Controlled By:  ReplicaSet/my-app-rs-12345
Containers:
  # ... détails des conteneurs ...
QoS Class:                  Burstable # Ou Guaranteed, ou BestEffort
Node-Selectors:             
Tolerations:                node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                            node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  # ... événements ...

En conclusion, comprendre et utiliser consciemment les classes de QoS en définissant judicieusement les `requests` et `limits` est une pratique essentielle pour construire des clusters Kubernetes stables, performants et résilients. Elle vous permet d'exprimer la criticité de vos applications et d'influencer la manière dont Kubernetes gère les ressources en situation de stress.