Retrait d'Ingress NGINX : votre guide de migration Kubernetes

Le retrait d’Ingress NGINX n’est plus quelque chose que les equipes de plateforme peuvent laisser dans le backlog. Si vos clusters en dependent encore, mars 2026 est une echeance operationnelle ferme, pas un rappel leger. Le vrai risque n’est pas que vos charges de travail s’arretent instantanement. Le vrai risque est qu’elles continuent de fonctionner sur un composant de bordure non maintenu, ce qui est exactement le type d’exposition qui transforme une decision de plateforme de routine en un incident urgent plus tard.

C’est pourquoi cette migration doit etre traitee comme de l’ingenierie de trafic de production, pas comme un exercice de conversion de manifestes. Vous devez savoir ou Ingress NGINX fonctionne, quels comportements vos applications utilisent silencieusement, quel modele de remplacement convient a votre environnement et comment valider la bascule sans surprendre les utilisateurs.

Ce qui est retire et quand

Selon l’annonce du projet Kubernetes, Ingress NGINX est mis a la retraite le 31 mars 2026, apres quoi il n’y aura plus de nouvelles versions, de corrections de bugs ou de mises a jour de securite (blog Kubernetes). Les deploiements existants continueront de fonctionner, et les artefacts d’installation comme les charts Helm et les images de conteneurs resteront disponibles, mais “fonctionne encore” n’est pas la meme chose que “encore supporte.” Les comites de direction et de reponse de securite de Kubernetes ont publie une declaration de suivi renforcant l’urgence.

Cette distinction est importante car de nombreuses equipes ne ressentiront pas de douleur immediate. Le trafic peut continuer a couler. Les tableaux de bord peuvent rester verts. Rien d’evident ne peut casser le premier jour. Mais le composant ne recevra plus de correctifs pour les vulnerabilites nouvellement decouvertes, et cela change immediatement le profil de risque.

La premiere etape pratique est de confirmer si vous l’utilisez reellement. Dans de nombreux environnements, cela signifie inventorier les clusters, les namespaces, les releases Helm et les classes ingress plutot que de supposer qu’une offre geree plus recente l’a remplace partout.

Une simple conversation de migration devrait commencer par quatre questions :

1. ou Ingress NGINX fonctionne-t-il aujourd’hui
2. quelles applications en dependent encore
3. quelles annotations ou comportements personnalises sont utilises
4. quel controleur ou modele d’API le remplacera

Si vous ne pouvez pas repondre proprement a ces questions, vous n’etes pas pret a basculer en toute securite.

Risques de rester sur Ingress NGINX

La plus grande erreur que les equipes peuvent faire est de traiter le retrait comme une depreciation ordinaire. Ce n’est pas juste un avertissement qu’une fonctionnalite sera moins a la mode l’annee prochaine. C’est un probleme de securite et d’operations.

Apres le retrait, rester sur Ingress NGINX signifie :

• plus de corrections de bugs futures
• plus de correctifs de securite
• plus de mises a jour officielles d’aucune sorte
• une derive de plateforme croissante par rapport au reste de l’ecosysteme Kubernetes
• plus de risque operationnel a chaque changement d’infrastructure environnante

Le danger cache est que les deploiements existants continueront souvent a fonctionner assez bien pour eviter l’attention. Cela cree un faux sentiment de securite. Un composant de bordure non supporte reste un composant de bordure, et les composants de bordure tendent a avoir des consequences elevees lorsqu’ils echouent ou sont exposes.

Il y a aussi un risque de planification. Kubernetes a ete explicite que les alternatives disponibles ne sont pas des remplacements directs plug-and-play. Si votre plan de migration suppose que vous pouvez echanger un controleur a la derniere minute avec zero revue de comportement, vous sous-estimez presque certainement le travail.

C’est pourquoi la bonne mentalite n’est pas “remplacer un controleur ingress.” C’est re-modeliser l’entree de trafic, le comportement de routage et la propriete de plateforme.

Gateway API vs autres options de controleur

La plupart des equipes ont deux chemins realistes.

Migrer vers Gateway API

Gateway API est la direction moderne que Kubernetes pousse pour le reseau de services. Elle est plus expressive que l’Ingress classique, plus structuree et concue autour de roles organisationnels plus clairs. Au lieu d’empiler des comportements specifiques a l’implementation dans des annotations, elle donne aux equipes de plateforme un modele plus explicite avec des ressources comme GatewayClass, Gateway et HTTPRoute.

C’est generalement le meilleur choix a long terme quand vous voulez :

• une separation plus propre des responsabilites
• une configuration de routage plus portable
• une meilleure gouvernance multi-equipes
• des fonctionnalites de routage de trafic plus riches
• un standard de plateforme oriente vers l’avenir

Gateway API est particulierement convaincante si votre equipe de plateforme pense deja a une politique de trafic plus avancee, a la propriete partagee de gateway ou aux patterns de trafic IA et d’inference. Si c’est dans votre feuille de route, notre guide Kubernetes pour les charges de travail IA est un bon suivi car la gestion moderne du trafic devient encore plus importante une fois que l’inference et les charges de travail multi-locataires entrent en jeu.

