Kubernetes Gateway API devient mainstream : l’ère Ingress se termine en 2026

Ingress-NGINX est retiré — voici ce qui s'est réellement passé

Ingress-NGINX, le contrôleur d'ingress le plus largement déployé dans l'écosystème Kubernetes, a atteint la fin officielle de maintenance le 24 mars 2026. Les déploiements existants continueront de tourner et les artefacts restent disponibles, mais il n'y aura plus de releases, de correctifs ni de patchs de sécurité. La SIG-Network Kubernetes et le Security Response Committee ont cité un manque de mainteneurs (1-2 mainteneurs à temps partiel pour un projet adopté mondialement) et une dette technique accumulée — incluant l'annotation « snippets » qui permettait une configuration NGINX arbitraire et était devenue une source récurrente de préoccupations sécurité.

Ce n'est pas juste une note de ménage. Pour des milliers de clusters qui dépendent encore d'ingress-nginx, l'absence de futurs patchs de sécurité en fait une responsabilité de conformité autant qu'opérationnelle. La recommandation de la SIG-Network est sans ambiguïté : migrez, et commencez maintenant.

Gateway API est le successeur — et il est réellement prêt

Gateway API est un groupe de travail SIG-Network depuis des années, mais 2026 est l'année où il est passé de « prometteur » à « baseline production ». La spécification livre ce que chaque équipe plateforme Kubernetes sérieuse attendait d'Ingress et contournait avec des annotations : primitives de routage expressives, CRD type-safe avec validation appropriée, séparation claire des rôles entre équipes infrastructure, plateforme et applications, routage cross-namespace, et modèle d'extension standard pour les fonctionnalités spécifiques vendor.

Les signaux de l'écosystème sont tout aussi importants que la spec. AWS Load Balancer Controller a livré le support GA pour Kubernetes Gateway API en mars 2026, gérant le routage L4 (TCP/UDP via NLB) et L7 (HTTP/gRPC via ALB) via la spec Gateway API. Ce seul changement donne aux clients AWS la découverte automatique de certificats, le routage cross-namespace et le déploiement à rôles séparés sans permissions cluster-admin — exactement les fonctionnalités que les équipes plateforme construisaient avec du glue custom. Google Cloud, Azure et les principaux projets de service mesh (Istio, Linkerd, Cilium) livrent tous des implémentations Gateway API en parallèle.

L'histoire de la migration est moins douloureuse qu'il n'y paraît

Le projet Kubernetes a sorti Ingress2Gateway 1.0 le 20 mars 2026 — un outil de conversion qui mappe les ressources Ingress existantes sur les équivalents Gateway API. Ce n'est pas une baguette magique ; les configurations complexes pilotées par annotations nécessitent toujours une revue. Mais pour le cas courant (une poignée de ressources Ingress pointant vers des services via des routes basées sur hôte et chemin), Ingress2Gateway prend quelques minutes plutôt que des jours.

Opérationnellement, le chemin de migration le plus sûr est l'exécution parallèle : déployer Gateway API aux côtés de l'Ingress existant, router un sous-ensemble de trafic via le nouveau chemin, valider le comportement et basculer graduellement. Kubernetes supporte depuis longtemps plusieurs contrôleurs sur le même cluster, donc la bascule n'a pas à être un événement de cutover. Les équipes avec des pipelines GitOps matures trouveront la migration particulièrement propre — les types de ressources explicites de Gateway API (Gateway, HTTPRoute, GRPCRoute, TLSRoute) mappent proprement sur les pratiques Helm, Kustomize et ArgoCD/Flux.

Ce que les équipes plateforme devraient faire en 2026

Trois étapes pratiques. D'abord, auditer. Lancez la commande recommandée (`kubectl get pods –all-namespaces –selector app.kubernetes.io/name=ingress-nginx`) sur chaque cluster pour trouver où ingress-nginx est encore utilisé. Vous serez probablement surpris ; ingress-nginx atterrit discrètement via des charts Helm, des défauts de Kubernetes managé et des pipelines CI/CD legacy.

Ensuite, prioriser. Démarrez les migrations avec les clusters portant du trafic régulé ou face-client, où l'absence de patchs de sécurité sur ingress-nginx crée une vraie exposition. Les clusters non-prod et internes peuvent suivre.

Enfin, standardiser sur une seule implémentation Gateway API par plateforme. La spec est standard mais les implémentations diffèrent en comportements avancés (extension filters, protocoles de transport, intégration observabilité). Choisissez-en une — contrôleur cloud-provider, Envoy Gateway, ou implémentation service-mesh-native — et faites-en le défaut à travers vos clusters.

L'arc plus large

L'arrivée de Gateway API clôt une tension de longue date dans le networking Kubernetes : Ingress était trop limité, chaque plateforme a donc construit des annotations et CRD custom autour, et la portabilité a souffert. Gateway API rend ce contournement inutile. À mesure que les clusters migrent en 2026 et 2027, attendez-vous à ce que les équipes plateforme récupèrent des heures par semaine de glue routing bespoke et attendez-vous à ce que le vendor lock-in sur le comportement ingress s'assouplisse significativement. C'est la rare transition Kubernetes qui laisse authentiquement les opérateurs mieux lotis après le travail.

Sources et lectures complémentaires

• Ingress NGINX Retirement: What You Need to Know — Kubernetes Blog
• Announcing Ingress2Gateway 1.0 — Kubernetes Blog
• AWS Load Balancer Controller Reaches GA with Kubernetes Gateway API Support — InfoQ
• Kubernetes Ingress vs Gateway API: What to Use in 2026 — OneUptime
• The End of an Era: Transitioning Away from Ingress NGINX — Google Open Source Blog