GPU sur Kubernetes : ce qui fonctionne ensemble, septembre 2026

Date de relevé : 2026-09-04. Chaque ligne ci-dessous a été vérifiée ce jour-là sur les pages officielles NVIDIA, Kubernetes, cert-manager, Cilium, Calico et Helm. Les versions et les dates sont reprises telles qu'elles y figurent.

En résumé

• Restez sur Kubernetes 1.35 ou 1.36. La 1.37 est sortie le 2026-08-26, mais le GPU Operator, cert-manager, Cilium, Calico, Helm 4.2 et ingress-nginx ne la prennent pas encore en charge. La 1.34 arrive en fin de vie le 2026-10-27 : ne démarrez rien de nouveau dessus.
• Figez le driver sur la branche R580 LTS (580.178.04, fin de vie juin 2028) ou R595 production (595.91.07, fin de vie mars 2027). Les deux sont des branches CUDA 13.
• Ce choix plafonne CUDA à 13.2. CUDA 13.3 exige le driver 610.43.02, livré uniquement sur R610, une nouvelle branche feature dont NVIDIA n'annonce pas la durée de support. Soit vous plafonnez vos images à 13.2, soit vous embarquez le paquet de forward compatibility.
• Encore sur R535 ? Cette branche est en fin de vie depuis juin 2026 et ne fait pas tourner CUDA 13. Migrez maintenant.
• Le projet ingress-nginx est arrêté. Il n'y aura jamais de build testé sur Kubernetes 1.36 ou 1.37, ni de correctif de sécurité. Choisissez une implémentation Gateway API.
• GPU Operator 26.7.0 exige containerd 2.0. La 26.3.x est dépréciée mais accepte encore containerd 1.7. Mettez à niveau containerd d'abord, l'operator ensuite.
• Toute version du Container Toolkit antérieure à 1.17.8 traîne deux CVE publiées, dont une critique. La version actuelle est la 1.20.0. Vérifiez-la sur chaque nœud cette semaine.

La matrice

Quel driver pour quel CUDA

Le plancher ne se négocie pas : tout toolkit CUDA 13.x exige un driver 580 ou plus récent, CUDA 12.x tourne sur les drivers 525 à 579, et la compatibilité de version mineure ne sauvera ni le code compilé en PTX ni les fonctionnalités qui dépendent du driver quand celui-ci est trop ancien (cudaErrorCallRequiresNewerDriver).

Ce qui casse vraiment à la mise à niveau

• Kubernetes 1.37 : SELinuxMount est activé par défaut et « peut casser des charges existantes dans les clusters où SELinux est activé » ; scheduling.k8s.io v1alpha2 a disparu, supprimez donc ces objets du kube-apiserver avant la mise à niveau.
• Kubernetes 1.36 : le plugin de volume git-repo est désactivé sans possibilité de le réactiver, et volume_operation_total_errors est devenu volume_operation_errors_total, donc vos dashboards et vos alertes ne trouvent plus la métrique.
• GPU Operator 26.7.0 : le mode DRA/GPUCluster exige Kubernetes 1.34.2 ou plus récent, un driver 580 ou plus récent et un runtime compatible CDI ; GPUCluster et ClusterPolicy ne peuvent pas coexister dans un même cluster.
• Conteneur driver du GPU Operator : tous les nœuds worker doivent tourner sur la même version d'OS ; un parc hétérogène ne fonctionne qu'avec des drivers préinstallés.
• Device plugin 0.19.0 : les flags par défaut (gds, gdrcopy, mofed) ont changé, ce qui a cassé les charges RDMA/NCCL ; corrigé en 0.19.3 et dans GPU Operator 26.3.3.
• NVIDIA driver 570.124.06 à 570.158.01 : mélanger des tranches MIG et des GPU entiers sur un même nœud cassait l'ordonnancement ; corrigé à partir de 570.172.08 et 580.65.06.
• NVIDIA driver sur Grace (GH200, GB200) : à partir de 580.65.06, CDMM est activé par défaut, ce qui est incompatible avec le partage MIG et GPUDirect Storage.
• Container Toolkit 1.19.1 et suivants : les specs CDI sont générées au schéma v0.7.0 et les runtimes plus anciens les rejettent ; minimums : containerd 1.7.16, cri-o 1.30.0, docker 26.1.0, podman 5.1.0.
• cert-manager 1.21 : les configurations Vault Kubernetes auth et Route53 qui utilisent le ServiceAccount du controller perdent le droit create sur serviceaccounts/token ; ajoutez votre propre RBAC ou passez à un ServiceAccount dédié.
• Cilium 1.20 : proxylib est supprimé, retirez donc les sections kafka, l7 et l7proto de vos politiques avant la mise à niveau, et CiliumNodeConfig doit passer sur cilium.io/v2.

Les prochaines dates à retenir

• 2026-09-09 : fin des correctifs de bugs Helm 3.
• 2026-09-15 : prochaine vague de patchs Kubernetes.
• 2026-10-27 : fin de vie de Kubernetes 1.34.
• 2026-11 (prévu) : sortie de cert-manager 1.22, qui met fin au support de la 1.20.
• 2027-02-10 : fin des correctifs de sécurité Helm 3.
• 2027-02-28 : fin de vie de Kubernetes 1.35.
• 2027-03 : fin de vie de la branche production NVIDIA R595.
• 2027-06-28 : fin de vie de Kubernetes 1.36.
• 2028-06 : fin de vie de la branche LTS NVIDIA R580.

C'est la liste que Dixence déroule avant de toucher au moindre cluster qu'elle maintient. L'édition d'octobre suivra dès que les pages upstream auront changé.