Ingress NGINX : fin de support, quel remplaçant choisir ?

Si votre cluster fait tourner le contrôleur communautaire ingress-nginx, il ne reçoit plus de versions ni de correctifs de sécurité depuis mars 2026. Vos routes continuent de répondre, rien ne s’arrête tout seul, mais il faut remplacer le contrôleur. Vous pouvez conserver l’API Ingress avec une autre implémentation ou passer à la Gateway API. Le choix dépend surtout des comportements à reproduire : authentification, réécritures de chemins, annotations NGINX.

Pour une petite équipe qui prépare un remplacement durable, notre recommandation est d’évaluer d’abord la Gateway API. Garder Ingress avec un contrôleur maintenu reste un choix défendable pour limiter le premier chantier. Dans les deux cas, les tests applicatifs décident.

Ce qui prend fin en mars 2026, et ce qui continue

Le retrait concerne kubernetes/ingress-nginx, le projet communautaire. NGINX lui-même, le contrôleur distinct F5 NGINX Ingress Controller et l’API Ingress de Kubernetes ne disparaissent pas avec lui. La déclaration des comités Kubernetes confirme l’échéance de mars 2026. Un load balancer existant continue à servir les requêtes après cette date.

La maintenance communautaire est terminée. Même si votre service répond et que vous montez régulièrement la version du plan de contrôle Kubernetes, le contrôleur installé par votre propre release Helm reste un composant à remplacer séparément.

Les engagements du cloud se vérifient séparément. Microsoft annonce des correctifs critiques pour les ressources NGINX Ingress de l’add-on application routing AKS jusqu’en novembre 2026. Cette prolongation ne couvre pas toute installation d’ingress-nginx sur AKS. Au 2 novembre 2026, nous sommes dans le dernier mois annoncé ; la documentation ne donne pas de jour précis. Même si cet add-on couvre encore votre installation, la date de sortie est à planifier dès maintenant.

Identifier le contrôleur et ses dépendances

Le nom nginx ne suffit pas. Pour identifier ce que vous devez remplacer, reliez les images et arguments du contrôleur aux IngressClass, puis aux annotations applicatives, en vérifiant l’identifiant du contrôleur et le workload qui tourne.

Ces exemples en lecture seule utilisent l’API networking.k8s.io/v1, kubectl 1.34.1 et jq 1.8.1. Les filtres JSON et la conversion ont été testés hors ligne sur des jeux de données, pas lors d’une migration complète de cluster. Les requêtes demandent des droits de lecture globaux. Utilisez un kubectl compatible avec votre serveur.

