Ingress NGINX jubilado 2026: cómo migrar a Gateway API

En pocas palabras: En marzo de 2026, el SIG Network de Kubernetes retiró Ingress-NGINX: sin releases, bugfixes ni parches de seguridad, y con los repos en solo lectura. La ruta oficial es migrar a Gateway API, que reemplaza las 30 annotations del controlador por recursos nativos como HTTPRoute.

Sí, ya está: Ingress NGINX quedó jubilado en 2026. En marzo, el SIG Network de Kubernetes y el Security Response Committee retiraron el controlador, y desde entonces no salió ni un release, ni un bugfix, ni un parche de seguridad. Los repos en GitHub están en modo lectura. Tu cluster no se rompió, y ese es justo el problema.

Ingress-NGINX es el controlador de Ingress más usado de Kubernetes: un proxy de borde basado en NGINX que enruta el tráfico HTTP/HTTPS externo hacia los servicios internos del cluster. Lo mantenía el proyecto Kubernetes (SIG Network), no la empresa NGINX Inc. Desde marzo de 2026 quedó retirado. Sigue andando, pero sin nadie atrás que lo arregle.

¿Por qué Kubernetes decidió jubilar Ingress-NGINX en 2026?

Kubernetes jubiló Ingress-NGINX porque un componente de borde de esa criticidad estaba sostenido por muy poca gente. En el comunicado conjunto de enero de 2026, el proyecto lo describió como mantenido “solo por una o dos personas trabajando en su tiempo libre”. Para algo que corría en la mitad de los clusters, la ecuación no cerraba.

Kat Cosgrove, del Kubernetes Steering Committee, lo puso sin vueltas: “En marzo de 2026, Kubernetes va a retirar Ingress NGINX, una pieza de infraestructura crítica para cerca de la mitad de los ambientes cloud native”. Ese 50% sale de una investigación interna de Datadog citada en el mismo comunicado.

¿Por qué tirar de la manija justo ahora? Porque mantener un proxy NGINX con años de anotaciones acumuladas, cada una con su comportamiento particular, es una deuda técnica que se paga en incidentes de seguridad. El equipo prefirió cortar por lo sano y empujar a todos hacia una API mejor pensada. Sobre eso hablamos en herramientas de deployment automático.

¿Qué pasa con mis clusters en producción después de la jubilación?

Tus servicios siguen funcionando. Ese es el detalle traicionero: nada se cae el día uno, así que nada te avisa de que ahora estás corriendo un proxy de borde sin mantenimiento. La bomba es de tiempo, no de impacto inmediato.

El precedente ya lo vivimos. La CVE-2025-1974, divulgada el 24 de marzo de 2025, permitía tomar el control de un cluster entero, y en ese momento Kubernetes calculaba que más del 40% de los administradores corría el componente afectado. ¿Hubo parche? Sí, en las versiones v1.12.1 y v1.11.5. La próxima vez no va a existir.

Ponele que dentro de seis meses aparece una vulnerabilidad crítica en el parsing de anotaciones. Con Ingress-NGINX vivo, esperabas el fix y actualizabas. Ahora el repo está congelado y tu única salida es haber migrado antes. Por eso el reloj corre aunque todo se vea verde en el dashboard.

¿Cómo funciona Gateway API y por qué reemplaza a Ingress?

Gateway API es la API oficial de Kubernetes para enrutamiento de tráfico, sucesora directa del recurso Ingress. En vez de aplastar toda la configuración en anotaciones de un solo objeto, la separa en recursos con roles distintos: el GatewayClass lo define el proveedor de infraestructura, el Gateway lo maneja el equipo de plataforma, y el HTTPRoute lo controla el equipo de la aplicación. Relacionado: automatizar el despliegue en Kubernetes.

Esa jerarquía (Gateway apunta a HTTPRoute, que apunta a BackendRef) es lo que antes metías a la fuerza en un string de anotación. Acá viene lo bueno: al ser campos tipados de la API, el control de acceso RBAC entiende quién puede tocar qué. El 27 de febrero de 2026, según la documentación de Gateway API, la versión v1.5 promovió seis funcionalidades a estado Standard, o sea que dejaron de ser experimentales.

¿Cómo usar ingress2gateway para automatizar la conversión?