Rester sur l’API Ingress mais changer de controleur

C’est souvent le chemin a court terme le plus rapide. Si votre objectif est de reduire rapidement le risque de retrait tout en minimisant les changements au niveau applicatif, un autre controleur ingress supporte peut etre le pont plus pratique.

Cette option peut avoir du sens quand :

• votre modele de trafic est encore relativement simple
• vos equipes dependent fortement de l’API Ingress aujourd’hui
• vos proprietaires d’applications ne sont pas prets pour des changements de modele de routage plus larges
• votre calendrier de migration est serre

Le compromis est que vous pouvez eviter le probleme de retrait de mars 2026 sans obtenir les benefices a plus long terme de Gateway API. Pour certaines organisations, c’est quand meme la bonne decision. La vitesse et la supportabilite comptent.

Le vrai cadre de decision

Ne cadrez pas cela comme “Lequel est techniquement le plus cool ?” Cadrez-le comme :

• Combien de portabilite de comportement avons-nous besoin ?
• Combien de changement les equipes applicatives peuvent-elles absorber maintenant ?
• Combien de dette d’annotations avons-nous ?
• Avons-nous besoin d’un modele de trafic moderne oriente par roles ?
• Resolvons-nous pour le prochain trimestre ou les trois prochaines annees ?

Cela vous donne une meilleure reponse que de copier ce qu’une autre entreprise a publie sur les reseaux sociaux.

Cinq comportements que les equipes negligent avant la migration

C’est la ou de nombreuses migrations echouent. Convertir des manifestes est la partie facile. Preserver le comportement du trafic est la partie difficile.

Kubernetes a deja mis en evidence plusieurs comportements d’Ingress NGINX qui surprennent les equipes pendant la migration. Meme une traduction de manifeste “reussie” peut casser la production si vous ne les prenez pas en compte.

1. Le comportement des regex peut etre plus large que vous ne pensez

Ingress NGINX peut traiter les chemins comme des expressions regulieres d’une facon inattendue par les equipes, surtout lorsque certaines annotations sont presentes. Si vous migrez vers Gateway API ou un autre controleur et supposez que le comportement exact ou prefixe sera le meme, vous pouvez casser le routage.

2. use-regex peut affecter plus qu’une seule regle de chemin

Un comportement particulierement dangereux est que nginx.ingress.kubernetes.io/use-regex: "true" peut affecter tous les chemins pour un hote a travers les ingresses Ingress NGINX, pas seulement la regle ou vous l’avez remarque en premier. Cela signifie que des fautes de frappe ou des hypotheses qui semblaient inoffensives peuvent en fait faire partie de votre comportement de trafic actuel.

3. Les regles de reecriture peuvent impliquer silencieusement une correspondance regex

L’annotation rewrite-target peut effectivement introduire un comportement de type regex meme si vous n’avez pas explicitement pense a la route comme basee sur les regex. Les equipes decouvrent souvent cela seulement lorsque les routes migrees deviennent plus strictes et que des requetes precedemment acceptees commencent a retourner 404.

4. Les redirections de barre oblique finale peuvent disparaitre

Ingress NGINX peut rediriger les requetes sans barre oblique finale vers le chemin avec barre oblique. Les implementations conformes de Gateway API n’ajoutent pas silencieusement cette redirection pour vous. Si des clients ou des systemes en aval dependent de ce comportement, la migration peut creer une casse subtile.

5. La normalisation d’URL peut changer les resultats de correspondance

Ingress NGINX normalise les URLs avant la correspondance et le routage. Si vos applications dependent de ce comportement, un nouveau controleur ou une implementation Gateway API peut traiter des requetes d’apparence equivalente differemment a moins que vous ne recreiez le comportement voulu explicitement.

La lecon cle est simple : votre comportement de routage de production n’est pas seulement ce que votre YAML dit. C’est aussi ce que votre controleur fait reellement avec ce YAML.

Validation, rollback et observabilite

Une migration sure necessite trois choses : de la visibilite avant le changement, une bascule controlee pendant le changement et un rollback rapide si la realite ne correspond pas au plan.

Valider le comportement, pas seulement la syntaxe

Il ne suffit pas que les manifestes s’appliquent proprement. Vous devez tester :

• la correspondance exacte des chemins
• le routage par prefixe
• le comportement des regex
• les reecritures
• les redirections
• la terminaison TLS
• la gestion des en-tetes
• les health checks
• le comportement de bordure lie a l’authentification
• les reponses d’echec

Si possible, capturez les patterns de requetes en direct avant la migration et rejouez un trafic representatif dans un environnement inferieur. Cela vous donne un bien meilleur signal que de tester manuellement deux ou trois URLs.

Planifier le rollback avant la bascule

Le rollback devrait faire partie de la premiere reunion de conception de la migration, pas quelque chose que vous improvisez apres que le changement commence a echouer.

Un vrai plan de rollback devrait definir :

