Kubernetes SIG Network et le Security Response Committee ont annoncé l’arrêt du Community Ingress NGINX Controller — une décision qui impacte une large partie de l’écosystème Kubernetes.
Une maintenance « best effort » sera assurée jusqu’en mars 2026. Au-delà de cette date, le projet ne recevra plus de mises à jour, de corrections de bugs ni de correctifs de sécurité.
Les déploiements existants continueront de fonctionner, mais sans aucune garantie de sécurité ni de support — ce qui soulève des enjeux importants pour les organisations qui l’utilisent en production.
Ce qui change — et pourquoi c’est important.
Ingress NGINX est depuis longtemps un composant clé pour exposer des applications Kubernetes.
À partir de mars 2026, le projet Community Ingress NGINX ne bénéficiera plus :
- de correctifs de sécurité
- de remédiation des vulnérabilités (CVE)
- d’évolutions fonctionnelles
Kubernetes SIG Network recommande d’initier une migration dès maintenant, vers le Gateway API ou vers un autre contrôleur Ingress supporté.
Du point de vue sécurité et gouvernance, continuer à utiliser un composant non maintenu implique un risque croissant dans le temps.
Pas d’arrêt immédiat — mais un risque croissant.
It’s important to clarify:
Les applications ne s’arrêteront pas brutalement en mars 2026.
En revanche, la situation évoluera progressivement :
- aucune vulnérabilité future ne sera corrigée
- la compatibilité avec les futures versions Kubernetes deviendra incertaine
- les équipes sécurité perdront en visibilité et en contrôle
Pour les environnements critiques, exposés ou réglementés, cela devient rapidement une décision stratégique — et non plus uniquement technique.
Quelles sont les options ?
Deux trajectoires principales s’offrent aux organisations.
- Évoluer vers le Gateway API Kubernetes
Le Gateway API représente la direction long terme recommandée par Kubernetes. Il apporte :
- une architecture orientée rôles
- des APIs standardisées
- une meilleure portabilité
De nombreuses implémentations existent déjà : https://gateway-api.sigs.k8s.io/implementations/
Cependant, il s’agit d’un changement architectural majeur, parfois complexe à mettre en œuvre dans des environnements existants.
- Adopter une alternative Ingress supportée
Le Community Ingress NGINX n’est pas la seule implémentation d’Ingress Controller.
Plusieurs alternatives sont activement maintenues, notamment celles référencées par Kubernetes : https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/
Pour les équipes utilisant déjà NGINX, le F5 NGINX Ingress Controller (OSS) constitue une évolution naturelle et pérenne :
- open source (Apache 2.0)
- maintenance active
- continuité technologique
- compatible avec une évolution vers le Gateway API
Une migration à aborder de manière pragmatique.
Il n’existe pas de trajectoire unique.
Dans la pratique, les migrations réussies sont :
- progressives
- maîtrisées
- alignées avec les enjeux métiers et sécurité
La plupart des organisations ont intérêt à sécuriser et stabiliser leurs environnements actuels, puis à planifier une transition progressive.
Quelles prochaines étapes ?
Si vous :
- utilisez Kubernetes ou OpenShift en production
- évaluez le Gateway API
- souhaitez réduire votre exposition aux risques
C’est le bon moment pour analyser votre situation et définir une stratégie de migration claire.
