Kubernetes v1.35 impose la migration vers cgroup v2 pour les nœuds Linux

Le projet Kubernetes a placé la prise en charge de cgroup v1 en mode maintenance, signalant un basculement définitif vers l'interface unifiée de gestion des ressources de cgroup v2. À partir de Kubernetes v1.35, le kubelet refusera de démarrer sur les nœuds utilisant encore cgroup v1, sauf si les administrateurs désactivent explicitement ce comportement. Cette modification concerne tous les clusters basés sur Linux, obligeant les opérateurs à vérifier leurs versions de noyau, leurs environnements d'exécution de conteneurs et leurs configurations de nœuds avant toute mise à niveau.

Ce qui s'est passé

Les groupes de contrôle, ou cgroups, sont une fonctionnalité du noyau Linux permettant au système d'exploitation d'allouer des ressources telles que le CPU et la mémoire à des processus spécifiques. Kubernetes s'appuie sur ce mécanisme pour garantir que les conteneurs n'interfèrent pas entre eux. Bien que cgroup v2 soit stable dans Kubernetes depuis la version 1.25, la prise en charge de l'ancienne interface v1 est désormais progressivement supprimée. Dans Kubernetes v1.35, le paramètre de configuration failCgroupV1 est défini par défaut sur true. Cela signifie que si un nœud utilise cgroup v1, le processus kubelet échouera lors du démarrage, rendant ainsi le nœud hors service.

Les administrateurs qui ne sont pas encore prêts à migrer peuvent temporairement définir failCgroupV1: false dans leur fichier de configuration kubelet. Cependant, il ne s'agit que d'une mesure provisoire. La politique de dépréciation de Kubernetes indique que la suppression complète de la prise en charge de cgroup v1 est imminente, comme suivi dans KEP-5573. Pour les clusters gérés par kubeadm, l'application est encore plus stricte. Le contrôle préliminaire SystemVerification, faisant partie de l'outil k8s.io/system-validators, renvoie désormais une erreur lors de l'initialisation, de la jonction ou de la mise à niveau s'il détecte cgroup v1 sur un nœud exécutant kubelet v1.35 ou ultérieur. Auparavant, cela ne générait qu'un avertissement.

Cette transition ne relève pas seulement de la conformité ; elle débloque des capacités modernes de gestion des ressources. Cgroup v2 offre une hiérarchie unique et unifiée, simplifiant l'interface par rapport aux multiples hiérarchies de v1. Il fournit une isolation plus forte et prend en charge de nouvelles fonctionnalités telles que Pressure Stall Information (PSI) et une qualité de service (QoS) mémoire améliorée. Les clusters restant sur v1 passent à côté de ces optimisations et font face à des problèmes de compatibilité croissants avec les nouveaux environnements d'exécution de conteneurs et outils de surveillance.

Comment cela fonctionne

Cgroup v2 remplace la structure complexe à hiérarchies multiples de v1 par un arbre unique où tous les contrôleurs (CPU, mémoire, E/S) sont attachés. Cette unification permet une comptabilité des ressources plus cohérente et empêche les scénarios où un processus est limité par un contrôleur mais pas par un autre en raison d'incohérences de hiérarchie. Dans Kubernetes, le kubelet interagit avec ces contrôleurs pour appliquer les limites définies dans les spécifications des Pods. Avec v2, le kubelet peut utiliser des fonctionnalités comme memory.high pour le throttling et memory.min pour la protection dure, ce qui n'était pas possible ou fiable avec v1.

La migration modifie également la gestion des événements de dépassement de mémoire (OOM). Dans cgroup v2, le kubelet définit memory.oom.group pour chaque cgroup de conteneur. Lorsqu'un événement OOM se produit, le noyau tue tous les processus de ce conteneur simultanément, plutôt que de les éliminer un par un. Cela empêche les conteneurs partiellement fonctionnels de rester dans un état corrompu. De plus, cgroup v2 permet la délégation, autorisant les conteneurs sans privilèges root à gérer leurs propres cgroups en toute sécurité via systemd, une capacité qui était risquée ou impossible avec v1.

Détails clés