• ce qui est rebascule
• quels changements DNS ou de load balancer doivent etre inverses
• combien de temps prend le rollback
• qui a l’autorite de le declencher
• quelles donnees ou changements de configuration sont irreversibles

Si vous ne pouvez pas decrire le rollback en cinq minutes, il n’est probablement pas pret.

Ameliorer l’observabilite avant la migration

Les equipes attendent souvent la semaine de migration pour regarder l’observabilite au niveau de l’ingress. C’est trop tard.

Avant la bascule, assurez-vous d’avoir une bonne visibilite sur :

• le volume de requetes
• les changements de codes de statut
• les percentiles de latence
• les echecs TLS
• les changements de trafic au niveau des routes
• la sante des backends
• le volume de redirections
• les pics d’erreurs par chemin ou hote

Vous ne voulez pas que votre premier indice soit un message Slack d’une equipe orientee client. Les migrations sont plus faciles quand vous pouvez voir le comportement au niveau des routes immediatement et comparer les anciens et les nouveaux patterns en quasi temps reel.

La visibilite securitaire compte aussi. La bordure fait partie de votre frontiere de confiance, c’est une raison pour laquelle une migration comme celle-ci devrait etre examinee en meme temps que votre strategie d’architecture Zero Trust, pas traitee uniquement comme une corvee de reseau.

Un plan de migration phase

Les meilleurs plans de migration d’Ingress NGINX sont phases, ennuyeux et hautement intentionnels. C’est une bonne chose.

Phase 1 : Inventorier et classifier

Commencez par cataloguer chaque cluster et application utilisant Ingress NGINX. Regroupez les charges de travail par criticite du trafic, complexite et utilisation des annotations.

A cette etape, cherchez :

• les annotations personnalisees
• les chemins regex
• les regles de reecriture
• les redirections
• les noms d’hotes partages
• les patterns de gateway multi-locataires
• les integrations d’authentification et WAF
• les CRDs ou sidecars specifiques au controleur

Si vous voulez migrer vers Gateway API, c’est aussi le moment ou des outils comme ingress2gateway peuvent aider a traduire les ressources, mais la traduction doit etre traitee comme un accelerateur, pas comme une preuve de justesse.

Phase 2 : Choisir le modele cible

Decidez quelles charges de travail devraient migrer vers Gateway API en premier et lesquelles peuvent avoir besoin d’un remplacement de controleur intermediaire. Chaque application n’a pas besoin du meme chemin.

Un pattern courant est :

• applications internes simples d’abord
• applications externes non critiques ensuite
• applications complexes ou riches en annotations plus tard
• bordure partagee et trafic critique pour le metier en dernier

Cela donne a l’equipe de plateforme le temps d’apprendre sans parier sur le trafic le plus sensible en premier.

Phase 3 : Construire une matrice de comportement

Pour chaque application ou groupe de routes, documentez :

• les chemins attendus
• les redirections
• les reecritures
• les exigences d’authentification
• le comportement TLS
• les en-tetes et cookies
• les attentes de sante du backend
• les conditions d’echec

Cela devient le contrat que vous validez avant et apres la bascule.

Phase 4 : Executer des tests en parallele

La ou c’est possible, executez le modele cible en parallele et comparez le comportement. Cela peut signifier du trafic en miroir, des noms d’hotes alternatifs, des points d’entree canary ou des bascules par etapes par environnement.

C’est dans cette phase que les surprises deviennent visibles tandis que le rayon d’explosion est encore petit.

Phase 5 : Basculer par vagues

Passez par vagues controlees avec des metriques de succes claires, des declencheurs de rollback et une propriete dediee. Ne combinez pas la migration ingress avec cinq changements de plateforme sans rapport dans la meme fenetre.

Phase 6 : Supprimer les anciennes dependances

Une fois le trafic stable, supprimez les classes ingress obsoletes, les releases Helm, les configurations de controleur et les hypotheses d’equipe qui pointent encore vers Ingress NGINX. Une migration n’est pas terminee tant que la dependance n’est pas reellement partie.

Telechargez une fiche d’inventaire de migration de cluster

Le retrait d’Ingress NGINX est urgent, mais l’urgence n’est pas une raison pour se precipiter aveuglément. Les equipes qui migrent bien traiteront cela comme un projet de comportement du trafic, un projet de gouvernance de plateforme et un projet d’exposition securitaire tout a la fois.

La prochaine etape la plus pratique est de construire une fiche d’inventaire de migration de cluster qui capture chaque classe ingress, nom d’hote, annotation, reecriture, redirection, dependance TLS et proprietaire de rollback en un seul endroit. Ce document sera plus precieux qu’une declaration generique “nous devrions passer a Gateway API”.

Obtenez la fiche gratuite d’inventaire de migration de cluster →

A partir de la, associez votre travail de migration a notre guide Kubernetes pour les charges de travail IA, notre feuille de route de securite de la chaine d’approvisionnement logicielle, et notre guide d’architecture Zero Trust afin que votre migration de bordure renforce la plateforme plus large au lieu de simplement remplacer un composant vieillissant par un autre.