ingress2gateway es la herramienta oficial que traduce tus recursos Ingress y sus anotaciones a manifiestos de Gateway API. La versión 1.0 salió el 20 de marzo de 2026 y ahora convierte más de 30 anotaciones de Ingress-NGINX, cuando la versión anterior apenas cubría tres. Es el salto que hizo viable la migración masiva.

El uso básico es leer del cluster y escupir YAML. Algo así:

• Instalás la CLI desde el repositorio kubernetes-sigs/ingress2gateway.
• Corrés ingress2gateway print --input-file ingress.yaml o directamente contra el cluster con el provider ingress-nginx.
• Revisás la salida antes de aplicarla. La herramienta convierte lo que puede mapear, pero no adivina lógica de negocio.

Ojo con una cosa: ingress2gateway hace el 80% del trabajo aburrido, no el 100% del pensamiento. Las anotaciones exóticas, los snippets de configuración NGINX embebidos y las reglas de rewrite complicadas casi siempre necesitan una pasada manual. Tomalo como un borrador muy bueno, no como el manifiesto final.

¿Cuáles son los pasos correctos para migrar de Ingress-NGINX a Gateway API?

La migración segura es incremental y arranca en staging, nunca en producción de una. La idea es convertir, validar y hacer rollout gradual, dejando que Ingress-NGINX y Gateway API convivan un rato mientras verificás que el tráfico se comporta igual.

1. Auditá lo que tenés: contá cuántos Ingress hay y qué anotaciones usan. kubectl get ingress -A es el punto de partida.
2. Corré ingress2gateway en staging y guardá el YAML generado.
3. Validá las conversiones automáticas objeto por objeto: hosts, paths, backends y pesos.
4. Marcá las anotaciones no soportadas que la herramienta no supo traducir y resolvelas a mano.
5. Testeá exhaustivo en staging con tráfico sintético que reproduzca los casos reales.
6. Hacé rollout gradual con canary en producción, moviendo un porcentaje chico primero.
7. Retirá Ingress-NGINX recién cuando el 100% del tráfico esté sobre Gateway API y estable.

Migrás un servicio, lo probás en staging, funciona, lo pasás a canary con 5% de tráfico, mirás las métricas, subís a 50%, esperás, y recién ahí lo llevás a 100% y apagás la ruta vieja. Ese ritmo lento es feo pero es el que evita el llamado a las tres de la mañana. En infraestructura cloud empresarial de Google profundizamos sobre esto.

¿Qué alternativas de controladores Ingress hay además de Ingress-NGINX?

Hay varias, pero conviene separar dos cosas. Una es seguir usando un controlador de Ingress (el recurso viejo) con otro proyecto. La otra, la recomendación oficial, es moverte a Gateway API. Un aviso importante: el NGINX Ingress Controller de NGINX Inc (hoy de F5) es un proyecto distinto al Ingress-NGINX que jubiló Kubernetes, así que no confundas los nombres.

Opción	Tipo	Cuándo conviene
Gateway API (v1.5)	API oficial de Kubernetes	Recomendación oficial; ruta a futuro
Traefik	Controlador dinámico	Config dinámica y arranque simple
HAProxy Ingress	Controlador Ingress	Cuando ya usás HAProxy y querés control fino
Kong Ingress	Controlador con API gateway	Si necesitás plugins y gestión de API
NGINX Ingress (F5)	Comercial, mantenido por NGINX Inc	Soporte pago y continuidad NGINX

Si estás pensando dónde correr todo esto, para infraestructura y hosting en Argentina podés mirar donweb.com. El punto de fondo igual es uno solo: cambiar de controlador de Ingress es patear el problema para adelante, porque el recurso Ingress ya no es el futuro. Gateway API sí lo es.

¿Cómo se mapean las anotaciones de Ingress-NGINX a Gateway API?

Las anotaciones más comunes tienen equivalente directo en los filtros de HTTPRoute, y ingress2gateway convierte más de 30 de forma automática. Acá va una muestra de las que más se ven en producción, para que sepas qué esperar cuando revises el YAML generado.

Anotación Ingress-NGINX	Equivalente en Gateway API
nginx.ingress.kubernetes.io/rewrite-target	Filtro URLRewrite en HTTPRoute
nginx.ingress.kubernetes.io/ssl-redirect	Filtro RequestRedirect a HTTPS
nginx.ingress.kubernetes.io/permanent-redirect	Filtro RequestRedirect (301)
nginx.ingress.kubernetes.io/canary + canary-weight	Pesos (weight) en BackendRef
nginx.ingress.kubernetes.io/enable-cors	Filtro CORS en HTTPRoute

