Ingress-NGINX est mort : le vrai outil pour migrer enfin

Ingress-NGINX est mort depuis mars 2026. Si tu as lu notre article sur la fin de vie annoncée, tu sais déjà qu’il fallait bouger. Ce qui a changé depuis : il existe enfin un chemin de migration qui tient la route, avec une API stable pour le trafic TCP/UDP brut et un outil officiel qui fait le gros du travail de conversion.

Ce qui vient de devenir stable

Gateway API v1.6.0 est sorti le 30 juin 2026, et c’est la première version où TCPRoute et UDPRoute quittent le channel expérimental pour rejoindre le Standard channel, sous l’API gateway.networking.k8s.io/v1. Avant cette version, ces deux types de ressources vivaient en v1alpha2 — utilisables, mais sans garantie de stabilité, ce qui en bloquait l’adoption en production pour pas mal d’équipes.

Concrètement, une TCPRoute ne gère ni hostnames, ni matches, ni filtres : elle route une connexion vers un ou plusieurs backendRefs (16 maximum par règle), avec une répartition pondérée en support étendu si tu en as besoin. C’est volontairement minimaliste — pensé pour exposer une base de données, un serveur DNS ou tout protocole qui ne parle pas HTTP. Un exemple minimal :

apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
  name: postgres-route
spec:
  parentRefs:
    - name: my-gateway
      sectionName: postgres
  rules:
    - backendRefs:
        - name: postgres-svc
          port: 5432

Le détail qui compte : un parentRef se résout par sectionName (un listener nommé sur ta Gateway) ou par port. Si tu exposais déjà des flux TCP/UDP via des annotations maison sur Ingress-NGINX (c’était fréquent pour la base de données ou le LDAP), tu as maintenant un équivalent standard, documenté, et porté par plusieurs implémentations de la Gateway API. Voir la référence officielle TCPRoute pour le détail complet des champs.

L’outil qui change vraiment la donne : Ingress2Gateway

Le projet kubernetes-sigs/ingress2gateway a atteint la version 1.0 le 20 mars 2026, puis la 1.2 en juillet. Ce n’est pas un contrôleur, il ne touche à rien en prod : il lit tes manifestes Ingress (ou directement ton cluster via le kubeconfig courant) et génère les ressources Gateway API équivalentes.

ingress2gateway print \
  --providers=ingress-nginx \
  --emitter=kgateway \
  --input-file ./ingress.yaml \
  -o yaml

Quelques options utiles au quotidien : -n/--namespace pour restreindre la lecture à un namespace, -A pour tout le cluster, --allow-experimental-gw-api si tu veux aussi les champs encore expérimentaux, et --ingress-nginx-ingress-class si ta classe Ingress n’est pas la nginx par défaut. L’outil ne devine pas tout : les annotations propres à Ingress-NGINX qui n’ont pas d’équivalent direct (certaines logiques de rewrite avancées, par exemple) ressortent en avertissement plutôt qu’en conversion silencieuse — ce qui est exactement le comportement que tu veux avant une bascule en production.

Ta checklist de migration

• Choisis ton implémentation de la Gateway API avant de lancer la conversion (kgateway, Istio, Envoy Gateway, Cilium…) — les manifestes générés en dépendent directement.
• Lance ingress2gateway print sur un export de tes manifestes, pas directement en écriture sur le cluster : relis les avertissements avant d’appliquer quoi que ce soit.
• Vérifie que les politiques annexes (auth, rate limiting, retries) qui vivaient dans des annotations NGINX ont bien un équivalent — souvent via des Policy spécifiques à l’implémentation choisie, pas via HTTPRoute lui-même.
• Migre un service non critique en premier, garde l’ancien Ingress en place en parallèle le temps de valider DNS, TLS et comportement des redirections.
• Ne fais jamais tourner deux contrôleurs qui revendiquent le même trafic en même temps — bascule service par service, pas en big bang.

Pourquoi ça ne peut plus attendre

Ingress-NGINX n’a plus de patch de sécurité depuis sa fin de vie. Pour rappel, la dernière faille sérieuse avant la mise en retraite — CVE-2026-3288, score CVSS 8.8, injection de configuration nginx via l’annotation rewrite-target — permettait l’exécution de code dans le contexte du contrôleur et, de fait, la lecture de tous les Secrets qu’il pouvait voir. Elle a été corrigée dans les versions 1.13.8, 1.14.4 et 1.15.0, mais plus aucune version future ne recevra ce genre de correctif. Si tu fais tourner Ingress-NGINX aujourd’hui en te disant « ça tourne, je verrai plus tard », c’est ce genre de CVE qui ne sera jamais patchée pour toi.

Pour en savoir plus sur l’annonce initiale de retraite, voir le billet officiel du blog Kubernetes.

FAQ

Dois-je migrer vers Gateway API même si mon trafic est purement HTTP ?

Oui, à terme — HTTPRoute est stable depuis plus longtemps que TCPRoute/UDPRoute et c’est le remplaçant naturel d’Ingress pour le trafic web. Mais rien ne t’empêche de migrer en deux temps : HTTP d’abord, TCP/UDP ensuite si tu en as besoin.

Ingress2Gateway supporte-t-il d’autres contrôleurs qu’Ingress-NGINX ?

Le provider le mieux documenté reste ingress-nginx, mais le projet gère aussi d’autres providers d’entrée — vérifie la liste à jour avec ingress2gateway --help sur ta version installée, elle évolue vite.

Faut-il abandonner complètement les annotations NGINX ?

Celles qui correspondent à du routage pur (host, path, rewrite simple) se convertissent bien vers HTTPRoute. Celles qui pilotaient des comportements avancés (auth externe, limitation de débit fine) demandent presque toujours une politique spécifique à ton implémentation de la Gateway API — ce n’est pas automatique, prévois ce travail dans ton planning de migration.

Passe à l’action

Si tu as encore des Ingress NGINX en prod, le plus urgent n’est pas de tout migrer ce week-end : c’est de faire tourner ingress2gateway print une première fois sur un export de tes manifestes pour voir ce qui se convertit proprement et ce qui ne se convertit pas. Tu sauras en une commande où se trouve le vrai travail.