En noviembre de 2025, los mantenedores de Ingress NGINX publicaron un anuncio que pasó casi desapercibido en muchos equipos: el controlador de entrada más usado en Kubernetes entraría en retiro definitivo en marzo de 2026. Sin releases, sin parches de seguridad, sin actualizaciones. Fin.
Ese plazo ya venció. Y la mayoría de las organizaciones que todavía corren Ingress NGINX en producción no están migrando por convicción técnica, sino corriendo contra el reloj de una deuda de infraestructura que ignoraron demasiado tiempo.
¿Por qué retiraron Ingress NGINX?
El motivo oficial fue escasez de recursos: el proyecto perdió mantenedores activos y la comunidad no tenía capacidad para sostenerlo a largo plazo. Pero el contexto técnico agrava el diagnóstico. En 2024 ya habían aparecido las vulnerabilidades #IngressNightmare — un conjunto de fallos que permitían a atacantes comprometer clústeres enteros a través de inyección de configuración maliciosa.
Claude Desbloqueado
Mi curso avanzado para aprender a sacarle mucho más provecho a Claude en el trabajo y en el día a día, con funciones y usos más potentes. Comienza el 23 de marzo.
→ Inscríbete hoy 🚀La arquitectura de Ingress NGINX hereda decisiones de diseño de NGINX clásico: C/C++, templating de configuración, parseo de anotaciones con superficie de ataque amplia. En entornos cloud-native, eso es riesgo estructural, no solo bugs solucionables con parches.
Kubernetes SIG Network tomó la decisión correcta, aunque incómoda: mejor el dolor de una migración planificada que mantener software inseguro indefinidamente.
Traefik no es solo el reemplazo disponible: es el drop-in real
El ecosistema tiene alternativas — F5 NGINX Ingress Controller, HAProxy Ingress, las soluciones nativas de cada cloud provider (AKS, AWS Load Balancer Controller, GKE). Todas funcionan. Pero todas exigen reescribir configuraciones.
La ventaja de Traefik en este momento específico es una sola: compatibilidad con las anotaciones nginx.ingress.kubernetes.io. Si tu equipo lleva años acumulando anotaciones NGINX en cientos de recursos Ingress, Traefik tiene una capa de compatibilidad que permite migrar sin reescribir nada. Los mismos objetos Ingress, el mismo formato, el mismo comportamiento — pero sobre un controlador activamente mantenido.
Eso es decisivo cuando la alternativa es una migración de semanas o meses con riesgo de regresiones en producción.
Pero hay algo importante que no viene en el comunicado de Traefik Labs: esta ventaja tiene fecha de expiración. Traefik mantiene el compatibility layer activamente hoy, pero su hoja de ruta a largo plazo apunta a Gateway API, no a seguir emulando un controlador retirado para siempre.
El problema de fondo: Gateway API es el futuro, pero no es la solución urgente
Kubernetes tiene desde hace años una especificación llamada Gateway API — un estándar que reemplaza el recurso Ingress con una jerarquía más expresiva y poderosa: Gateway, GatewayClass, HTTPRoute, TLSRoute. Diseñado para manejar casos que Ingress nunca pudo cubrir bien: routing avanzado, múltiples tenants, protocolos no-HTTP.
Traefik v3.6 tiene soporte completo de Gateway API v1.4 y se posiciona como líder del estándar. Muchos equipos están tentados a saltarse la migración temporal y pasar directamente a Gateway API.
Es un error de timing.
Gateway API requiere migrar todos los recursos Ingress existentes a nuevos tipos de objetos. Si tienes 200 servicios en producción con reglas de routing complejas, eso es meses de trabajo. No es algo que se haga bajo presión de un deadline de seguridad. La migración responsable separa los problemas en dos fases: primero salir de Ingress NGINX (usar el compatibility layer de Traefik), luego planificar la modernización a Gateway API con tiempo y pruebas.
El error que muchos equipos van a cometer es mezclar ambas fases y terminar paralizado en medio de las dos.
Lo que esto dice sobre el ecosistema cloud
El retiro de Ingress NGINX no es un accidente técnico. Es el primer caso grande de obsolescencia planificada en infraestructura de networking de Kubernetes, y anticipa un patrón que veremos más seguido: proyectos open source críticos sin modelo de sostenibilidad que eventualmente pierden mantenedores y fuerzan migraciones masivas.
La lección práctica para cualquier equipo que corre cargas en Kubernetes: el inventario de controladores, operadores y add-ons tiene que actualizarse periódicamente. No solo revisar CVEs, sino verificar el ritmo de mantenimiento, la salud del proyecto, y si hay señales de abandono antes de que sea una emergencia.
Un WAF mal configurado puede dejarte expuesto sin que lo sepas — como pasó con Azure WAF en modo Detection que muchos equipos dejaron corriendo sin protección real. Con Ingress NGINX el riesgo es equivalente: el controlador sigue funcionando, sigue despachando tráfico, pero ya no recibirá el parche para el próximo IngressNightmare.
¿Qué deberías hacer ahora?
Si estás en este escenario, hay tres preguntas que ordenan el trabajo:
1. ¿Cuántos recursos Ingress tienes y con qué anotaciones? El inventario es lo primero. Un kubectl get ingress -A -o yaml seguido de un grep de anotaciones nginx.ingress.kubernetes.io te da la superficie de migración real. Si tienes pocas anotaciones custom, cualquier controlador sirve. Si tienes decenas de reglas complejas, el compatibility layer de Traefik se vuelve crítico.
2. ¿Qué tan urgente es el riesgo de seguridad en tu entorno? Si corres clusters en internet con tráfico público, el riesgo de no tener parches de seguridad es inmediato. Si es infraestructura interna con exposure limitado, tienes más tiempo para planificar, aunque no indefinido.
3. ¿Tienes capacidad para la migración ahora o después? La diferencia entre migrar hoy y migrar en tres meses es que en tres meses estarás corriendo software sin actualizaciones de seguridad en un componente crítico de tu red. No hay respuesta correcta universal, pero el análisis de riesgo tiene que ser explícito.
Para startups pequeñas que acaban de descubrir este problema, la ruta más pragmática es: instalar Traefik con el NGINX Provider habilitado, transferir gradualmente los Ingress comenzando por los más simples, y validar en staging antes de promover a producción. La documentación oficial de Traefik tiene guías de migración específicas.
El momento del estándar
El retiro de Ingress NGINX va a acelerar la adopción de Gateway API. No porque sea lo más urgente ahora, sino porque los equipos que ya están migrando a Traefik van a encontrarse con un controlador que hace de Gateway API su prioridad, y la inversión en modernización va a seguir el camino natural.
Esto no es la primera vez que un estándar de red se impone por sustitución forzada más que por adopción voluntaria — el debate sobre BGP y sus alternativas lleva décadas exactamente porque no hay retiro forzado del protocolo antiguo. Kubernetes tuvo la disciplina de cortar el soporte. Eso es inusual y, a largo plazo, saludable para el ecosistema.
El costo real no lo pagan las empresas que ya migraron. Lo pagan las que lo ven como problema de operaciones, no de seguridad, y lo posponen hasta que aparece la siguiente vulnerabilidad crítica en un controlador que nadie va a parchar.
