Fin d’Ingress-NGINX : migration vers Gateway API
Depuis mars 2026, Ingress-NGINX est officiellement arrivé à la fin de sa vie utile. Plus aucune correction, plus aucune mise à jour de sécurité, plus aucun correctif de bogues. Le projet Kubernetes …
Depuis mars 2026, Ingress-NGINX est officiellement arrivé à la fin de sa vie utile. Plus aucune correction, plus aucune mise à jour de sécurité, plus aucun correctif de bogues. Le projet Kubernetes a mis à la retraite le contrôleur d’entrée (Ingress Controller) le plus utilisé au monde. Environ la moitié de toutes les environnements cloud-native sont concernés. Celui qui ne migre pas maintenant exploite des charges de travail exposées à Internet avec un composant abandonné.
L’essentiel
- 🚨 Ingress-NGINX est en fin de vie depuis mars 2026. Aucune mise à jour de sécurité n’est plus fournie (projet Kubernetes, 11 novembre 2025).
- 📊 Environ 50 % de tous les environnements cloud-native utilisent Ingress-NGINX (Comité directeur Kubernetes, 29 janvier 2026).
- ✅ Gateway API v1.4 est le successeur officiel. Prêt pour la production depuis octobre 2025 (CNCF).
- 🔄 Traefik, HAProxy et F5 NGINX Ingress Controller sont des alternatives éprouvées issues de la communauté.
- 🏢 KubeCon Europe 2026 à Amsterdam (23-26 mars) fait de la migration un thème obligatoire pour les équipes plateforme.
Ce qui s’est produit – et pourquoi l’action est urgente
Le 11 novembre 2025, le projet Kubernetes a publié un billet de blog annonçant la fin de vie d’Ingress-NGINX. Ce contrôleur, standard depuis des années pour le routage HTTP dans les clusters Kubernetes, ne recevra plus aucune mise à jour à compter de mars 2026. Le dépôt GitHub deviendra en lecture seule et sera transféré vers l’organisation « kubernetes-retired ».
Ce que cela signifie concrètement : chaque nouvelle CVE détectée dans NGINX ou dans la logique du contrôleur restera sans correctif. Pour un contrôleur directement exposé à Internet et chargé de router l’intégralité du trafic entrant d’un cluster, il s’agit d’un risque de sécurité réel.
Le 29 janvier 2026, le Comité directeur Kubernetes et le Comité de réponse aux incidents de sécurité ont renforcé cette annonce. Dans un communiqué officiel, ils ont chiffré la portée du phénomène : environ 50 % de tous les environnements cloud-native utilisent Ingress-NGINX (source : recherche Datadog). La recommandation est claire : évaluer Gateway API comme successeur officiel, planifier la migration – et ne pas attendre.
Gateway API : le successeur officiel
La communauté Kubernetes prépare ce remplacement depuis plusieurs années. Gateway API n’est pas simplement un nouveau contrôleur d’entrée, mais un concept fondamentalement différent. Plutôt qu’une seule ressource `Ingress` accompagnée d’annotations, on dispose désormais de ressources distinctes pour l’infrastructure (GatewayClass, Gateway) et le routage (HTTPRoute, GRPCRoute, TCPRoute).
Depuis octobre 2025, Gateway API v1.4.0 est en statut « General Availability ». Les ressources GatewayClass, Gateway et HTTPRoute sont stables et prêtes pour la production. Il ne s’agit plus d’une version bêta. Des entreprises telles que Google, Red Hat et VMware utilisent déjà Gateway API dans leurs offres gérées de Kubernetes.
L’avantage décisif : une configuration basée sur les rôles. Les administrateurs de cluster définissent l’infrastructure Gateway, tandis que les équipes de développement configurent leurs propres routes de façon indépendante. Avec Ingress-NGINX, tout reposait sur une seule ressource comportant des centaines d’annotations, comprises par très peu de personnes dans l’équipe.
Les trois meilleures alternatives comparées
Gateway API constitue le choix stratégique idéal. Mais toutes les équipes ne peuvent pas migrer immédiatement. Selon la configuration du cluster, les annotations utilisées et les intégrations existantes, les chemins de migration diffèrent.
Traefik a été l’un des premiers contrôleurs à implémenter pleinement le support de Gateway API v1.4. Pour ceux qui utilisent déjà Traefik comme proxy inverse, la migration peut se faire avec un effort minimal. Traefik Labs propose une procédure détaillée de migration, avec un mappage étape par étape des annotations Ingress vers les ressources Gateway API.
F5 NGINX Ingress Controller est un fork commercial soigneusement maintenu. Pour ceux qui souhaitent rester sur NGINX sans dépendre du support communautaire, c’est la solution nécessitant le moins de modifications. La configuration est quasi identique ; seuls l’espace de noms et les charts Helm changent. L’inconvénient : verrouillage fournisseur (vendor lock-in) et coûts de licence.
HAProxy Ingress Controller est le remplaçant le plus stable et le plus proche d’un « 1:1 » pour les équipes recherchant un contrôleur léger et éprouvé. HAProxy Technologies maintient activement ce contrôleur et a inscrit le support de Gateway API à sa feuille de route.
Planifier la migration : 5 étapes pour les équipes plateforme
Migrer d’Ingress-NGINX n’est pas un projet de week-end. Les équipes plateforme doivent procéder de façon structurée.
Étape 1 : Inventaire initial. Répertorier toutes les ressources `Ingress` présentes dans le cluster. Quelles annotations sont utilisées ? Quelles configurations personnalisées sont stockées dans des ConfigMaps ? Des outils tels que Fairwinds Insights peuvent aider à évaluer l’ampleur de la migration.
Étape 2 : Choisir le contrôleur cible. Gateway API pour les projets nouveaux (Greenfield) et la stratégie à long terme. Traefik ou F5 NGINX pour les équipes devant migrer rapidement et souhaitant conserver autant que possible leurs manifests Ingress existants.
Étape 3 : Exécution parallèle. Installer le nouveau contrôleur à côté d’Ingress-NGINX. Rediriger progressivement le trafic, route par route. Ne pas basculer l’intégralité du trafic d’un seul coup.
Étape 4 : Adapter la supervision. Les métriques Prometheus spécifiques à Ingress-NGINX (`nginx_ingress_controller_*`) n’existent plus dans le nouveau contrôleur. Les tableaux de bord et les alertes doivent être reconstruits autour des nouvelles métriques.
Étape 5 : Désinstaller Ingress-NGINX. Uniquement lorsque toutes les routes auront été migrées et que le nouveau contrôleur fonctionnera de façon stable. Pas avant. Le fonctionnement parallèle à long terme double la surface d’attaque.
Pièges courants lors de la migration
Les problèmes les plus fréquents liés à la migration d’Ingress-NGINX ne concernent pas le contrôleur lui-même, mais plutôt l’écosystème qui l’entoure.
Annotations sans équivalent. Ingress-NGINX comporte plus de 100 annotations, couvrant des fonctions allant de la limitation de débit (rate limiting) au partage de ressources entre origines (CORS), en passant par les en-têtes personnalisés. Toutes n’ont pas d’équivalent direct dans Gateway API. Les équipes doivent vérifier quelles annotations sont effectivement utilisées et si la fonctionnalité correspondante est implémentée différemment dans le nouveau contrôleur.
Intégration avec cert-manager. De nombreuses équipes utilisent cert-manager avec Ingress-NGINX pour obtenir automatiquement des certificats TLS. Depuis la version 1.15, cert-manager prend nativement en charge Gateway API. La migration est généralement simple, mais les ressources Gateway nécessitent des labels différents de ceux des ressources Ingress.
External-DNS. Pour ceux qui utilisent External-DNS afin de générer automatiquement des entrées DNS, il faut vérifier si la version déployée est capable de reconnaître les ressources Gateway API. Les versions anciennes d’External-DNS ne traitent que les objets `Ingress`.
Pages d’erreur personnalisées et extraits de configuration (snippets). Ingress-NGINX autorise l’insertion d’extraits de configuration NGINX personnalisés via des annotations. Cette fonctionnalité est puissante, mais aussi un risque de sécurité. Gateway API n’offre délibérément aucune fonctionnalité équivalente. Les équipes utilisant ces snippets doivent déplacer cette logique soit directement dans le contrôleur, soit dans des middlewares.
Pourquoi le projet Kubernetes a abandonné Ingress-NGINX
La fin de vie d’Ingress-NGINX n’est pas un échec technique, mais une rationalisation stratégique. Ce contrôleur avait été lancé en 2016 comme implémentation de référence, puis était devenu, au fil des ans, la norme de facto. Or, précisément cette popularité est devenue un problème : plus de 100 annotations, une répartition floue des rôles, et une base de code devenue de plus en plus difficile à maintenir à chaque mise à jour de NGINX.
S’y sont ajoutés des incidents de sécurité. En octobre 2025, le Comité de réponse aux incidents de sécurité de Kubernetes a publié un rapport sur plusieurs vulnérabilités critiques dans le webhook d’admission d’Ingress-NGINX. La combinaison d’une forte pénétration, d’une base de code complexe et d’une capacité de maintenance en diminution a rendu la fin de vie inévitable.
Pour l’écosystème Kubernetes, il s’agit d’une évolution saine. Gateway API ne remplace pas seulement Ingress-NGINX, mais l’ensemble du concept d’Ingress. À la place d’annotations spécifiques à un fournisseur, on dispose désormais de ressources standardisées que tout contrôleur peut implémenter. Cela réduit le verrouillage fournisseur et rend le réseau Kubernetes plus portable.
Ce que les entreprises DACH doivent prioriser dès maintenant
Les secteurs réglementés en Allemagne, en Autriche et en Suisse subissent une pression particulière. Les entreprises soumises à la directive NIS2 doivent pouvoir démontrer que leur infrastructure informatique est activement maintenue. Un contrôleur d’entrée sans support de sécurité constitue un risque de non-conformité documentable.
Les prestataires de services financiers et les établissements de santé doivent donner la priorité à cette migration. La preuve d’un entretien actif des composants fait partie de la documentation de la chaîne logistique exigée par NIS2. Si une entreprise exploite, lors d’un audit, un composant en fin de vie sur son périmètre Internet, elle devra justifier ce choix.
Les PME dotées de petites équipes plateforme tireront particulièrement profit de Traefik ou de F5 NGINX comme solution intermédiaire. La migration vers Gateway API pourra alors intervenir ultérieurement, une fois les capacités et les compétences nécessaires acquises.
KubeCon Europe 2026 : la migration devient un thème obligatoire
Le 23 au 26 mars 2026 se tiendra la KubeCon Europe à Amsterdam. La migration d’Ingress-NGINX domine l’ordre du jour des pistes consacrées à l’ingénierie plateforme. Pour les équipes qui n’ont pas encore migré, la conférence proposera des ateliers pratiques (hands-on) et des retours d’expérience d’entreprises ayant déjà mené à bien cette transition.
Ceux qui ne se rendront pas à Amsterdam : les présentations sont généralement publiées sous forme d’enregistrements sur YouTube dans les quatre semaines suivant la conférence. Mais attendre n’est pas une stratégie. Chaque jour sans mise à jour de sécurité est un jour de risque accru.
Conclusion
Ingress-NGINX a longtemps été la référence. Cette ère est révolue. Sa fin de vie n’est pas une surprise, mais le résultat d’une décision délibérée de la communauté Kubernetes en faveur de Gateway API. Celui qui n’agit pas maintenant exploite un composant critique pour la sécurité sans aucun support.
La voie pragmatique : Gateway API pour les nouveaux projets et comme objectif stratégique. Traefik ou F5 NGINX comme solutions transitoires pour les équipes devant réagir rapidement. Fonctionnement parallèle, migration progressive, puis suppression complète d’Ingress-NGINX.
La question n’est plus « si », mais « à quelle vitesse ».
Questions fréquentes
Que se passe-t-il si je continue à utiliser Ingress-NGINX ?
Techniquement, cela continuera de fonctionner, mais vous ne recevrez plus aucune mise à jour de sécurité. Chaque nouvelle vulnérabilité découverte dans NGINX ou dans le code du contrôleur restera sans correctif. Pour des charges de travail exposées à Internet, cela représente un risque croissant.
Combien de temps prend la migration vers Gateway API ?
Cela dépend du nombre de ressources `Ingress` et des annotations utilisées. Pour de petits clusters avec 10 à 20 routes, la migration peut être réalisée en une à deux semaines. Pour des configurations importantes comportant des snippets personnalisés et des règles de routage complexes, comptez quatre à huit semaines.
Puis-je exécuter Gateway API et Ingress-NGINX en parallèle ?
Oui, et c’est même recommandé. Installez le nouveau contrôleur en parallèle, migrez route par route, puis supprimez Ingress-NGINX uniquement lorsque toutes les routes fonctionnent de façon stable.
Traefik est-il meilleur que Gateway API ?
Traefik est une implémentation, Gateway API est une spécification. Traefik prend pleinement en charge Gateway API v1.4. Vous pouvez utiliser Traefik comme contrôleur tout en exploitant les ressources Gateway API. Ces deux éléments ne s’excluent pas mutuellement.
Quel est le coût du F5 NGINX Ingress Controller ?
F5 propose le NGINX Ingress Controller dans une version open source gratuite et une version commerciale « Plus ». Cette dernière nécessite une licence NGINX Plus, dont le prix dépend du nombre d’instances déployées.
Articles complémentaires
- Gouvernance des clusters Kubernetes dans les PME – Pourquoi le contrôle devient plus important que la montée en échelle (cloudmagazin)
- Certificats TLS en 2026 – Pourquoi une durée de validité de 200 jours marque la fin de la gestion manuelle (cloudmagazin)
- Identité cloud-native – OAuth 2.1, clés de passe (passkeys) et l’avenir de l’authentification (cloudmagazin)
Plus d’articles du réseau média MBF Media
- Vérification pratique des SBOM – Comment votre entreprise met en œuvre la nomenclature logicielle (SecurityToday)
- Rapatriement dans le cloud (Cloud Repatriation) 2026 – Pourquoi les DSI ramènent des charges de travail (Digital Chiefs)
Source de l’image : Brett Sayles / Pexels
Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.
