Ingress-NGINX se retira y Kubernetes ya tiene sus favoritos

Durante casi una década, si levantabas un clúster de Kubernetes y necesitabas dar entrada al tráfico, recurrías a Ingress-NGINX. No era el valor por defecto oficial, pero actuaba como si lo fuera. Por eso, cuando los mantenedores anunciaron que el proyecto se retira en marzo de 2026, la reacción de la comunidad mezcló nostalgia, cansancio y una avalancha de hilos preguntando qué lo sustituye.

Lo curioso es que a nadie le pilló por sorpresa. La transición para alejarse de Ingress-NGINX llevaba años gestándose en segundo plano, y el anuncio de retiro solo hizo visible una tendencia consolidada. Muchos operadores ya tenían sus favoritos y los ejecutaban en producción mucho antes de la noticia.

Traefik está en todas partes, quizá más de lo esperado

Si la conversación tuvo un protagonista indiscutible, fue la frecuencia con la que apareció Traefik. A los operadores les encanta su configuración directa, su integración limpia con cert-manager y Let's Encrypt, y la forma en que convive con Ingress y Gateway API sin obligarte a elegir desde el primer día. Ese modelo bilingüe es un gran alivio, porque permite migrar poco a poco en lugar de reescribir decenas o cientos de manifiestos de golpe.

La nueva capa de compatibilidad con Ingress-NGINX que ofrece Traefik tampoco viene nada mal. Una vía directa que no exige modificar los recursos existentes es justo lo que necesitan ahora los equipos de plataforma saturados.

Algunos se quejaron del precio de la versión enterprise, pero la gran mayoría ni la utiliza. Para casi cualquier entorno, la versión de código abierto cubre todo lo necesario.

Envoy Gateway vive un momento dulce

Envoy lleva mucho tiempo siendo el motor oculto tras gran parte del mundo nativo de la nube: impulsa Istio, Contour, Cilium y la mitad de los proxies con los que interactúas sin darte cuenta. Envoy Gateway toma ese núcleo y lo envuelve en un controlador moderno y limpio, diseñado directamente en torno a Gateway API.

Gusta mucho porque arranca rápido, no impone la complejidad de una malla de servicios y no genera infraestructura imprevista. El proyecto goza de una comunidad de colaboradores muy activa y los operadores lo ven como una pasarela con mucho futuro y margen de crecimiento. Para los equipos que buscan algo más moderno que NGINX pero más ligero que un service mesh completo, Envoy Gateway da en el clavo.

Los usuarios de Cilium apuestan con todo por Cilium Gateway API

Quienes usan Cilium tienden con fuerza hacia la consolidación. Ya lo emplean como CNI, motor de eBPF, sustituto de kube-proxy e implementación de BGP, y a menudo también como perímetro de seguridad. Cuando Cilium sumó soporte para Gateway API, muchos equipos vieron la oportunidad de restar componentes en vez de añadir más. El atractivo es obvio: menos pods, menos demonios, menos capas y un plano de datos coherente.

Todavía quedan detalles por pulir. El soporte de TCPRoute aún no está completo y algunos echan en falta los registros HTTP centralizados que ofrecía Ingress-NGINX, pero la mayoría confía en que esas funciones llegarán pronto. Si tu clúster ya corre sobre Cilium, el atractivo de su pasarela resulta difícil de ignorar.

Istio no deja de aparecer, incluso sin usarlo como malla

Cada vez que alguien mencionaba Istio, otra persona respondía recordando que es toda una malla de servicios. Aun así, muchos ingenieros utilizan Istio únicamente por sus capacidades de entrada, sin sidecars y sin malla completa, usando solo los gateways.

Varios administradores describieron despliegues con múltiples pasarelas, algunas públicas y otras privadas, con cert-manager y ExternalDNS resolviendo la fontanería habitual. Es una solución estable, flexible y con una ruta clara hacia Gateway API sin obligarte a adoptar un mesh.

La fama de pesado que arrastra Istio no encaja con cómo se utiliza hoy en día. Para algunos equipos es simplemente una pasarela muy bien construida y curtida en mil batallas, que por casualidad incluye funciones de malla que jamás llegan a activar.