Lo lindo del canary es que en Ingress-NGINX vivía en tres anotaciones acopladas y medio frágiles, mientras que en Gateway API es un campo weight nativo dentro de la lista de backends. Más legible y menos propenso a que alguien lo rompa sin querer.

Errores comunes al migrar (y cómo evitarlos)

• Migrar directo a producción: saltear staging es la receta para un incidente. Convertí, validá y recién ahí hacés canary. La herramienta genera YAML, no garantías.
• Confiar en el 100% de la conversión automática: ingress2gateway no traduce snippets de configuración NGINX embebidos ni lógica custom. Revisá manualmente las anotaciones que quedaron afuera.
• Confundir Ingress-NGINX con el NGINX Ingress de F5: son proyectos distintos. Migrar de uno al otro no te saca del problema de fondo si seguís sobre el recurso Ingress.
• Postergar porque “todavía anda”: el cluster sin parches es un pasivo silencioso. Cuanto más esperás, más grande es la migración de emergencia el día que salga una CVE.

Preguntas Frecuentes

¿Ingress-NGINX todavía recibe actualizaciones de seguridad después de marzo 2026?

No. Desde marzo de 2026 no hay releases, bugfixes ni parches de seguridad, y los repositorios de GitHub quedaron en modo solo lectura. Cualquier vulnerabilidad nueva que se descubra no va a tener fix oficial, a diferencia de la CVE-2025-1974 que sí se parcheó en su momento. Lo explicamos a fondo en productos y servicios de Google Cloud.

¿Cuánto tiempo tengo para migrar de Ingress-NGINX?

La fecha límite ya pasó: fue marzo de 2026. Tus servicios siguen funcionando, así que técnicamente no hay un corte forzado, pero cada día que pasa sin migrar es más exposición a una vulnerabilidad sin parche. La recomendación es empezar la migración ahora, no esperar a que aparezca un problema.

¿Cuál es la mejor alternativa a Ingress-NGINX?

Gateway API v1.5 es la recomendación oficial de Kubernetes, ya que reemplaza al recurso Ingress con una API tipada y con mejor separación de roles. Si por algún motivo necesitás seguir con un controlador de Ingress clásico, Traefik, HAProxy Ingress o Kong son opciones, pero seguís atado a un recurso que ya no es el futuro.

¿ingress2gateway convierte todas las anotaciones automáticamente?

Convierte más de 30 anotaciones de Ingress-NGINX desde la versión 1.0 del 20 de marzo de 2026, contra las tres que soportaba antes. No cubre el 100% de los casos: los snippets de configuración NGINX embebidos y la lógica custom requieren ajuste manual, así que siempre revisá el YAML generado antes de aplicarlo.

¿Gateway API soporta todas las funciones de Ingress-NGINX?

Cubre las funciones más usadas (rewrites, redirects, canary por pesos, CORS) con filtros nativos de HTTPRoute, y el 27 de febrero de 2026 la v1.5 promovió seis funcionalidades a Standard. Algunas capacidades muy específicas de NGINX todavía dependen de extensiones del proveedor, así que conviene validar tu caso puntual en staging.

Conclusión

Lo que cambió es simple de enunciar y molesto de asimilar: Ingress-NGINX dejó de existir como software mantenido en marzo de 2026, y si lo seguís corriendo estás sobre infraestructura sin parches en el borde de tu cluster. No se rompió nada todavía, pero esa calma es prestada.

La buena noticia es que la herramienta acompañó. ingress2gateway 1.0 y Gateway API v1.5 hacen que la migración sea mucho menos dolorosa que hace un año. Empezá auditando tus Ingress, corré la conversión en staging, validá a mano lo que no mapea, y hacé el rollout con canary. Cuanto antes arranches, más chica es la migración y menos chances de que te agarre una CVE sin salida.

Fuentes

• Kubernetes SIG Network – Repositorio oficial de Ingress-NGINX (modo lectura)
• Gateway API – Documentación oficial del proyecto (v1.5)
• ingress2gateway – Herramienta de conversión automática a Gateway API
• Kubernetes Docs – Concepto de Gateway API
• Plan de migración: Ingress-NGINX retirado y las 30 anotaciones a Gateway API