Guides

Ingress-NGINX est abandonné : La route vers l’API Gateway

Kubernetes a archivé ingress-nginx en mars 2026 : plus de correctifs de sécurité. Voici comment migrer proprement vers l'API Gateway sans temps d'arrêt.

Par Alec Chizhik 24 juin 2026 7 min de lecture

Ingress-NGINX est abandonné : La route vers l’API Gateway

Le 24 mars 2026, le projet Kubernetes a archivé le dépôt d’ingress-nginx. Depuis lors, plus aucun correctif de bug ni patch de sécurité n’est disponible, précisément pour le contrôleur qui termine le trafic web de la plupart des clusters. Si vous y exécutez encore vos services, vous exploitez votre composant réseau le plus critique sans aucune maintenance.

Les points clés en bref

La fin de vie est une réalité : Depuis le 24 mars 2026, ingress-nginx est archivé, sans nouvelles fonctionnalités, sans correctifs, sans patches CVE. L’API Kubernetes Ingress sous-jacente reste disponible, mais pas le populaire contrôleur communautaire.
La Gateway API est la successeure toute désignée : La version 1.5.1 est stable, plusieurs contrôleurs conformes sont prêts à l’emploi, et l’outil ingress2gateway 1.0 convertit automatiquement plus de 30 annotations.
L’effort réside dans les cas particuliers : Le chemin standard est mécanique, mais les snippets d’authentification, l’affinité de session et les règles Canary doivent être reconstruits manuellement.

Pourquoi le temps est écoulé

L’annonce a été faite en novembre 2025 par la Kubernetes SIG Network et le Security Response Committee, un communiqué de suivi en janvier 2026 ayant clairement souligné la gravité de la situation. En mars 2026, la maintenance « best effort » a pris fin, et le dépôt GitHub a été archivé le 24 mars. Ne comptez pas sur une longue période de grâce pour temporiser : le support est bel et bien terminé.

Le problème réel ne réside pas dans l’absence de nouvelles fonctionnalités, mais dans la situation sécuritaire. De nouvelles vulnérabilités continuent d’être découvertes ; le débordement de tas NGINX-Rift de mai 2026 a également touché les versions archivées. Plus aucun correctif n’est disponible pour y remédier. De plus, l’utilisation d’un logiciel en fin de vie directement dans le plan de données Layer-7 génère automatiquement des écarts lors des audits SOC 2, PCI-DSS ou ISO 27001. Si vous avez besoin de preuves de conformité, un drapeau rouge est levé à ce niveau.

Une clarification s’impose, car les deux notions sont souvent confondues : l’API Kubernetes Ingress elle-même ne disparaît pas. Elle reste généralement disponible, mais son développement est gelé. Le travail actif a entièrement migré vers la Gateway API. Le contrôleur concerné est donc ingress-nginx, et non le concept d’Ingress en soi.

Qu’est-ce que la Gateway API ? La Gateway API est une norme Kubernetes pour le routage Layer-7, appelée à remplacer l’ancienne API Ingress. Elle sépare clairement les rôles entre l’équipe infrastructure et l’équipe application, décrit les routes de manière beaucoup plus expressive et est conçue dès l’origine pour le multi-locataire au sein d’un même cluster. Depuis 2026, elle constitue la voie officielle pour tout nouveau code réseau.

Aucun patch de sécurité n’a été publié depuis la fin de vie d’ingress-nginx le 24 mars 2026. Chaque nouvelle vulnérabilité dans le plan de données L7 reste définitivement ouverte.

Source : Kubernetes SIG Network, Security Response Committee

Trois chemins, un seul est le principal

Avant chaque équipe qui utilise encore ingress-nginx, trois options s’offrent. Elles diffèrent moins sur le plan technique que sur l’horizon temporel et sur la question de savoir combien de dette technique on est prêt à emporter.

Le premier chemin consiste à passer à la Gateway API. C’est la direction dans laquelle l’écosystème évolue, et pour la plupart des clusters, c’est l’interface la plus propre. Le deuxième chemin est le passage à un autre contrôleur d’ingress, comme Traefik, HAProxy, Envoy Gateway ou la version commerciale F5-NGINX. Cela permet de conserver l’API d’ingress familière, mais reporte simplement la décision stratégique. Le troisième chemin consiste à acheter un support commercial de sécurité pour la version archivée, proposé par des tiers. Cela gagne du temps pour un déménagement ordonné, mais ne résout pas le problème fondamental.

Pour les nouvelles plateformes et pour tous ceux qui envisagent déjà une modernisation, le choix se porte sur la Gateway API. La comparaison suivante montre pourquoi c’est ainsi et où les compromis réels se situent.

Ce qui plaît à la Gateway API

Trajectoire officielle de développement, toutes les nouvelles fonctionnalités y sont intégrées
Séparation claire entre infrastructure et application
Routes plus expressives sans prolifération anarchique d’annotations
Portabilité à travers les contrôleurs conformes

Ce qui reste problématique

Les annotations propres ne correspondent pas toutes à 100 %
L’équipe doit apprendre un second modèle de ressources
L’observabilité et les tableaux de bord nécessitent un nouveau câblage
Maturité des contrôleurs variable selon les fonctionnalités

La migration en cinq étapes

