La stabilité DRA oblige à repenser les charges GPU
&8211; Kubernetes 1.36 « Haru&8220; est disponible depuis le 22 avril 2026 et apporte deux changements qui nécessitent une action immédiate pour les clusters d&8217;entreprise DACH : cgroup v1 n&8217;est pas déprécié …
6 min de lecture
Kubernetes 1.36 « Haru“ est disponible depuis le 22 avril 2026 et apporte deux changements qui nécessitent une action immédiate pour les clusters d’entreprise DACH : cgroup v1 n’est pas déprécié mais complètement supprimé – Dynamic Resource Allocation pour les charges de travail GPU est maintenant stable. Ceux qui utilisent encore cgroup v1 ne pourront pas effectuer de mise à jour après cette version sans migrer au préalable.
Les points clés en bref
- Kubernetes 1.36 « Haru“ disponible depuis le 22 avril 2026 : cgroup v1 complètement supprimé, pas de retour possible après la mise à jour
- cgroup v2 obligatoire : tous les nœuds doivent être migrés vers cgroup v2 avant la mise à jour – RHEL 9+, Ubuntu 22.04+ et SLES 15 SP5+ l’ont activé par défaut
- Dynamic Resource Allocation (DRA) stable : planification structurée des GPU/FPGA sans contournements de Device-Plugin est maintenant prête pour la production
- Job API : contrôle de la parallélisme successif stable – Gestion Max-in-flight pour les charges de travail batch considérablement améliorée
- Recommandation : ne lever le gel des mises à jour qu’après validation de cgroup-v2 sur tous les nœuds de travail de tous les clusters
Connexe : S3 Files vs. EFS vs. FSx : Comparatif des services de systèmes de fichiers AWS 2026
Qu’est-ce que cgroup v2 ? Control Groups Version 2 (cgroup v2) est le mécanisme du noyau Linux pour le contrôle des ressources des processus et des conteneurs. Contrairement à cgroup v1, cgroup v2 fonctionne avec une hiérarchie unifiée au lieu de plusieurs hiérarchies de sous-systèmes parallèles – cela simplifie la comptabilité des ressources et permet un contrôle plus précis de la gestion de la mémoire OOM, du signalement de la pression et du contrôle de la latence des E/S pour les charges de travail des conteneurs.
cgroup v1 est supprimé – pas déprécié, mais retiré
La différence principale avec les annonces précédentes : le projet Kubernetes n’a pas mis cgroup v1 en statut déprécié, mais l’a directement retiré. Il n’y a plus de « période de grâce de dépréciation » pour la version 1.36. Ceux qui mettent à jour sans migrer tous les nœuds vers cgroup v2 échoueront lors de la mise à jour.
Concrètement : kubelet et le runtime des conteneurs (containerd, CRI-O) attendent sur chaque nœud cgroup v2 comme fonctionnalité active du noyau. Sur les nœuds fonctionnant encore en mode cgroup v1, kubelet ne démarrera plus après la mise à jour. Cela concerne particulièrement les organisations qui utilisent encore des nœuds RHEL 8 ou Ubuntu 20.04 plus anciens – les deux systèmes utilisent cgroup v1 par défaut.
Statut de migration par distribution
| Distribution | cgroup v2 par défaut à partir de | Action requise |
|---|---|---|
| RHEL 9 / Rocky 9 / Alma 9 | dès la sortie (2022) | Aucune – déjà cgroup v2 |
| RHEL 8 / CentOS 8 | Pas par défaut | Mise à jour du système vers RHEL 9 ou activation manuelle |
| Ubuntu 22.04 LTS | dès la sortie (2022) | Aucune – déjà cgroup v2 |
| Ubuntu 20.04 LTS | Pas par défaut | Définir les paramètres du noyau systemd ou mettre à jour vers 22.04 |
| SLES 15 SP5+ | à partir de SP5 | Aucune à partir de SP5 – vérifier les SP plus anciens |
Allocation dynamique de ressources (DRA) stable : Ce que cela signifie pour les workloads GPU
L’allocation dynamique de ressources est passée de la version bêta à stable dans la version 1.36. DRA résout un problème fondamental lié aux workloads GPU et accélérateurs : les plugins de périphériques comme le plugin de périphérique NVIDIA ont jusqu’à présent mis en œuvre une attribution statique 1:1 des emplacements GPU aux pods. Plusieurs pods ne pouvaient pas partager un GPU de manière structurée. Avec DRA, les administrateurs de cluster peuvent diviser les ressources GPU de manière granulaire via les ResourceClasses et les ResourceClaims – une tranche de GPU pour un pod d’inférence, une autre pour un travail d’entraînement.
Avantages de DRA pour l’entreprise
- Partage de GPU sans exigences de matériel NVIDIA MIG
- Les ResourceClaims sont namespaced – compatibles multi-locataires
- Meilleure utilisation du matériel d’accélération coûteux
- Configuration déclarative au lieu de hacks de plugins de périphériques
La migration nécessite
- Les plugins de périphériques existants doivent être migrés vers l’API DRA
- Plugin de périphérique NVIDIA v0.17+ requis pour la compatibilité DRA
- Le scheduler et le kubelet doivent avoir la fonctionnalité DRA activée
- Aucun chemin de migration automatique pour les anciens déploiements de plugins de périphériques
Ce que les équipes d’entreprise dans la région DACH doivent vérifier maintenant
Liste de contrôle de mise à niveau Kubernetes 1.36
- Vérifiez tous les nœuds de travail sur cgroup v2 : stat -fc %T /sys/fs/cgroup/ doit renvoyer cgroup2fs
- Vérifiez la version de la runtime de conteneur : containerd 1.7+ et CRI-O 1.28+ prennent en charge cgroup v2 de manière native
- Vérifiez le cluster géré : EKS, GKE et AKS migrent automatiquement les nœuds lors de la mise à niveau de la version de Kubernetes
- Cluster autogéré : faites pivoter ou migrez manuellement tous les nœuds avant la mise à niveau
- Vérifiez la version du plugin de périphérique NVIDIA si des workloads GPU sont utilisés
Source des faits : Blog Kubernetes, Notes de version Kubernetes 1.36, CNCF TAG-Runtime, Blog NVIDIA avril 2026.
- SecurityToday : Ivanti EPMM Zero-Days – Ce que les opérateurs KRITIS doivent faire maintenant
- Digital Chiefs : Gouvernance Smart City 2026 – Enseignements pour les CIO tirés du retard des villes allemandes
- MyBusinessFuture : Clean Industrial Deal – Ce que les entreprises de production doivent mettre en œuvre à partir de 2027
Foire aux questions
Puis-je encore activer cgroup v1 sous Kubernetes 1.36 ?
Non. Avec Kubernetes 1.36, le code cgroup v1 est complètement supprimé de kubelet et des bibliothèques internes de Kubernetes. Il n’y a pas de Feature-Gate qui réactiverait cgroup v1. Ceux qui restent sur la version 1.35 ou antérieure peuvent continuer à utiliser cgroup v1, mais une mise à niveau vers 1.36+ nécessite impérativement cgroup v2 sur tous les nœuds.
Comment puis-je vérifier si mes nœuds utilisent déjà cgroup v2 ?
Sur chaque nœud : stat -fc %T /sys/fs/cgroup/. Si cela renvoie cgroup2fs, cela signifie que cgroup v2 est actif. Si cela renvoie tmpfs, cela signifie que cgroup v1 est encore utilisé. Autre méthode : cat /proc/1/cgroup – si toutes les entrées sont fusionnées en une seule ligne avec 0::/, le système utilise cgroup v2 unified.
La suppression de cgroup v1 concerne-t-elle également Kubernetes géré sur AWS/GCP/Azure ?
Avec EKS, GKE et AKS, la migration des nœuds vers cgroup v2 est effectuée automatiquement par le fournisseur cloud lors de la mise à niveau de la version de Kubernetes – les nouveaux pools de nœuds ou groupes de nœuds gérés sont mis à jour vers des images de base compatibles cgroup v2. Les problèmes concernent les groupes de nœuds autogérés ou les pools d’instances Spot avec des AMIs personnalisées qui fonctionnent encore sous Ubuntu 20.04 ou Amazon Linux 2 (sans configuration cgroup v2).
Quand devrais-je commencer la mise à niveau vers 1.36 ?
Uniquement après avoir validé complètement cgroup v2 sur tous les nœuds de travail dans le cluster. Le chemin recommandé : mettre à niveau le cluster de préproduction, observer tous les workloads pendant 2 semaines, puis effectuer une mise à niveau progressive des clusters de production nœud par nœud. Sur les clusters gérés avec mise à niveau automatique : ouvrir la fenêtre de mise à niveau automatique uniquement après avoir validé la compatibilité des nœuds.
Qu’est-ce qui change pour les équipes qui exécutent des workloads GPU avec le plugin de périphérique NVIDIA ?
Le plugin de périphérique NVIDIA classique continue de fonctionner dans Kubernetes 1.36 – il utilise l’API de plugin de périphérique, pas DRA. Ceux qui souhaitent migrer de Device-Plugin vers DRA ont besoin de NVIDIA-Device-Plugin v0.17+ et doivent redéfinir les ResourceClasses et les ResourceClaims pour leurs workloads GPU. La migration est facultative mais recommandée pour les clusters GPU multi-locataires qui doivent partager le matériel d’accélération.
Source de la une : Pexels | Base factuelle : Blog Kubernetes, CNCF, Blog des développeurs NVIDIA
