7 min de lectura

Desde marzo de 2026, Ingress-NGINX está oficialmente en fase de retirada. Sin parches, sin actualizaciones de seguridad ni correcciones de errores. El proyecto Kubernetes ha jubilado al controlador de ingreso más utilizado del mundo. Aproximadamente la mitad de todos los entornos cloud-native se ven afectados. Quien no migre ahora estará gestionando cargas de trabajo expuestas a Internet con un componente abandonado.

En resumen

• 🚨 Ingress-NGINX alcanzó su fin de vida (EOL) en marzo de 2026. Ya no hay actualizaciones de seguridad (Proyecto Kubernetes, 11.11.2025).
• 📊 Aproximadamente el 50 % de todos los entornos cloud-native utilizan Ingress-NGINX (Comité Directivo de Kubernetes, 29.01.2026).
• ✅ Gateway API v1.4 es el sucesor oficial. Listo para producción desde octubre de 2025 (CNCF).
• 🔄 Traefik, HAProxy y F5 NGINX Ingress Controller son alternativas comunitarias probadas.
• 🏢 KubeCon Europe 2026 en Ámsterdam (23 al 26 de marzo) convierte la migración en un tema obligado para los equipos de plataforma.

Qué ha ocurrido y por qué urge actuar ya

El 11 de noviembre de 2025, el proyecto Kubernetes publicó un artículo de blog sobre la retirada de Ingress-NGINX. Este controlador, estándar durante años para el enrutamiento HTTP en clústeres Kubernetes, dejará de recibir actualizaciones a partir de marzo de 2026. El repositorio de GitHub pasará a modo solo lectura y se trasladará a la organización kubernetes-retired.

¿Qué significa esto concretamente? Cada nueva CVE detectada en NGINX o en la lógica del controlador permanecerá sin parchear. Para un controlador que está directamente expuesto a Internet y gestiona todo el tráfico entrante de un clúster, esto representa un riesgo de seguridad tangible.

El 29 de enero de 2026, el Comité Directivo de Kubernetes y el Comité de Respuesta ante Seguridad emitieron una declaración conjunta. En un comunicado oficial, cuantificaron su difusión: aproximadamente el 50 % de todos los entornos cloud-native emplean Ingress-NGINX (fuente: investigación de Datadog). La recomendación es inequívoca: evaluar Gateway API como sucesor oficial, planificar la migración y no esperar.

Gateway API: el sucesor oficial

La comunidad Kubernetes ha estado preparando esta sustitución durante años. Gateway API no es simplemente un nuevo controlador de ingreso, sino un concepto fundamentalmente distinto. En lugar de una única recurso Ingress con anotaciones, ahora existen recursos separados para infraestructura (GatewayClass, Gateway) y para enrutamiento (HTTPRoute, GRPCRoute, TCPRoute).

Desde octubre de 2025, Gateway API v1.4.0 tiene el estatus de disponibilidad general (General Availability). GatewayClass, Gateway y HTTPRoute son estables y aptos para producción. Ya no se trata de una versión beta. Empresas como Google, Red Hat y VMware ya implementan Gateway API en sus ofertas gestionadas de Kubernetes.

La ventaja decisiva: configuración basada en roles. Los administradores de clúster definen la infraestructura de Gateway, mientras que los equipos de desarrollo configuran sus rutas de forma independiente. En Ingress-NGINX, todo se concentraba en un único recurso con cientos de anotaciones, que muy pocos miembros del equipo comprendían realmente.

«Gateway API modela las redes de Kubernetes de una forma expresiva, extensible y basada en roles».
– Documentación de Kubernetes, Conceptos de Gateway API (traducción adaptada)

Las tres mejores alternativas comparadas

Gateway API es la opción estratégicamente correcta. Pero no todos los equipos pueden migrar de inmediato. Según la configuración del clúster, las anotaciones utilizadas y las integraciones existentes, los caminos de migración varían.

Traefik fue uno de los primeros controladores en implementar soporte completo para Gateway API v1.4. Quienes ya usan Traefik como proxy inverso podrán realizar la transición con un esfuerzo mínimo. Traefik Labs ofrece una guía detallada de migración con mapeo paso a paso de anotaciones Ingress a recursos de Gateway API.

F5 NGINX Ingress Controller es la bifurcación comercial mantenida activamente. Quienes deseen seguir usando NGINX sin renunciar al soporte profesional encontrarán aquí el menor esfuerzo de reconfiguración. La configuración es prácticamente idéntica; únicamente cambian el espacio de nombres y los charts de Helm. El inconveniente: dependencia del proveedor (vendor lock-in) y costes de licencia.

