Kubernetes 1.36 est arrivé : espaces de noms utilisateurs stables, IPVS supprimé, Ingress-NGX retiré

5 min de lecture

Kubernetes 1.36 sort le 22 avril 2026, avec environ 80 améliorations et plusieurs changements qui occuperont concrètement les équipes d’exploitation dans les semaines à venir. Les User Namespaces deviennent stables, le mode IPVS disparaît de kube-proxy, et le plugin de volume gitRepo est supprimé. En parallèle, le champ externalIPs émet des avertissements de dépréciation. Ceux qui ne mettent pas à jour leur feuille de route pour les clusters se préparent à un mur pour la v1.43.

En lienFinOps : évaluation de la maturité 2026  /  Opus 4.7 vs GPT-5.4 : l’inférence cloud européenne en 2026

Ce qui a réellement changé avec Kubernetes 1.36

Les chiffres en un coup d’œil : 80 améliorations dans cette version, dont 18 passent en stable, 18 en bêta, et 26 sont de nouvelles fonctionnalités alpha. Après plusieurs cycles de release axés sur des ajouts liés à l’IA (comme l’ordonnancement optimisé pour l’IA dans la 1.35), la version 1.36 recentre les efforts sur les fondations de la plateforme. Les User Namespaces en sont le point d’orgue : les Pods peuvent désormais fonctionner en production avec leur propre plage d’UID par rapport à l’hôte, ce qui réduit la surface d’attaque classique liée à l’échappement de conteneurs. Pour les charges de travail sensibles en matière de sécurité dans des environnements régulés, il s’agissait de la fonctionnalité manquante la plus souvent citée depuis deux ans.

Les volumes OCI (Stable) permettent de monter directement des artefacts OCI en tant que volumes en lecture seule dans les Pods, sans avoir besoin d’un Init-Container dédié. Le Scale-to-Zero du HPA passe en bêta et ouvre la voie à des déploiements dormant en permanence, qui ne sont mis à l’échelle qu’à la demande. Pour des modèles similaires au serverless au sein de clusters Kubernetes classiques, c’est un levier concret.

Les suppressions sont également significatives. Les volumes gitRepo disparaissent définitivement, car l’audit de sécurité a documenté à plusieurs reprises des risques liés à la chaîne d’approvisionnement. Le mode IPVS dans kube-proxy, déprécié dans la v1.35, est désormais complètement supprimé, ce qui fait de la configuration proxy basée sur iptables la valeur par défaut. Les champs externalIPs dans les objets Service émettent désormais des avertissements de dépréciation et disparaîtront définitivement dans la v1.43. Ceux qui utilisent encore externalIPs dans leurs manifestes doivent migrer vers LoadBalancer ou Ingress d’ici là.

Pourquoi cela est pertinent pour les équipes DACH dès maintenant

L’impact opérationnel réside moins dans les nouvelles fonctionnalités que dans les *breaking changes*. Les clusters d’entreprise allemands, souvent évolués sur plusieurs années, comportent des configurations historiques qui fonctionnaient encore sous la version 1.35 mais qui pourraient poser problème avec la 1.36. IPVS était le paramètre par défaut pour de nombreuses équipes, ses avantages en termes de performance pour les grands volumes de services étant bien documentés. Sa suppression impose désormais de vérifier les limites de *connection tracking* et de planifier les capacités dans les configurations iptables.

Le cas d’Ingress-NGINX est encore plus marqué. Le 24 mars 2026, la SIG Security a officiellement retiré le contrôleur, faute de ressources suffisantes pour assurer les *security reviews* requises. Dans les installations DACH, Ingress-NGINX reste de loin le choix le plus courant pour l’ingress des clusters. La migration vers la Gateway API ou des contrôleurs alternatifs comme HAProxy, Contour ou Traefik n’est pas triviale. La SIG recommande un audit sous 60 jours, car les nouvelles vulnérabilités (CVE) dans Ingress-NGINX ne seront plus corrigées.

La graduation des *user namespaces* ouvre en revanche une porte que les équipes sécurité allemandes réclamaient depuis des années. Les secteurs régulés (services financiers, santé, infrastructures critiques) disposent désormais d’un outil natif pour renforcer l’isolation des conteneurs, sans dépendre de projets externes comme gVisor ou Kata Containers. Pour les audits NIS2, ce point deviendra un sujet central dans les *security reviews* des prochains mois.

Analyse pour les architectes cloud

Cette version est moins axée sur les fonctionnalités que les précédentes, mais elle implique davantage de travail par cluster. Les fournisseurs de Kubernetes managés (EKS, AKS, GKE, IONOS Managed Kubernetes, STACKIT) déploieront la prise en charge de la 1.36 au cours des quatre à huit prochaines semaines. Pour ceux qui gèrent leurs clusters en interne, la date de sortie est fixée au 22 avril. Les équipes travaillant avec des clusters de taille moyenne devraient au minimum mettre à niveau un cluster de staging vers la 1.36, exécuter des scans des manifests pour identifier les trois *breaking changes*, et parallèlement élaborer un plan de migration pour Ingress-NGINX.

Le point le plus stratégique est l’abandon d’Ingress-NGINX. Si vous n’avez pas encore de feuille de route, vous devriez trancher dans les deux prochaines semaines : rester avec un engagement de *security patching* en interne, migrer vers la Gateway API avec un autre implémenteur, ou opter pour un contrôleur Ingress commercial avec un contrat de support. Cette décision aura des répercussions sur la planification des ressources et la gouvernance sécurité jusqu’au troisième trimestre 2026.

Concrètement, cela signifie pour de nombreuses équipes qu’il faudra libérer un ou deux sprints dans le planning. Ceux qui ont déjà expérimenté la Gateway API ont fait la moitié du chemin. Ceux qui n’ont jamais simulé une migration des règles Ingress devraient organiser un *tabletop walkthrough* avec les équipes SRE et réseau d’ici fin mai au plus tard.

Questions fréquentes

La mise à niveau vers Kubernetes 1.36 est-elle absolument nécessaire ?

Kubernetes 1.33 (février 2025) est la première version à ne bénéficier que d’un mois de support supplémentaire. À partir de mai 2026, Kubernetes 1.34 sera la version supportée la plus ancienne. Quiconque exploite encore la version 1.32 ou une version antérieure ne bénéficie plus d’aucun support. La mise à niveau vers la 1.36 n’est pas impérativement immédiate, mais le saut direct vers la prochaine LTS n’est pas un schéma qui fonctionne bien sous Kubernetes.

Quel est le bon chemin de migration pour quitter Ingress-NGINX ?

Le SIG Security recommande la Gateway API associée à une implémentation activement maintenue. Les candidats réalistes sont Contour, Traefik, HAProxy ou les variantes commerciales de NGINX Inc. et F5. La migration ne se fait pas en un seul sprint, car la Gateway API repose sur des types de ressources différents et les règles de réécriture doivent être migrées. Les équipes doivent prévoir entre quatre et douze semaines selon la taille du cluster.

Dois-je utiliser les User Namespaces directement en production ?

Pour les charges de travail sensibles en matière de sécurité, oui, mais de manière progressive. La feature gate est stable, mais la maturité de la plateforme dans des scénarios de production nécessite encore un à deux trimestres d’observation. Des tests en environnement de staging avec une charge représentative constituent la première étape recommandée avant de basculer les charges de travail critiques.

Plus du réseau MBF Media

Quelle Titelbild: Pexels / Wolfgang Weiser (px:33512156)