Fin d’Ingress NGINX Controller : ce que vous devez faire avant mars 2026

C’était, c’est toujours d’ailleurs, ne l’enterrons pas trop vite, l’Ingress Controller le plus utilisé de la planète Kubernetes. Un mastodonte. Un classique. Le bon vieux portail NGINX qui encaissait tout. Et pourtant, en mars 2026, c’est la fin.

Si vous gérez des clusters K8S, impossible que la nouvelle vous ait échappé : l’équipe Kubernetes retire officiellement Ingress NGINX Controller du futur de l’écosystème. Il vous reste un an et demi pour trouver une alternative : après la date butoir, plus aucun correctif ne sera appliqué, même critique.

Alors… comment rebondir ? Que prévoit Kubernetes ? Quelles sont vos options ? On décrypte tout ça pour vous. Place à la magie.

Découvrir nos services DevOps

La raison officielle tient en deux mots : dette technique.
La vraie raison, elle, tient en une phrase :

« Ce qui autrefois était perçu comme des options pratiques est aujourd’hui vu comme de véritables failles de sécurité, comme la possibilité d’injecter des directives NGINX arbitraires via les annotations snippets. La flexibilité d’hier est devenue la dette technique insurmontable d’aujourd’hui. »

C’est Tabitha Sable, l’autrice du communiqué officiel de Kubernetes, qui résume le mieux la situation : Ingress NGINX a été victime de son propre succès. Trop de fonctionnalités. Trop d’annotations. Trop de hacks. Trop de comportements implicites. Et surtout : pas assez de mainteneurs.

Pendant des années, le projet a survécu grâce à 1 ou 2 développeurs bénévoles. Nos héros.

