8 min de lecture
Kubernetes 1.36 est passé en disponibilité générale (GA) le 22 avril 2026. Deux changements sont au cœur de cette version : la suppression définitive du support cgroup-v1 et la disponibilité générale de l’allocation dynamique des ressources (DRA). Pour les équipes Ops en entreprise, cela se traduit par des tâches concrètes à réaliser dans les 60 prochains jours – avant que le support upstream et les correctifs de sécurité pour les anciennes versions de cluster n’expirent. Voici une checklist de migration sans surcharge théorique.
Les points clés en bref
- Kubernetes 1.36 GA le 22/04/2026 : suppression du support cgroup-v1, DRA devient disponible généralement
- Ceux qui fonctionnent encore sur cgroup-v1 (identifiable par –cgroup-driver=cgroupfs) doivent migrer vers containerd + cgroup-v2 avant la mise à niveau
- DRA-GA : l’installation des pilotes de ressources et les CRD NodeFeature sont désormais obligatoires pour les charges de travail GPU/FPGA
- Prérequis minimum containerd : 1.7.x pour le support 1.36, 2.0 recommandé
- Fenêtre de temps : Kubernetes 1.33 fin de vie en octobre 2026 – ceux qui sont encore sur 1.33 doivent mettre à niveau maintenant
Articles liésEdge Computing 2026 : ThinkEdge SE60n Gen 2 en test pratique / FinOps 2026 : Maîtriser les coûts cloud en entreprise
Qu’est-ce que Kubernetes 1.36 et pourquoi cette version est-elle critique pour la migration ?
Qu’est-ce que Kubernetes 1.36 ? Kubernetes 1.36 est la version publiée le 22 avril 2026 du système open source d’orchestration de conteneurs, marquant la suppression définitive du support cgroup-v1 ainsi que la disponibilité générale de l’allocation dynamique des ressources (DRA) pour les ressources matérielles telles que les GPU et les FPGA.
Kubernetes 1.36 est la première version à supprimer complètement cgroup-v1. cgroup v1 (Control Groups version 1) était l’interface classique du noyau Linux pour l’isolation des ressources – limites de RAM, quotas CPU, hiérarchies de processus. Depuis Kubernetes 1.25, cgroup-v2 était la voie standard. Avec la version 1.36, cgroup-v1 n’est plus simplement déprécié de manière optionnelle, il a disparu.
Cela signifie : quiconque exploite encore un nœud avec le pilote cgroupfs sous cgroup-v1 ne pourra plus démarrer après une mise à niveau vers 1.36. Le Kubelet renverra une erreur lors de la vérification d’initialisation. Il ne s’agit pas d’une transition douce – c’est un arrêt brutal.
Chiffres clés de la migration
23%
des clusters d’entreprise fonctionnaient encore sur cgroup-v1 ou avaient un statut incertain selon l’enquête CNCF T1 2026
Oct 2026
K8s 1.33 Fin de vie – ceux qui sont encore sur 1.33 ont 5 mois
containerd 2.0
Version recommandée pour K8s 1.36 – 1.7.x est le minimum, 2.0 est la voie supportée
Étape 1 : Vérifier l’état du cluster (version cgroup et containerd)
Avant que quiconque ne procède à une mise à niveau, chaque nœud doit faire un inventaire. Deux vérifications, toutes deux réalisables à distance via kubectl :
Version de cgroup par nœud :
xargs -I{} kubectl describe node {} | grep « Container Runtime »
# Ou directement sur le nœud :
stat -fc %T /sys/fs/cgroup
# Sortie « tmpfs » = cgroup-v1, « cgroup2fs » = cgroup-v2
Version et configuration de containerd :
# Min : 1.7.x | Recommandé : 2.0.x
# Vérifier le pilote cgroup de containerd :
grep -i cgroup /etc/containerd/config.toml
# Doit afficher « SystemdCgroup = true » (cgroup-v2)
Celui qui voit SystemdCgroup = false ou aucune entrée fonctionne encore en mode cgroupfs. C’est le principal obstacle à la mise à niveau vers la version 1.36.
Étape 2 : Migration vers cgroup-v2 au niveau des nœuds
La migration des nœuds de cgroup-v1 vers cgroup-v2 nécessite un changement de paramètre du noyau et un cycle de redémarrage avec vidage du nœud (drain). Aucune mise à niveau progressive (rolling upgrade) n’est possible ; chaque nœud doit être vidé.
1. Ajuster les paramètres de démarrage du noyau (GRUB ou systemd-boot selon le système d’exploitation) :
GRUB_CMDLINE_LINUX= »systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all »
update-grub && reboot
2. Mettre à jour la configuration de containerd :
[plugins. »io.containerd.grpc.v1.cri ».containerd.runtimes.runc.options]
SystemdCgroup = true
3. Ajuster la configuration de Kubelet :
cgroupDriver: systemd
# Séquence de redémarrage :
kubectl drain <nœud> –ignore-daemonsets
systemctl restart containerd kubelet
kubectl uncordon <nœud>
« Un nœud qui ne redémarre pas proprement après le vidage, c’est le moment où la planification se heurte à la réalité. Prévoyez 45 minutes par nœud, pas 15. »
– Alec Chizhik, cloudmagazin
Étape 3 : Configurer DRA – Dynamic Resource Allocation
DRA est désormais en disponibilité générale dans la version 1.36. Qu’est-ce que cela signifie pour les équipes gérant des charges de travail GPU ou FPGA ? DRA remplace l’ancien mécanisme de plugin de périphérique pour les ressources matérielles. Si vous utilisez des GPU NVIDIA via le plugin de périphérique NVIDIA, vous devez vérifier si le pilote du fournisseur est déjà compatible avec DRA.
Vérifications obligatoires pour DRA dans les environnements GPU :
kubectl get –raw /api/v1 | grep -i « dynamic »
# Vérifier les CRDs ResourceSlice et DeviceClass :
kubectl get crd | grep resource.k8s.io
# Sortie attendue :
# deviceclasses.resource.k8s.io
# resourceclaims.resource.k8s.io
# resourceslices.resource.k8s.io
NVIDIA a introduit le support DRA avec NVIDIA-GPU-Operator 25.x. Le support DRA pour AMD ROCm est annoncé pour le deuxième trimestre 2026. Si vous utilisez des GPU Intel (Gaudi, Arc), vous devez effectuer des vérifications séparées ; les Extensions Kubernetes d’Intel ont leur propre cycle de publication.
Avantages et inconvénients : passer directement à 1.36 ou faire une étape intermédiaire via 1.35
Arguments pour le passage direct à 1.36
- Une seule migration au lieu de deux (pas de version intermédiaire)
- DRA-GA immédiatement utilisable
- Horizon de support plus long (fin de vie de 1.36 : ~avril 2027)
- Une seule fenêtre d’indisponibilité au lieu de deux
Arguments pour l’étape intermédiaire via 1.35
- Migration cgroup-v2 préparable en 1.35 sans les modifications de 1.36
- DRA encore en beta en 1.35 – moins de surprises s’il n’y a pas de charge GPU
- Répartition des risques : migration infrastructure + mise à jour API séparées
Foire aux questions
Dois-je activer cgroup-v2 avant de mettre à niveau vers K8s 1.36 ?
Oui, c’est une exigence stricte. K8s 1.36 ne démarre pas sur les nœuds qui fonctionnent encore en mode cgroup-v1. La migration doit être terminée au niveau du nœud avant la mise à niveau Kubernetes (paramètres GRUB + configuration containerd + config Kubelet).
Quelle version de containerd me faut-il pour Kubernetes 1.36 ?
Le minimum est containerd 1.7.x. Il est recommandé d’utiliser containerd 2.0.x pour un support complet. containerd 1.6.x n’est plus compatible. Vérifiez avec containerd –version.
DRA remplace-t-il NVIDIA Device Plugin ?
À moyen terme oui, à court terme les deux coexistent. DRA est en GA dès K8s 1.36, mais les pilotes des fabricants ont leurs propres feuilles de route. NVIDIA GPU Operator prend en charge DRA à partir de la version 25.x. Le Device Plugin continue de fonctionner en parallèle jusqu’à ce que les fabricants basculent officiellement vers DRA uniquement.
Que deviennent mes quotas de ressources existants après la migration vers cgroup-v2 ?
Les limites mémoire et CPU restent sémantiquement identiques sous cgroup-v2. La différence : cgroup-v2 applique les limites plus précisément, notamment dans les scénarios de sur-engagement mémoire. Dans de rares cas, les charges de travail qui fonctionnaient à la limite sous cgroup-v1 peuvent recevoir des signaux OOM plus tôt sous cgroup-v2.
Comment vérifier si mon service Kubernetes managé (EKS, GKE, AKS) utilise déjà cgroup-v2 ?
EKS : Amazon Linux 2023 utilise cgroup-v2 par défaut. Amazon Linux 2 reste en cgroup-v1. GKE : Tous les nœuds avec Container-Optimized OS depuis 2023 sont en cgroup-v2. AKS : Les nœuds Ubuntu standard passent à cgroup-v2 à partir d’AKS 1.25. Vérifiez avec stat -fc %T /sys/fs/cgroup sur un nœud.
Réseau
Industrie 5.0 : Ce que les CIO doivent décider maintenant (Digital Chiefs) | Nearshoring 2026 : Cadre décisionnel (MyBusinessFuture)
Source image de couverture : Pexels / cottonbro studio (px:6804597)