HAProxy Ingress Controller es el reemplazo más estable y fiel 1:1 para equipos que buscan un controlador ligero y probado. HAProxy Technologies lo mantiene activamente y tiene previsto el soporte para Gateway API en su hoja de ruta.

Planificar la migración: 5 pasos para los equipos de plataforma

Migrar desde Ingress-NGINX no es un proyecto para un fin de semana. Los equipos de plataforma deben proceder de forma estructurada.

Paso 1: Inventario inicial. Inventariar todos los recursos Ingress del clúster. ¿Qué anotaciones se utilizan? ¿Qué configuraciones personalizadas contienen los ConfigMaps? Herramientas como Fairwinds Insights pueden ayudar a estimar el alcance de la migración.

Paso 2: Elegir el controlador objetivo. Gateway API para proyectos nuevos (Greenfield) y estrategia a largo plazo. Traefik o F5 NGINX para equipos que necesiten migrar rápidamente y deseen conservar, en lo posible, sus manifiestos Ingress existentes.

Paso 3: Ejecución paralela. Instalar el nuevo controlador junto a Ingress-NGINX. Redirigir el tráfico gradualmente, ruta por ruta. No cambiarlo todo de golpe.

Paso 4: Adaptar el monitoreo. Las métricas específicas de Prometheus para Ingress-NGINX (nginx_ingress_controller_*) ya no existen en el nuevo controlador. Los paneles y alertas deben reconstruirse sobre las nuevas métricas.

Paso 5: Desinstalar Ingress-NGINX. Solo cuando todas las rutas hayan sido migradas y el nuevo controlador funcione de forma estable. No antes. No mantener la ejecución paralela indefinidamente, pues duplica la superficie de ataque.

Trampas habituales durante la migración

Los problemas más frecuentes en la migración desde Ingress-NGINX no afectan al propio controlador, sino al ecosistema que lo rodea.

Anotaciones sin equivalente. Ingress-NGINX dispone de más de 100 anotaciones, desde limitación de tasas (rate limiting) hasta CORS y cabeceras personalizadas. No todas tienen un equivalente directo en Gateway API. Los equipos deben verificar qué anotaciones se usan realmente y si su funcionalidad se implementa de otra manera en el nuevo controlador.

Integración con cert-manager. Muchos equipos usan cert-manager junto con Ingress-NGINX para obtener certificados TLS automáticamente. cert-manager soporta Gateway API de forma nativa desde la versión 1.15. La migración suele ser sencilla, pero los recursos Gateway requieren etiquetas distintas a los recursos Ingress.

External-DNS. Quienes usan External-DNS para crear entradas DNS automáticas deben comprobar si la versión instalada reconoce los recursos de Gateway API. Versiones antiguas de External-DNS solo trabajan con objetos Ingress.

Páginas de error personalizadas y fragmentos (snippets). Ingress-NGINX permite insertar fragmentos personalizados de NGINX mediante anotaciones. Es una funcionalidad potente, pero también un riesgo de seguridad. Gateway API deliberadamente no incluye una función equivalente. Los equipos que usan snippets deberán trasladar dicha lógica al propio controlador o a un middleware.

Por qué el proyecto Kubernetes ha abandonado Ingress-NGINX

La retirada de Ingress-NGINX no es un fracaso técnico, sino una limpieza estratégica. El controlador se lanzó en 2016 como implementación de referencia y, con los años, se convirtió en el estándar de facto. Precisamente eso se convirtió en el problema: más de 100 anotaciones, ausencia de una distribución clara de responsabilidades entre roles y una base de código cada vez más difícil de mantener con cada actualización de NGINX.

Además, hubo incidentes de seguridad. En octubre de 2025, el Comité de Respuesta ante Seguridad de Kubernetes publicó un informe sobre varias vulnerabilidades críticas en el admission webhook de Ingress-NGINX. La combinación de alta difusión, complejidad creciente del código y reducción de la capacidad de mantenimiento hizo inevitable su retirada.

Para el ecosistema Kubernetes, este es un paso saludable. Gateway API no solo sustituye a Ingress-NGINX, sino que reemplaza todo el concepto de Ingress. En lugar de anotaciones específicas de cada proveedor, ahora existen recursos estandarizados que cualquier controlador puede implementar. Esto reduce la dependencia de proveedores y hace el networking de Kubernetes más portable.