• Application par défaut : Dans Kubernetes v1.35, failCgroupV1 est défini par défaut sur true, provoquant l'échec du démarrage du kubelet sur les nœuds cgroup v1.
• Exigences du noyau : Une version du noyau Linux 5.8 ou ultérieure est requise pour la prise en charge de cgroup v2, avec 5.9+ recommandé pour la stabilité de la QoS mémoire.
• Prise en charge de l'environnement d'exécution : Containerd v1.4+ et CRI-O v1.20+ prennent en charge cgroup v2 ; la découverte automatique du pilote nécessite containerd v2.0+ ou CRI-O v1.28+.
• QoS mémoire : La fonctionnalité alpha Memory QoS, qui utilise memory.high et memory.low, est exclusivement disponible sur les nœuds cgroup v2.
• Mises à jour des outils : Les outils de surveillance doivent être mis à jour ; cAdvisor v0.43.0+ est recommandé, ainsi que des versions compatibles des bibliothèques Java et Node.js.
• Conversion du poids CPU : Les environnements d'exécution OCI plus récents comme crun v1.23 et runc v1.3.2 utilisent une conversion non linéaire de cpu.shares (v1) vers cpu.weight (v2), améliorant la granularité pour les petites demandes de CPU.

Pourquoi c'est important

Pour les ingénieurs logiciels et les équipes de plateforme, ce changement signifie que les configurations d'infrastructure héritées ne sont plus viables. Si vous mettez à niveau votre plan de contrôle vers v1.35 sans migrer vos nœuds de travail, votre cluster sera cassé. Les nœuds ne pourront pas rejoindre le cluster, et les nœuds existants pourraient ne pas redémarrer après un reboot. Cela crée une dépendance stricte vis-à-vis des mises à jour du système d'exploitation, car de nombreuses anciennes distributions Linux utilisent cgroup v1 par défaut. Les équipes doivent désormais coordonner les mises à niveau du noyau à travers leur parc de machines, ce qui peut représenter un obstacle opérationnel majeur dans les environnements hétérogènes de grande taille.

Au-delà de la douleur immédiate de la migration, rester sur v2 débloque une meilleure efficacité des ressources. Des fonctionnalités comme PSI offrent une visibilité en temps réel sur la contention des ressources, permettant des décisions d'autoscaling plus précises. La gestion améliorée des OOM garantit que les défaillances d'application sont plus propres et plus faciles à déboguer. De plus, à mesure que la mise à l'échelle verticale in-place devient stable, cgroup v2 est requis pour une application agrégée précise. Ignorer ce chemin de migration finira par laisser les clusters incapables d'adopter ces améliorations de performance et de fiabilité.

Ce que vous pouvez faire

• Vérifier l'état actuel : Exécutez stat -fc %T /sys/fs/cgroup/ sur vos nœuds. Si cela retourne cgroup2fs, vous êtes déjà sur v2.
• Vérifier la version du noyau : Assurez-vous que tous les nœuds Linux exécutent le noyau 5.8 ou ultérieur. Mettez à niveau le système d'exploitation si nécessaire avant de tenter la mise à niveau de Kubernetes.
• Mettre à jour l'environnement d'exécution de conteneurs : Confirmez que vous utilisez containerd v1.4+ ou CRI-O v1.20+. Idéalement, passez à containerd v2.0+ pour tirer parti de la découverte automatique du pilote cgroup.
• Configurer Kubelet : Si vous ne pouvez pas migrer immédiatement, définissez failCgroupV1: false dans votre configuration kubelet, mais prévoyez de supprimer cette dérogation rapidement. Faites correspondre le pilote cgroup à votre environnement d'exécution, en préférant l'utilisation de systemd.
• Mettre à jour la pile de surveillance : Mettez à niveau cAdvisor vers v0.43.0 ou ultérieur et vérifiez que vos scrapeurs Prometheus et autres outils de surveillance prennent en charge les métriques cgroup v2.
• Tester la QoS mémoire : Si vous utilisez une gestion avancée des ressources, testez les fonctionnalités alpha Memory QoS dans un environnement de staging pour comprendre comment le throttling memory.high affecte vos charges de travail.