Après l'arrêt d'ingress-nginx : valider une migration parallèle vers Gateway API

Ce que c'est

État au 25 octobre 2026 : l'avis d'arrêt d'Ingress NGINX de la communauté Kubernetes fixait à mars 2026 la fin de la maintenance assurée au mieux des moyens disponibles, sans nouvelles versions, corrections de bogues ni mises à jour de sécurité ensuite. Les déploiements existants et les artefacts d'installation restent utilisables. Vérifier de nouveau l'avis d'arrêt et la documentation de prise en charge et de conformité du contrôleur de remplacement choisi avant de planifier un changement. Cela concerne le projet communautaire ingress-nginx ; identifier le contrôleur réellement utilisé au lieu de classer de la même manière tout ce qui porte le nom NGINX. Avis d'arrêt.

Pourquoi c'est important

Une image disponible ou un point de terminaison fonctionnel ne démontre pas que la maintenance se poursuit. Gateway API modifie le modèle de configuration : un Gateway décrit les points d'entrée, tandis qu'HTTPRoute décrit le routage applicatif. Les annotations propres au contrôleur nécessitent une correspondance explicite. Le guide général de migration explique la conversion, mais précise qu'il ne fournit pas de procédure complète de migration en fonctionnement. Modèle de migration.

La procédure par étapes suivante est une proposition de plan opérationnel. Ses critères de recette doivent couvrir les exigences existantes de l'application en matière de routage et de sécurité.

Comment l'appliquer

• Recenser les contrôleurs dans chaque cluster dont l'inspection est autorisée. L'avis d'arrêt suggère kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx. Examiner aussi les déploiements et les images des contrôleurs : une requête par étiquette seule ne permet pas d'exclure la présence d'installations renommées ou personnalisées. Consigner les ressources Ingress, les classes, les annotations, les références TLS et la configuration du contrôleur.

• Choisir une implémentation Gateway API maintenue dont la conformité et la prise en charge des extensions couvrent les fonctionnalités requises. Attribuer la responsabilité des points d'entrée et des routes. Le guide d'accueil officiel prévoit l'exécution du nouveau contrôleur aux côtés d'ingress-nginx avec une adresse IP externe différente ; préparer donc un point de terminaison distinct pour la validation avant de modifier le trafic public. Guide de migration parallèle.

• Avec une installation d'ingress2gateway préalablement examinée, générer une ébauche à partir des manifestes exportés. L'annonce officielle de la version 1.0 documente la forme suivante :

  ingress2gateway print --input-file ingress.yaml --providers=ingress-nginx > gateway-draft.yaml
  

  Examiner les ressources générées et tous les avertissements avant d'appliquer quoi que ce soit. Sélectionner la GatewayClass du remplacement réellement retenu et vérifier les noms, les espaces de noms et les références aux services de destination. Guide de conversion.

• Traiter explicitement chaque fonctionnalité non prise en charge. Cette annonce relève des fragments de configuration non convertis, des conversions approximatives de délais d'attente, des limites de taille du corps sans équivalent standard dans son exemple et des différences de normalisation des URL. Vérifier de nouveau ces correspondances avec l'API actuelle et l'implémentation choisie ; ne pas transformer une limite historique du convertisseur en affirmation permanente sur la spécification.

• Valider le point de terminaison distinct avec le nom d'hôte et l'identité TLS prévus. Tester les redirections, les exigences d'authentification, la priorité des routes, les téléversements, les requêtes longues et les comportements de rejet attendus. S'en tenir à des tests applicatifs ordinaires, sans charges utiles d'attaque. Comparer les résultats aux exigences documentées, sans se limiter au fait que les deux points de terminaison renvoient une réponse de succès.

• Déplacer le trafic selon le processus contrôlé de modification du DNS ou du répartiteur de charge du site. Observer les erreurs applicatives et les journaux d'accès, conserver un moyen de retour arrière limité dans le temps, puis supprimer l'ancien contrôleur et les ressources inutilisées une fois la période d'observation achevée avec succès.

Pièges

Ne pas supposer que le YAML généré préserve les contrôles d'accès ou que les extensions personnalisées sont portables entre contrôleurs. Un déploiement parallèle exige également une responsabilité clairement définie pour le DNS et l'automatisation des certificats. Éviter de laisser indéfiniment exposé le contrôleur dont la maintenance a cessé comme solution de secours non documentée. La réussite de la conversion, la disponibilité du contrôleur et le bon comportement de l'application sont des vérifications distinctes.