kubernetes/ingress-nginx finaliza en marzo de 2026: guía de migración
El origen del debate
Hola a todos, comparto un artículo que escribí sobre el próximo fin de ciclo de vida (End-of-Life) para el controlador kubernetes/ingress-nginx mantenido por la comunidad, programado para marzo de 2026.
El artículo analiza por qué este cambio importa (ausencia de parches para futuros CVE, problemas de cumplimiento normativo), cómo ejecutar una auditoría rápida para comprobar si tus clústeres están afectados y un desglose de las alternativas de migración más viables (como Traefik o Gateway API) según diferentes configuraciones de infraestructura.
Me encantará saber a qué controladores está migrando el resto de la comunidad.
Cualquier idea para mejorar la guía es más que bienvenida. Les deseo un excelente día a todos, Kubernautas :)
Nino
Aspectos destacados en los comentarios
Punto de debate 1
A decir verdad, muchísima gente nunca actualizó ingress-nginx después de ponerlo en marcha durante las pruebas iniciales; esas organizaciones simplemente seguirán con él hasta el final.
Punto de debate 2
El mayor inconveniente en mi caso es la falta de soporte en la especificación de gateway para nuestro escenario multiinquilino. Vincular la definición en la pasarela para los listeners y sus certificados implica que tendría que regresar y actualizar el Gateway cada vez que entre un nuevo inquilino. Sé que se está trabajando en torno a ListenerSet, pero no puedo migrar hasta que eso funcione con cert-manager. https://cert-manager.io/announcements/2025/11/26/ingress-nginx-eol-and-gateway-api/ https://gateway-api.sigs.k8s.io/geps/gep-1713/
Punto de debate 3
Por si sirve de algo, he estado probando la versión preliminar de cert-manager con soporte para XListenerSet y funciona bien. Se supone que la versión 1.20 con este soporte se lanza hoy, salvo que sufra algún retraso. https://cert-manager.io/announcements/2025/11/26/ingress-nginx-eol-and-gateway-api/ Dicho esto, me sorprende que Gateway API se haya lanzado sin ListenerSets, que resultan indispensables para casi cualquier cliente con el que he trabajado.
Punto de debate 4
Pasamos por este mismo proceso de migración el año pasado cuando abandonamos un controlador de ingress más antiguo. La parte más dura no fue elegir el reemplazo, sino la fase de descubrimiento. Teníamos como 60 y tantos namespaces repartidos en 8 clústeres y nadie sabía con certeza qué equipos estaban usando ingress-nginx frente a otros controladores o LoadBalancers directos. Terminé programando un script rápido para ejecutar kubectl get ingress por todas partes y filtrar por controller class, cruzando luego los datos con las anotaciones reales de los pods. Tomó una eternidad porque teníamos que cambiar de contexto entre clústeres continuamente. Descubrimos un montón de despliegues fantasma cuya existencia nadie recordaba. Si tuviera que repetirlo, automatizaría esa auditoría inicial de forma mucho más contundente desde el principio. Ejecutar los mismos comandos de diagnóstico en toda la flota en paralelo nos habría ahorrado unas dos semanas de trabajo de rastreo. La migración real fue fluida una vez que supimos con qué estábamos lidiando. Por cierto, Gateway API funcionó de maravilla para nuestro caso, sobre todo si ya estás en una versión reciente de k8s.
Punto de debate 5
¿Parece que el verdadero problema ahí es no obligar al uso de CI como Argo / Flux?
Resumen del hilo
- Subreddit original: r/kubernetes
- Autor original: u/neo123every1iskill
- Puntuación en Reddit: 69
- Cantidad de comentarios: 34
- Hilo original: https://medium.com/@housemd/kubernetes-ingress-nginx-eol-march-2026-the-complete-migration-guide-to-replace-ingress-nginx-e8f6e118fb5f