Retrait d’Ingress NGINX dans Kubernetes : l’occasion de repenser vos pratiques
En bref : ce qu'il s'est passé
Kubernetes a annoncé le retrait d'Ingress NGINX avec fin de support annoncée pour mars 2026. Cette décision — relayée massivement — invite toutes les équipes qui utilisent aujourd'hui NGINX comme porte d'entrée dans leurs clusters Kubernetes à démarrer immédiatement leur migration vers une alternative.
Pourquoi cette annonce fait-elle tant parler ?
Ingress NGINX joue un rôle critique : c'est la porte d'entrée des applications exposées depuis Kubernetes. Sa popularité tient à sa maturité, sa flexibilité et son adoption par de nombreuses équipes DevOps.
Le retrait programmé crée deux urgences :
► Technique : arrêter d'utiliser une solution dont les correctifs et mises à jour cesseront
► Organisationnelle : profiter de la migration pour traiter des sujets structurels longtemps repoussés.
Beaucoup d'équipes se retrouvent face à un chantier imposé. Sur le terrain, nous constatons qu'une grande partie des organisations que nous accompagnons dépendent encore de cette solution.
Comment aborder cette situation ?
Nos interventions chez de grandes entreprises (France & international) révèlent des tendances récurrentes, qui peuvent générer des incidents.
Le parti pris défendu dans notre approche, est de prendre en compte tous les éléments de la migration, pour faire de cette situation imposée une opportunité stratégique 👇
Deux approches pour aborder cette migration
L'approche classique et ses risques, versus le parti pris de CNS pour transformer vos environnements Kubernetes et les rendre plus sûrs, observables et standardisés.
Dans de nombreuses entreprises, les environnements Kubernetes sont gérés exclusivement par les équipes applicatives, composants d’infrastructure inclus. Chaque équipe applique ses propres pratiques, souvent en autonomie complète.
Voici pourquoi une migration ne doit surtout pas être traitée comme un exercice purement technique (une réécriture de configuration), sans quoi elle peut dégénérer en incidents.
► Configurations non sécurisées : règles permissives, TLS mal configuré, politiques réseau incomplètes ;
► Hétérogénéité des déploiements : absence de standards et de catalogues de ressources, avec des environnements hétérogènes sur les plans sécurité et réseau ;
► Absence totale ou très faible d'observabilité, pourtant essentielle (visibilité limitée sur le comportement des entrées réseau et la latence applicative) ;
► Absence d'automatisation, ou automatisation insuffisante (processus manuels, risques d'erreur et de coûts opérationnels élevés) ;
► Peu ou pas de synergie avec les équipes réseau et sécurité, ce qui crée des angles morts.
Ces constats ne sont pas anecdotiques. Remplacer Ingress NGINX par une autre solution sans repenser l'architecture est une erreur fréquente.
Sécuriser, standardiser, observer, automatiser. Il s'agit de considérer la migration comme le moyen de reprendre le contrôle et d'améliorer durablement l’écosystème Kubernetes.
Notre approche et notre expertise réseau et sécurité Kubernetes permettent de transformer cette contrainte imposée par le calendrier en levier d'amélioration, sans sacrifier l’agilité des équipes, en prenant en compte tous les aspects de cette migration.
Les objectifs :
► Reprendre le contrôle des entrées réseau (policy, sécurité, authentification) ;
► Sécuriser l'écosystème Kubernetes, optimal sur les plans performance et coût ;
► Mettre en place une démarche d'observabilité ;
► Standardiser les environnements (imposer un standard et un catalogue réutilisable) ;
► Automatiser les opérations (déploiements et updates) pour réduire le risque humain ;
► Réconcilier les équipes applicatives avec les équipes infrastructure (réseau et sécurité).
Le tout sans dégrader l'agilité !
Quelles alternatives de migration possibles ?
Selon les besoins et les contraintes, plusieurs alternatives à Ingress NGINX sont envisageables.
Parmi les pistes techniques couramment choisies :
► Gateway API (proposition native de l'écosystème : c'est la solution recommandée par la communauté Kubernetes) — bonne intégration et standardisation ;
► Cilium + Cilium Gateway — solution orientée réseau et sécurité (Cilium propose une pile L7 et eBPF performante), sur laquelle CNS collabore fréquemment ;
► Solutions Cloud Native / Constructeurs tiers (fournie par un fournisseur ou un éditeur tiers.)
Le choix dépend du périmètre, des contraintes de compliance, des objectifs de performance et du modèle d'exploitation souhaité.
Ces pistes permettent d’assurer la continuité de service tout en améliorant la cohérence, la sécurité et la maintenabilité des environnements.
Pour aller plus loin sur le sujet
Parlons-en !
Rédigé par