Contour es la opción discreta y fiable que siempre sale a relucir

Contour no genera tanto ruido en redes como otros proyectos, pero cosecha elogios constantes. Está construido sobre Envoy, admite Gateway API y tiene fama de ser predecible en el sentido exacto que valoran los equipos de plataforma: sin sobresaltos, sin sorpresas y sin sesiones agónicas de depuración. Quienes buscan estabilidad sin magia innecesaria suelen decantarse por Contour.

La comunidad de HAProxy es más pequeña pero muy leal

HAProxy no domina las conversaciones, pero quienes lo utilizan están plenamente convencidos de su elección. Algunos usan el enrutador de OpenShift, basado en HAProxy, mientras que otros prefieren los charts de Helm de haproxytech o experimentan con el nuevo HAProxy Unified Gateway, compatible tanto con Ingress como con Gateway API. Su rendimiento y su transparencia lo hacen muy atractivo, sobre todo para equipos que dependen a diario de registros detallados.

Mucha gente sigue recurriendo a nginx-ingress (el de F5)

Una de las partes más confusas de este cambio es la colisión de nombres. ingress-nginx es el controlador de la comunidad que se retira, mientras que nginx-ingress es el controlador de F5/NGINX Inc., que sigue manteniéndose activamente.

Numerosos operadores planean pasarse al controlador mantenido por F5 porque es lo más parecido a seguir trabajando como siempre. Si todo tu clúster ya habla mediante anotaciones de NGINX, esta vía apenas altera nada, y esa familiaridad pesa mucho más de lo que muchos admiten.

Algunos equipos se saltan Ingress y apuestan por la nube

Un grupo más reducido pero relevante de operadores prefiere no tener otro controlador corriendo en el clúster. Algunos enrutan el tráfico mediante Cloudflare Tunnels, AWS Load Balancer Controller, Azure Managed NGINX o los balanceadores de carga de GCP. Otros usan ALB con reescrituras puntuales en nginx, o Kong, Gloo o KGateway en arquitecturas muy orientadas a APIs.

La lógica es sencilla: si el proveedor de nube puede gestionar el punto de entrada por ti, quizá ya no necesites mantener una capa de ingress propia.

Una preocupación real: Gateway API añade fricción al trabajo diario

Con el recurso Ingress todo resultaba compacto y sencillo. Los desarrolladores creaban un único objeto y cert-manager junto con ExternalDNS hacían el resto sin coordinación adicional ni roles complejos.

Gateway API reparte las responsabilidades en múltiples recursos. Los certificados van en los Gateways, los nombres de host en las HTTPRoutes y los balanceadores de carga se generan en distintas capas según el controlador. Además, los desarrolladores pierden el control integral del flujo a menos que se les otorguen permisos que muchos equipos de plataforma prefieren no conceder.

Varios operadores comentaron que prefieren mantenerse en Ingress porque Gateway API complica su flujo de trabajo de formas que consideran prescindibles, aunque no tengan nada en contra de la API en sí. La esperanza es que las HTTPRoutes acaben aprendiendo a gestionar certificados, recuperando la sencillez que muchos echan de menos.

El ambiente final: cierta nostalgia, pero la mirada puesta al frente

Ingress-NGINX definió la conectividad en Kubernetes durante años. Fue la herramienta de aprendizaje, la respuesta por defecto y el caballo de batalla infatigable. Es lógico que su retirada despierte nostalgia, ya que impulsó desde pequeños homelabs hasta enormes despliegues multiclúster.

Sin embargo, los sustitutos ya están más que listos. Traefik se perfila como la opción pragmática y directa, mientras Envoy Gateway mira con decisión al futuro. Cilium empuja hacia una capa de red integrada, Istio encuentra un papel como pasarela más simple, y Contour junto con HAProxy se mantienen firmes como elecciones de total confianza. Para otros equipos, los balanceadores nativos de la nube sustituyen por completo a los controladores tradicionales.

El retiro no ha desatado el pánico, sino que ha sacado a la luz decisiones que los operadores ya habían tomado. Ingress-NGINX tuvo una trayectoria larga e influyente. Hoy no queda un único heredero, sino un abanico de excelentes alternativas que ya sostienen cargas de trabajo reales.