Kubernetes 1.36 « Haru » : User Namespaces en GA, retrait d'Ingress NGINX et durcissement sécurité

Kubernetes 1.36, baptisée « Haru », est la première release majeure de 2026 — et elle envoie un signal clair : la sécurité par défaut se durcit. Au menu, 70 évolutions (18 passent en stable, 25 en bêta, 25 en alpha nouvelles), avec trois axes : durcissement sécurité, support des workloads IA/ML, et scalabilité de l'API à grande échelle.

Mais au-delà des nouveautés, « Haru » apporte surtout des retraits qui vont casser des déploiements si vous n'anticipez pas. Tour d'horizon de ce qui change, et surtout de ce que vous devez vérifier avant de mettre à jour.

Le gros morceau sécurité : User Namespaces en GA

La graduation la plus importante de cette release, attendue depuis plusieurs cycles : les User Namespaces passent en disponibilité générale (GA).

Le principe est puissant dans sa simplicité : la fonctionnalité mappe l'utilisateur root d'un conteneur vers un utilisateur non privilégié sur l'hôte. Conséquence directe : un processus qui s'échappe d'un conteneur (via une faille du runtime, du kernel, ou une mauvaise config) ne récupère pas les droits administrateur sur le nœud sous-jacent. C'est une réduction massive de l'impact d'une évasion de conteneur — exactement le type de défense en profondeur qu'on réclamait depuis des années.

Deux autres graduations sécurité accompagnent ce mouvement :

• Mutating Admission Policies (GA) — modifier les objets à l'admission via CEL, sans webhook externe à maintenir.
• Fine-Grained Kubelet API Authorization (GA) — un contrôle d'accès bien plus granulaire sur l'API du kubelet, qui était historiquement un point faible.

Pris ensemble, ces trois passages en GA déplacent Kubernetes vers un modèle secure-by-default qui se rapproche des principes d'une architecture Zero Trust.

Gestion des ressources : le pod se redimensionne à chaud

Côté exploitation, deux avancées notables passent en bêta :

• In-Place Vertical Scaling pour les ressources au niveau du pod (bêta, activé par défaut) : on peut redimensionner l'enveloppe CPU/mémoire d'un pod sans redémarrer les conteneurs. Fini les rolling restarts pour ajuster une limite mémoire. Un nouvel événement ResizeDeferred est introduit : si le nœud n'a pas la capacité immédiate, le pod continue de tourner à sa taille actuelle et le kubelet retente le redimensionnement dès que la capacité se libère.
• Memory QoS via cgroup v2 (bêta) : une protection mémoire à plusieurs niveaux qui aligne enfin les contrôles kernel sur les requests et limits des pods, réduisant la contention entre charges qui partagent un nœud.

Le Memory QoS s'appuie directement sur cgroup v2 et sur le PSI (Pressure Stall Information) du kernel Linux — un signal présent depuis 2018 qui permet d'identifier la saturation des ressources avant qu'elle ne devienne une panne.

⚠️ Ce qui casse : les retraits à anticiper

C'est ici qu'il faut être attentif. « Haru » supprime des éléments dépréciés de longue date :

Le plugin de volume gitRepo est supprimé (définitivement)

Déprécié depuis la v1.11, le plugin de volume gitRepo est retiré pour de bon. Et ce n'est pas qu'une question d'hygiène : ce plugin permettait à un attaquant d'exécuter du code en tant que root sur un nœud. Si vous l'utilisez encore, migrez vers des init containers ou un outillage git-sync externe avant de mettre à jour, sous peine de voir vos pods refuser de démarrer.

Ingress NGINX, c'est terminé

Changement majeur côté réseau : le projet Ingress NGINX a été retiré par le SIG Network et le Security Response Committee de Kubernetes le 24 mars 2026. Depuis cette date : plus aucune release, plus aucun correctif de bug, plus aucun patch de sécurité.

C'est lourd de conséquences, car Ingress NGINX est l'un des contrôleurs d'ingress les plus déployés au monde. Continuer à l'utiliser, c'est exposer la porte d'entrée de votre cluster à des vulnérabilités qui ne seront jamais corrigées. Les chemins de migration : Gateway API (le successeur officiel), ou un contrôleur maintenu activement (Envoy Gateway, Traefik, HAProxy, ou les solutions cloud managées).

Plan de migration recommandé

La montée vers 1.36 mérite une checklist :

1. Inventaire des dépréciations. Cherchez gitRepo dans vos manifests, et identifiez tous vos Ingress reposant sur ingress-nginx.

   # Repérer les volumes gitRepo
   kubectl get pods -A -o json | grep -i gitRepo
   
   # Repérer la classe ingress-nginx
   kubectl get ingress -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,CLASS:.spec.ingressClassName

2. Migrer Ingress NGINX vers Gateway API ou un contrôleur maintenu — sur un cluster de staging d'abord.
3. Tester User Namespaces. Activez-les progressivement : tous les workloads ne sont pas compatibles (montages, capacités spécifiques). Validez en pré-prod.
4. Vérifier cgroup v2. Memory QoS suppose des nœuds en cgroup v2 — vérifiez vos OS de nœuds.
5. Monter version par version. Ne sautez pas de versions ; respectez le skew de version supporté entre control plane et kubelets.

Pour la gestion des secrets dans vos manifests (et éviter de les committer), notre guide secrets management (Vault, External Secrets) reste d'actualité. Et pour la détection runtime des évasions de conteneurs que les User Namespaces visent à neutraliser, voir notre article eBPF, Falco et Cilium.

Dans la continuité de 1.35

« Haru » prolonge la trajectoire amorcée par la version précédente. Si vous aviez suivi notre analyse de Kubernetes 1.35 et son Dynamic Resource Allocation pour les GPU, vous reconnaîtrez le fil rouge : Kubernetes se muscle simultanément sur deux fronts, le support des workloads IA (allocation fine des accélérateurs) et le durcissement sécurité (isolation, moindre privilège, contrôle d'accès granulaire).

Conclusion

Kubernetes 1.36 « Haru » est une release de maturité : moins de feux d'artifice, plus de fondations solides. Les User Namespaces en GA sont une victoire pour quiconque prend la sécurité des conteneurs au sérieux, et le redimensionnement à chaud va simplifier la vie des équipes d'exploitation.

Mais le vrai message de cette version est dans ses retraits : gitRepo et Ingress NGINX disparaissent, et ignorer ces deux points transformera votre mise à jour en panne. Comme toujours avec Kubernetes, la montée de version se prépare en amont, sur un cluster de test, jamais à chaud en production. La prochaine étape, la 1.37, est attendue pour le 26 août 2026 — de quoi planifier sereinement votre fenêtre de migration.