Mais en mars 2025, Wiz Research révèle une série de vulnérabilités critiques (#IngressNightmare), dont une CVE notée 9.8 permettant une exécution de code à distance sans authentification et l’accès aux secrets du cluster. C’est le coup de grâce.

Le 11 novembre 2025, l’annonce tombe : Ingress NGINX Controller sera officiellement déprécié en mars 2026.

Il continuera de fonctionner… mais deviendra un composant non maintenu, exposé sur Internet.
Autrement dit : un risque.

Avant de parler de migration, rappelons que seul le moteur NGINX Ingress est déprécié.
L’API Ingress, elle, reste supportée.

En pratique, vous pouvez conserver le modèle Ingress tout en changeant simplement de moteur.Cela dit, Kubernetes fait progressivement évoluer son architecture réseau vers Gateway API, et c’est là qu’il va falloir se retrousser un peu les manches.

Revenons à nos moutons, pour remplacer Ingress NGINX Controller, vous avez trois options :

🟥 Rester sur Ingress NGINX Controller (déconseillé)

Honnêtement, nous ne le recommandons pas.
À moins que ce ne soit temporaire.
À partir de mars 2026, il ne sera plus maintenu et deviendra vulnérable et instable.

🟧 Changer d’Ingress Controller

C’est ce que feront la majorité des équipes.
C’est simple, pragmatique, immédiat : on change le moteur, pas la philosophie.

Voilà les alternatives Ingress Controller que vous pouvez utiliser :

• Traefik Ingress Controller : moderne, dynamique, configuration CRD propre, très apprécié des plateformes orientées DX.
• HAProxy Ingress : robuste, performant, basé sur un proxy reconnu depuis des décennies. Parfait pour les environnements exigeants.
• Contour (basé sur Envoy) : architecture propre, très stable, excellent support HTTP/2 et gRPC. 
• Istio Ingress Gateway : peut sembler “lourd”, mais pertinent si vous utilisez déjà Istio en mesh.
• Kong Ingress Controller : orienté API Gateway, parfait si vous faites beaucoup de gestion d’API.
• Pomerium : idéal pour les besoins d’auth forte (Zero Trust).
• Apache APISIX Ingress : flexible, orienté API, extensible en Lua, de plus en plus adopté.
• GKE Ingress / AWS ALB Ingress Controller / Azure AGIC : les contrôleurs propriétaires fournis par les clouds, simples, stables, mais moins portables.
• NGINX Ingress Controller : oui, promis, ce n’est pas la même chose que Ingress NGINX Controller. Il s’agit du contrôleur officiel édité par NGINX/F5. C’est l’option la plus transparente si vous souhaitez rester dans l’écosystème NGINX. Il existe d’ailleurs une documentation officielle pour migrer de Ingress-NGINX Controller à NGINX Ingress Controller. Mais ne vous recommandons pas cette option. Pour la simple raison que NGINX Ingress Controller traîne les mêmes casseroles conceptuelles que son presque-homonyme : snippets permissifs, surface d’attaque large, logique user space difficile à sécuriser…
  
  

🟩 Passer à Gateway API

C’est ce que préconise Kubernetes. Mais il va falloir se retrousser un peu les manches car cette migration depuis Ingress NGINX Controller vers un moteur plus pérenne ou vers Gateway API ne se fait pas en un claquement de doigts. On vous explique en détail ce qu’est Gateway API dans le paragraphe suivant.

Alors… évidemment, Kubernetes ne laisse personne en plan. Son plan de bataille, il existe depuis longtemps et il s’agit de Gateway API.

Concept lancé en 2020, stabilisé entre 2023 et 2024, largement adopté en 2025. Désormais, c’est la recommandation officielle.

Mais, alors, qu’est-ce que ça change ?

Là où Ingress NGINX Controller tenait sur une ressource unique et des milliers d’annotations, Gateway API a l’ambition de réécrire littéralement la grammaire du trafic Kubernetes : 

• Architecture multi-ressources (Gateway, GatewayClass, HTTPRoute, TCPRoute, GRPCRoute…)
• Séparation des rôles : réseau, sécurité, dev… chacun maîtrise son périmètre
• Extensibilité propre (plus de snippets NGINX cachés dans des annotations obscures)
• Sécurité by design
• Support multi-protocoles complet : HTTP, HTTPS, TCP, UDP, gRPC, WebSocket
• Multi-tenancy natif
• Standard universel, utilisé et supporté par tous les cloud providers

Et si vous préférez les comparaisons visuelles, voici un tableau comparatif entre Ingress et Gateway API : 

Dans un contexte où :
• Gateway API devient la cible long terme
• Ingress NGINX Controller disparaît
• Ingress reste supporté mais évolue peu

La meilleure option, c’est de transiter doucement depuis votre Ingress NGINX Controller vers Gateway API via Cilium.

Petit rappel : Cilium n’est pas seulement un CNI.
C’est aussi un load balancer eBPF, une plateforme d’observabilité (Hubble), un service mesh léger, et surtout un Gateway API controller mature basé sur Envoy.
Autrement dit : un stack réseau complet, conçu pour l’après-Ingress et déjà éprouvé.

Et si Cilium a beaucoup fait parler de lui ces derniers mois, ce n’est pas pour autant un phénomène de mode. Le projet existe depuis 2017, porté par Isovalent, soutenu par la CNCF et largement adopté par les plateformes cloud.

Pourquoi utiliser Cilium pour migrer vers Gateway API ?

1. Son implémentation Gateway API est native (basé sur Envoy)

L’intégration est propre, directe et conforme aux standards que Kubernetes fait émerger. On travaille avec l’API telle qu’elle a été pensée.

2. Des performances eBPF bien supérieures à NGINX

En réduisant le nombre de couches traversées par les paquets, Cilium diminue la latence, simplifie les chemins réseau. En plus d’une observabilité intégrée avec Hubble.

3. Plus sûr que la plupart des Ingress Controllers classiques

Cilium élimine les deux grandes faiblesses historiques des Ingress classiques : les annotations permissives et les proxies en user space. C’est l’autre avantage de l’eBPF : Cilium s’appuie sur une API stricte et fait exécuter sa logique réseau directement dans le kernel via eBPF, sans passer par des couches intermédiaires vulnérables.

4. Tout est centralisé

Cilium remplace :

• le CNI
• le load balancer
• l’Ingress Controller
• parfois même le service mesh

En bref : une seule brique à opérer, un seul point d’observabilité, un seul cycle de vie.

5. Un projet profondément impliqué dans SIG-Network

Enfin, Cilium est l’un des projets les plus actifs au sein de SIG-Network, le groupe de travail Kubernetes qui définit l’évolution du réseau. Ses équipes contribuent aux discussions, aux propositions de design et aux spécifications de Gateway API.

Oui, Cilium, notre chouchou, et pas seulement par amour de l’eBPF. Ce n’est pas un hasard si on l’a intégré dans notre architecture de référence Kubernetes.

L’objectif : pas de big bang.
La migration doit être progressive, service par service, sans downtime, sans stress inutile.

Voici la méthode que nos architectes DevOps recommandent : 

1. Installer/activer Cilium + Gateway API

Si Cilium n’est pas encore votre CNI :

cilium install --version 1.18.4 \
  --set gatewayAPI.enabled=true \
  --set kubeProxyReplacement=strict

Si Cilium est déjà installé : 

cilium upgrade --set gatewayAPI.enabled=true

2. Créer une Gateway Cilium

Votre nouveau portail d’entrée :

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cilium-gateway
spec:
  gatewayClassName: cilium
  listeners:
    - name: https
      protocol: HTTPS
      port: 443
      tls:
        mode: Terminate
        certificateRefs:
          - name: tls-cert

3. Migrer un Ingress vers une HTTPRoute

Ancien Ingress NGINX :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo

Nouvelle HTTPRoute : 

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: demo-route
spec:
  parentRefs:
    - name: cilium-gateway
  hostnames:
    - "example.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: demo-service
          port: 80

4. Faire cohabiter, tester, puis basculer complètement

C’est la magie de cette méthode : Ingress NGINX et Cilium Gateway coexistent parfaitement.

Ce qui permet :

• migration incrémentale
• A/B testing
• rollback immédiat
• pas de coupure de service

Une fois chaque route vérifiée :

kubectl delete ingress demo

Et seulement à la toute fin : 

helm uninstall ingress-nginx -n ingress-nginx

Ingress NGINX s’arrête.
Pas parce qu’il a échoué, mais parce qu’il a trop réussi.
Recette victime de son succès, comme on dit dans une célèbre enseigne.
Si vous utilisiez Ingress NGINX Controller, vous avez deux options solides à mettre en place avant mars 2026. Et nous, on vous conseille de passer par Cilium. Et si vous avez besoin d’un coup de main, on a du monde ici qui ne demande qu’à dégainer le Cilium CLI.

Méfait accompli.