Qu'est-ce qui change ?
Le Kubernetes Steering Committee et le Security Response Committee ont publié le 29 janvier 2026 une déclaration sans appel : Ingress NGINX, l'un des contrôleurs d'ingress les plus déployés de l'écosystème, sera retiré en mars 2026.
Selon les données Datadog, ~50% des environnements cloud natifs utilisent actuellement Ingress NGINX. Le problème ? Le projet ne compte plus que 1 à 2 mainteneurs travaillant sur leur temps libre, une situation devenue intenable face à l'accumulation de dette technique et de failles de sécurité structurelles.
La citation officielle est sans équivoque : "Rester avec Ingress NGINX après son retrait vous expose, vous et vos utilisateurs, à des attaques". Le comité insiste : les déploiements existants continueront de fonctionner, mais sans vérification proactive, vous ne saurez que vous êtes vulnérable qu'au moment de la compromission.
Quel impact pour les équipes DevOps ?
Contrairement aux mises à jour habituelles, il n'existe aucun remplacement drop-in. La migration nécessite une planification et un effort d'ingénierie significatifs. Voici comment vérifier si vous êtes concerné :
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginxNote : Cette commande requiert des permissions cluster administrator.
| Critère | Ingress NGINX (actuel) | Gateway API (recommandé) | Ingress tiers |
|---|---|---|---|
| Support officiel | ❌ Terminé mars 2026 | ✅ Standard Kubernetes | ✅ Selon éditeur |
| Migration effort | — | Moyen (refonte manifests) | Variable |
| Sécurité | ⚠️ Aucun patch futur | ✅ Maintenu activement | ✅ Selon éditeur |
| Maturité | Stable (mais EOL) | Production-ready (GA) | Mature (Traefik, HAProxy...) |
L'impact est direct : toute vulnérabilité découverte après mars 2026 restera non patchée. Pour les clusters en production, c'est un risque inacceptable.
Notre analyse
Deux mois, c'est court pour des migrations de cette ampleur. Mais cette décision reflète une réalité que beaucoup d'équipes DevOps connaissent : la maintenance open source n'est pas un acquis.
Nous pensons que cette transition forcée est une opportunité d'adopter Gateway API, le successeur moderne d'Ingress. Plus expressif, role-based, et conçu pour des cas d'usage avancés (mesh, TCP/UDP routing), Gateway API représente l'évolution naturelle du routing Kubernetes.
Notre recommandation : démarrez votre migration immédiatement. Commencez par un cluster de staging, documentez les différences de comportement, et planifiez un rollout progressif. Les équipes qui attendent mars pour agir se retrouveront en situation de crise.