La bonne partie d’abord : pour le cas standard, le déménagement est aujourd’hui mécanique. Depuis le 20 mars 2026, il existe ingress2gateway en version 1.0, un outil stable de la SIG Network qui traduit les définitions existantes d’Ingress ainsi que plus de 30 annotations courantes en objets Gateway et HTTPRoute. Le processus suivant maintient une interruption totale du service, si l’on suit cette séquence.

Chemin de migration sans interruption

Étape 1

Inventaire du patrimoine. Recueillir tous les objets Ingress et leurs annotations. La liste des cas spécifiques déterminera ultérieurement l’effort nécessaire, pas le nombre de routes.

Étape 2

Installer les CRDs. Déployer les ressources de l’API Gateway depuis le canal standard en version 1.5.1. Cela ne change rien au trafic, mais installe simplement le vocabulaire.

Étape 3

Choisir et déployer un contrôleur. Mettre en place un contrôleur conforme comme Envoy Gateway en parallèle du contrôleur existant ingress-nginx. Deux chemins de données côte à côte, encore sans commutation.

Étape 4

Convertir avec ingress2gateway. Exécuter l’outil via les fichiers YAML d’Ingress, il génère des objets Gateway et HTTPRoute. Vérifier la sortie, ne pas appliquer aveuglément, surtout pour ses propres annotations.

Étape 5

Commuter progressivement le trafic. Déplacer les routes une à une ou via DNS pondéré vers le nouveau chemin, surveiller, puis désactiver le contrôleur ancien. Seul lorsque plus rien ne pointe vers ingress-nginx, la migration est terminée.

Où les détails se bloquent

Les cinq étapes semblent fluides, et pour une plateforme dotée de règles d’Ingress propres et génériques, elles le sont aussi. La friction apparaît là où les équipes ont accumulé, sur plusieurs années, des annotations spécifiques à ingress-nginx. Ces endroits précis ne sont pas entièrement traduits par aucun outil.

Les principales difficultés peuvent être anticipées dès maintenant. Les snippets d’authentification et l’authentification externe doivent être réécrits dans la mécanique des filtres de l’API Gateway. Les sessions sticky et l’affinité de session sont modélisées différemment que via les anciennes annotations de cookies. Les déploiements canaries, qui fonctionnaient auparavant via des annotations, migrent vers des règles HTTPRoute pondérées. Et tout ce qui était lié à des snippets personnalisés ou à une configuration NGINX intégrée n’a, dans le nouveau monde, aucun équivalent direct. C’est ainsi voulu et n’est pas un manque de la part de l’API Gateway.

Il y a cependant aussi un gain qui se révèle seulement en production. La séparation des rôles de l’API Gateway permet à une équipe de plateforme de posséder le gateway, tandis que les équipes applicatives n’ont qu’à créer leurs propres routes, sans toucher à l’infrastructure commune. Qui doit effectuer la migration, peut en profiter pour nettoyer enfin ces responsabilités. Une obligation imposée devient ainsi un morceau de hygiène de plateforme, que l’on n’aurait jamais priorisé autrement.

Foire aux questions

Dois-je migrer immédiatement, ou ingress-nginx continue-t-il simplement de fonctionner ?

Techniquement, la dernière version continue de fonctionner, elle ne disparaît pas du cluster. Cependant, elle ne reçoit plus de mises à jour de sécurité. Chaque nouvelle faille reste ouverte, et lors des audits de conformité, un logiciel en fin de vie dans le chemin de données est considéré comme une anomalie. Le bon moment pour la migration était donc hier plutôt que demain.

L’API Kubernetes Ingress elle-même est-elle conservée ?

Oui. L’API Ingress reste disponible de manière générale, mais elle est gelée sans nouvelles fonctionnalités. Seul le contrôleur communautaire ingress-nginx est abandonné. Ceux qui souhaitent conserver l’API Ingress peuvent passer à un autre contrôleur, comme Traefik ou HAProxy.

Que fait exactement l’outil ingress2gateway ?

Il lit les définitions Ingress existantes et génère à partir de celles-ci des objets Gateway et HTTPRoute. La version 1.0 prend en charge plus de 30 annotations ingress-nginx courantes. Pour le cas standard, la conversion est mécanique, mais il convient tout de même de vérifier la sortie générée avant de l’appliquer.

Quels contrôleurs constituent une alternative à l’API Gateway ?

Ceux qui ne souhaitent pas passer au nouveau modèle peuvent remplacer ingress-nginx par Traefik, HAProxy, Envoy Gateway ou la variante commerciale F5-NGINX. Ceux-ci conservent l’API Ingress familière. Toutefois, la décision fondamentale n’est ainsi que repoussée.

Comment maintenir le temps d’arrêt à zéro lors de la bascule ?

La clé est le fonctionnement en parallèle. Laissez le nouveau contrôleur s’exécuter à côté d’ingress-nginx, déplacez le trafic route par route ou de manière pondérée via le DNS, tout en observant le processus. Ce n’est que lorsqu’il n’y a plus de charge sur l’ancien chemin qu’ingress-nginx est démantelé.

Plus d’articles du réseau MBF Media

Plus du réseau MBF Media

MyBusinessFutureL’IA dans les PME : le goulot d’étranglement se situe dans les anciens systèmes Digital ChiefsLa géopolitique rencontre la feuille de route des datacenters : ce que les DSI doivent sécuriser dès maintenant SecurityTodaySécurité des API : l’angle mort derrière chaque intégration

Source de l’image : générée par IA (Juli 2026)

Aussi disponible en

Español English Deutsch