kubectl get ingressclasses -o wide
kubectl get deployments,daemonsets -A -o json | jq -r '
  .items[] | . as $w | .spec.template.spec.containers[] |
  [$w.metadata.namespace, $w.metadata.name, .image,
   ((.args // []) | join(" "))] | @tsv'
kubectl get ingress -A -o json > ingress-inventory.json
jq -r '
  .items[] |
  [.metadata.namespace, .metadata.name,
   (.spec.ingressClassName //
    .metadata.annotations["kubernetes.io/ingress.class"] // "unset"),
   ((.metadata.annotations // {} | keys |
     map(select(startswith("nginx.ingress.kubernetes.io/")))) |
     join(","))] | @tsv' ingress-inventory.json

La liste affiche toutes les images pour ne pas manquer un contrôleur recopié dans un registre privé. Examinez notamment --controller-class et --ingress-class. Consultez aussi les valeurs Helm et les ConfigMaps globales : les mappings TCP/UDP ou les snippets peuvent s’y trouver, hors du relevé des annotations.

Pour chaque hostname, notez le responsable, le secret TLS et le protocole du backend. Testez aussi les refus d’accès. Si vous vérifiez seulement qu’une requête autorisée passe, une sonde de santé verte peut cacher la disparition de l’authentification pendant la migration et l’exposition du backend aux autres requêtes.

Les oublis qui causent le plus d’incidents pendant ce type de migration viennent rarement du contrôleur lui-même. Une annotation d’authentification posée à la main sur un seul Ingress, un mapping TCP resté dans un ConfigMap global, une règle qui ne correspond plus parce que la classe n’a pas été reportée : ils apparaissent après la bascule, rarement pendant les tests.

Comparer les remplaçants sans confondre API et contrôleur

Conserver Ingress limite les changements de types de ressources. La Gateway API sépare la gestion de l’entrée réseau des routes applicatives. Dans les deux cas, il faut un contrôleur installé : les CRD Gateway API seules n’acheminent aucun trafic.

Ce tableau ne classe aucune performance. Avant de commencer la recette d’un candidat, figez les versions du chart, de l’image et des CRD, car une page de documentation « latest » ne décrit pas forcément ce que vous avez installé. La conformité à une version de la Gateway API ne garantit pas la reprise de vos snippets NGINX.

Pour une nouvelle entrée HTTP, notre proposition par défaut est la Gateway API, avec Envoy Gateway et Kgateway à évaluer. Notre article consacré à Kgateway détaille cette implémentation. Ici, gardez le chantier proportionné : si vos règles Ingress sont simples et leur remplaçant maintenu déjà testé, changer aussi d’API dans la même fenêtre n’apporte pas forcément assez.

Traduire les annotations en tests applicatifs

Une annotation n’est reprise que si la nouvelle entrée reproduit son effet : sans réécriture, elle peut servir une page valide au mauvais chemin ; sans contrôle d’accès, elle peut exposer un backend privé sans erreur HTTP.

Faites cette revue avant de noter les produits. Lorsqu’un contrôle requis n’a pas de remplacement supporté, il faut revoir le fonctionnement applicatif ou choisir un autre contrôleur. Supprimer discrètement une politique de sécurité pour terminer la conversion YAML n’est pas une option.

Convertir hors ligne puis tester une entrée parallèle

ingress2gateway produit une base à relire, sans certifier l’équivalence en production. Avec ingress2gateway v1.2.0, la sous-commande s’appelle print. Cet exemple a été testé hors ligne avec cette version sur un export Ingress de test. Il n’installe rien et n’applique aucun manifeste au cluster.

ingress2gateway version
ingress2gateway print --providers=ingress-nginx \
  --input-file=ingress-inventory.json \
  --ingress-nginx-ingress-class=nginx \
  --all-namespaces > gateway-candidate.yaml

Remplacez nginx par la classe source de votre inventaire. Vérifiez le gatewayClassName généré contre la GatewayClass cible installée. Gardez les diagnostics de stderr : notre exemple produit du YAML tout en signalant configuration-snippet comme non supporté et proxy-body-size comme non appliqué par l’émetteur standard. Un code de sortie réussi ne prouve aucune équivalence. Relisez aussi les secrets et les références entre namespaces.

Installez le candidat sur une adresse distincte avec une sélection de classe explicite. Aucun des contrôleurs ne doit récupérer les routes de l’autre. Empêchez l’automatisation DNS de publier prématurément cette nouvelle entrée. Avant la bascule publique, testez le certificat et le hostname attendus. Pour une adresse IPv4, curl peut viser le candidat en conservant SNI et l’en-tête HTTP Host :

HOST=app.example.com
CANDIDATE_IP=203.0.113.20
curl --fail-with-body --resolve "${HOST}:443:${CANDIDATE_IP}" \
  "https://${HOST}/health"

Ces valeurs sont à remplacer. N’ajoutez pas -k : ignorer la validation du certificat masquerait un échec TLS. L’endpoint de santé ne vérifie qu’un chemin. Rejouez les refus d’accès, les uploads, les redirections et les connexions longues de votre recette. Comparez les logs du backend, pas seulement les codes HTTP.

Basculez un hostname pilote. Fixez vos seuils d’erreurs et de latence d’après son fonctionnement habituel, puis surveillez les deux entrées pendant la propagation DNS. Gardez l’ancienne configuration et ses certificats pour une période de retour arrière définie. Revenir à l’ancienne adresse ne déplace instantanément ni les caches DNS ni les connexions ouvertes. Le contrôleur retiré reste un secours temporaire, pas un PRA durable.

Chiffrer les exceptions plutôt que compter les routes

La charge se mesure en comportements à reprendre, plus qu’en routes. Pour la chiffrer sans oublier les exceptions, comptez à part l’inventaire, la réécriture des politiques, l’infrastructure parallèle, la recette applicative, la bascule et la répétition du retour arrière. Aucun nombre universel de jours par cluster ne serait sérieux.

Ajoutez le load balancer et les ressources proxy en double pendant la cohabitation. Calculez ce coût avec les tarifs horaires actuels du fournisseur et la durée mesurée. Comptez aussi l’édition ou l’abonnement nécessaire au WAF ou à l’authentification. Comparer un contrôleur gratuit à une offre managée sans ces dépendances fausse le budget.

Notre conseil est de retirer la dépendance non maintenue avec un responsable et un repli testé. Évaluez la Gateway API pour une refonte durable ; garder Ingress peut réduire le premier changement. Si personne ne porte l’inventaire et la bascule, notre infogérance Kubernetes permet d’en confier l’exploitation à l’équipe. Apportez l’image du contrôleur et l’export des annotations à un diagnostic gratuit de 30 minutes.