Ingress-NGINX en fin de vie : ton plan de migration vers la Gateway API

Si tu gères un cluster Kubernetes en production, il y a de fortes chances que tu utilises encore ingress-nginx pour exposer tes services. Sauf que ce projet, qui équipait historiquement une large majorité des clusters, ne reçoit plus aucun correctif depuis mars 2026 — ni bugfix, ni patch de sécurité. Dans cet article, tu vas comprendre pourquoi ce retrait a eu lieu, ce que Kubernetes propose comme remplaçant officiel (la Gateway API), et comment migrer sans tout casser en prod — avec un cas particulier si tu es sur AKS.

Pourquoi Ingress-NGINX tire sa révérence

Le SIG Network de Kubernetes et le comité de réponse aux incidents de sécurité ont annoncé la retraite du projet ingress-nginx fin 2025, avec une fin de maintenance actée en mars 2026. Deux raisons principales ont motivé cette décision :

• Un risque de sécurité structurel : le mécanisme de « snippets » qui permet d’injecter de la configuration NGINX brute via des annotations a été à l’origine de plusieurs CVE critiques, car il ouvre la porte à de l’injection de configuration depuis des ressources Ingress non fiables.
• Un projet sous-staffé : malgré des millions de déploiements dans le monde, la maintenance reposait sur une ou deux personnes bénévoles, un rythme intenable face à la charge de sécurité d’un composant aussi exposé.

Concrètement, depuis mars 2026 : plus de nouvelles releases, plus de correctifs de bugs, et surtout plus de patch en cas de nouvelle faille découverte. Si tu tournes encore dessus, chaque jour qui passe sans plan de migration augmente ton exposition.

La Gateway API, le successeur « officiel »

La communauté Kubernetes pousse depuis plusieurs années la Gateway API comme évolution naturelle d’Ingress — certains parlent d’« Ingress 2.0 ». Contrairement à l’API Ingress, pensée comme un objet unique et assez rigide, la Gateway API sépare clairement les responsabilités :

• le GatewayClass, fourni par le vendeur d’infrastructure (le contrôleur) ;
• le Gateway, géré par l’équipe plateforme/infra (les points d’entrée réseau) ;
• les HTTPRoute / GRPCRoute / TCPRoute, gérés par les équipes applicatives (le routage vers leurs services).

Cette séparation évite justement le problème des snippets : plus besoin d’injecter du texte de config libre, chaque équipe agit dans son périmètre avec des ressources typées. Côté maturité, le canal « standard » de la Gateway API n’a plus connu de changement cassant depuis deux ans, et TCPRoute/UDPRoute ont atteint la disponibilité générale récemment (dernière version stable v1.6.x début septembre 2026), ce qui en fait un socle solide au-delà du simple HTTP/HTTPS.

Et si tu es sur Azure Kubernetes Service (AKS) ?

Microsoft aligne AKS sur cette bascule upstream. Si tu utilises le module complémentaire de routage applicatif (application routing add-on) avec NGINX, tu bénéficies de correctifs de sécurité critiques jusqu’en novembre 2026 — mais aucune migration n’est imposée dans l’urgence aujourd’hui. Selon ta configuration actuelle, la documentation officielle AKS recommande un chemin de migration parmi trois :

• basculer vers l’implémentation Gateway API du module de routage applicatif ;
• migrer vers Application Gateway for Containers, qui prend en charge à la fois Ingress et Gateway API en natif ;
• ou, si tu as des besoins avancés (limites de taille de requête, scripts Lua, rate limiting), passer par l’add-on de service mesh Istio avec Gateway API.

Exemple concret : convertir un Ingress en Gateway API

Voici la même route exposée d’abord en Ingress classique, puis en Gateway API :

<!-- Ingress classique -->
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mon-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: monapp.exemple.fr
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: mon-app-svc
            port:
              number: 80

# Équivalent en Gateway API
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: mon-app
spec:
  parentRefs:
  - name: gateway-principale
  hostnames:
  - "monapp.exemple.fr"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: mon-app-svc
      port: 80

Le Gateway (le point d’entrée réseau lui-même, avec ses listeners et son TLS) est créé une seule fois par l’équipe plateforme, et chaque équipe applicative ne gère plus que ses HTTPRoute.

Comment migrer sans tout casser

Une migration Ingress → Gateway API se prépare, elle ne s’improvise pas un vendredi après-midi :

• Fais l’inventaire de toutes tes ressources Ingress actuelles (annotations comprises — c’est souvent là que se cachent les comportements spécifiques à migrer).
• Utilise ingress2gateway, l’outil officiel du projet Kubernetes SIG Network qui génère automatiquement les Gateway et HTTPRoute équivalents à partir de tes Ingress existants (support NGINX, Istio, GKE et plusieurs autres contrôleurs).
• Teste en environnement de staging avant toute bascule en prod, en particulier les comportements liés aux annotations spécifiques à ton contrôleur actuel qui n’ont pas toujours d’équivalent direct.
• Bascule progressivement, service par service si possible, avec un plan de rollback clair (garder les Ingress en parallèle le temps de valider chaque route).

FAQ

Dois-je migrer dans l’urgence ?

Non, mais tu dois planifier. Si tu es sur AKS avec le module NGINX, tu as un filet de sécurité jusqu’à fin novembre 2026. Au-delà, plus aucun correctif ne sera publié pour ingress-nginx lui-même.

Qu’est-ce qui casse concrètement si je ne fais rien ?

Rien ne casse du jour au lendemain — mais toute nouvelle CVE découverte sur ingress-nginx restera non corrigée, ce qui devient vite un point bloquant en audit de sécurité ou en conformité.

La Gateway API fonctionne-t-elle avec Helm et ArgoCD ?

Oui, les ressources Gateway et HTTPRoute sont des CRD Kubernetes standard : elles se déploient et se versionnent exactement comme n’importe quelle autre ressource, via Helm, Kustomize ou GitOps (ArgoCD/Flux).

La bascule vers la Gateway API n’est pas qu’une contrainte de fin de vie à subir : c’est aussi l’occasion de clarifier qui possède quoi entre équipe plateforme et équipes applicatives. Si tu tournes encore sur une version ancienne de Kubernetes, c’est aussi le bon moment pour vérifier ta compatibilité — jette un œil à notre article sur les nouveautés de Kubernetes 1.37. Et si la sécurité de ton cluster en général mérite un tour de vérification, notre guide complet pour sécuriser un cluster Kubernetes reste une bonne base.