kube-proxy en nftables et Gateway API : le plan de migration réseau à boucler avant Kubernetes 1.37

Les équipes plateforme ont l’habitude des dépréciations : une API v1beta1 qui disparaît, un flag de kubelet qui change de nom. Ce cycle-ci est différent, parce que les deux échéances qui tombent simultanément touchent le chemin de données de production : la façon dont les paquets atteignent vos Services, et la façon dont le trafic externe entre dans le cluster. Aucune des deux ne se règle par un kubectl apply de plus.

Deux ruptures simultanées : ce qui est supprimé, ce qui est seulement déprécié

Il faut séparer proprement les deux dossiers, car ils n’ont ni le même niveau d’urgence ni le même profil de risque.

Dossier 1 — kube-proxy. Le mode nftables est stable depuis la lignée 1.33 et constitue désormais la cible recommandée sur Linux. Le mode ipvs est entré en dépréciation avec 1.35, avec une suppression annoncée pour la lignée 1.36/1.37. Le mode iptables, lui, reste supporté : ne le mélangez pas dans la même urgence, même si sa trajectoire à moyen terme est claire. Point de vigilance : la disponibilité réelle du mode dépend de votre distribution. Vérifiez les release notes de votre fournisseur managé ou de votre installeur avant de fixer une date, car certaines distributions figent encore la valeur par défaut ou embarquent un kube-proxy patché.

Dossier 2 — Ingress NGINX. Ici il n’y a pas de dépréciation progressive : le contrôleur est retiré depuis mars 2026 et ne reçoit plus aucun correctif de sécurité. Un contrôleur d’entrée qui termine les connexions TLS, parse des en-têtes non fiables et tourne souvent avec des capacités réseau élevées est exactement le composant…