Migration obligatoire de Kubernetes vers cgroup v2 : bien au-delà d'un paramètre noyau

L'adoption stricte de cgroup v2 dans les versions récentes de Kubernetes, notamment avec l'activation par défaut de failCgroupV1=true dans kubeadm, rend cette migration incontournable. L'erreur classique des équipes d'infrastructure est d'envisager cette bascule comme une simple ligne ajoutée à GRUB, alors qu'elle modifie en profondeur la gestion de la mémoire, les runtimes de conteneurs et les politiques d'éviction OOMKilled.

Les limites de l'architecture cgroup v1

Sous v1, chaque contrôleur de ressource fonctionnait dans une hiérarchie arborescente indépendante. Lorsqu'un conteneur accumulait un cache de pages disque volumineux, le contrôleur de mémoire ne pouvait pas coordonner la limitation d'écriture avec le contrôleur d'E/S, entraînant des blocages imprévisibles et des déclenchements erratiques de l'OOM killer.

cgroup v2 impose une hiérarchie unifiée où chaque processus dépend d'un groupe unique pour l'ensemble de ses allocations.

L'apport décisif des métriques PSI

L'intérêt opérationnel majeur réside dans les indicateurs PSI (Pressure Stall Information). Contrairement aux pourcentages d'occupation bruts, le PSI quantifie la fraction de temps réelle durant laquelle les applications restent bloquées en attente de libération de mémoire ou d'E/S disque.

Bonnes pratiques de déploiement

1. Vérification du système de fichiers avec stat -fc %T /sys/fs/cgroup/.
2. Activation obligatoire de SystemdCgroup = true dans containerd.
3. Audit des anciennes versions Java pour prévenir les erreurs d'évaluation de la mémoire maximale allouée.

Cette mise à niveau garantit une stabilité accrue pour les clusters de production exigeants.