Qué deben priorizar ahora las empresas de DACH

Los sectores regulados en Alemania, Austria y Suiza enfrentan una presión especial. Las empresas obligadas a cumplir con NIS2 deben demostrar que su infraestructura TI se mantiene activamente. Un controlador de ingreso sin soporte de seguridad constituye un riesgo de cumplimiento documentable.

Las entidades financieras y los proveedores sanitarios deben abordar la migración como primera prioridad. La demostración de componentes mantenidos activamente forma parte de la documentación de la cadena de suministro exigida por NIS2. Quien, durante una auditoría, tenga una componente en fase de retirada en el perímetro de Internet tendrá serios problemas de explicación.

Las pymes con equipos de plataforma pequeños se beneficiarán especialmente de Traefik o F5 NGINX como solución intermedia. La migración a Gateway API podrá realizarse después como segundo paso, una vez que se haya adquirido la capacidad y el conocimiento necesario.

KubeCon Europe 2026: la migración será tema obligado

Del 23 al 26 de marzo de 2026 tendrá lugar la KubeCon Europe en Ámsterdam. La migración desde Ingress-NGINX dominará la agenda de las pistas de ingeniería de plataformas. Para los equipos que aún no han migrado, la conferencia ofrecerá talleres prácticos (hands-on) y casos reales de empresas que ya han completado la transición.

Quien no pueda acudir a Ámsterdam: las charlas suelen publicarse en formato grabado en YouTube dentro de las cuatro semanas siguientes. Pero esperar no es una estrategia. Cada día sin actualizaciones de seguridad es un día con riesgo abierto.

Conclusión

Ingress-NGINX fue durante años el estándar. Esa época ha terminado. Su retirada no es una sorpresa, sino el resultado de una decisión consciente de la comunidad Kubernetes a favor de Gateway API. Quien no actúe ahora estará gestionando un componente crítico para la seguridad sin soporte.

El camino pragmático: Gateway API para nuevos proyectos y como objetivo estratégico. Traefik o F5 NGINX como soluciones puente para equipos que deban reaccionar con rapidez. Ejecución paralela, migración progresiva y, finalmente, eliminación completa de Ingress-NGINX.

La pregunta ya no es si, sino con qué rapidez.

Preguntas frecuentes

¿Qué ocurre si sigo utilizando Ingress-NGINX?

Técnicamente seguirá funcionando, pero ya no recibirá actualizaciones de seguridad. Cada nueva vulnerabilidad en NGINX o en el código del controlador permanecerá sin parchear. Para cargas de trabajo expuestas a Internet, esto supone un riesgo creciente.

¿Cuánto tiempo lleva migrar a Gateway API?

Depende del número de recursos Ingress y de las anotaciones utilizadas. En clústeres pequeños con 10 a 20 rutas, la migración puede completarse en una o dos semanas. Entornos grandes con snippets personalizados y reglas de enrutamiento complejas requerirán de cuatro a ocho semanas.

¿Puedo ejecutar Gateway API e Ingress-NGINX en paralelo?

Sí, y de hecho se recomienda. Instale el nuevo controlador en paralelo, migre ruta por ruta y elimine Ingress-NGINX únicamente cuando todas las rutas funcionen de forma estable.

¿Es Traefik mejor que Gateway API?

Traefik es una implementación; Gateway API es una especificación. Traefik soporta completamente Gateway API v1.4. Puede usar Traefik como controlador y, al mismo tiempo, definir recursos de Gateway API. Ambas cosas no son excluyentes.

¿Cuál es el coste del F5 NGINX Ingress Controller?

F5 ofrece el NGINX Ingress Controller en una versión gratuita de código abierto y en una versión comercial Plus. Esta última requiere una licencia NGINX Plus, cuyo coste depende del número de instancias.

Artículos relacionados

• Gobernanza de clústeres Kubernetes en la pyme – por qué el control es más importante que la escalabilidad (cloudmagazin)
• Certificados TLS en 2026 – por qué la validez de 200 días marca el fin de la gestión manual (cloudmagazin)
• Identidad cloud-native – OAuth 2.1, passkeys y el futuro de la autenticación (cloudmagazin)

Más contenido de la red MBF Media

• Práctica SBOM – cómo implementar su empresa la lista de piezas de software (SecurityToday)
• Repatriación en la nube 2026 – por qué los CIO están trayendo de vuelta las cargas de trabajo (Digital Chiefs)

Fuente de imagen: Brett Sayles / Pexels