Después del NGINX Ingress Controller: Alternativas y Guía de Migración

Si gestionas clusters de Kubernetes en producción y llevas tiempo usando un NGINX Ingress Controller, este artículo es para ti. En los últimos meses, dos eventos han puesto el tema de los ingress controllers en primer plano: una serie de vulnerabilidades críticas bajo el nombre colectivo de IngressNightmare y el anuncio de deprecación estratégica por parte de F5/NGINX de su propio proyecto open source. El resultado es que muchos equipos de plataforma están revisando su posición y evaluando alternativas.

Este artículo no es una traducción de tendencias de Silicon Valley — es una guía técnica y operativa escrita desde la práctica de gestionar infraestructura Kubernetes real. Cubriremos qué ha pasado exactamente, qué opciones existen, cómo compararlas y cómo planificar una migración sin interrupciones en producción.

Dos proyectos, un mismo nombre: el problema de partida

Antes de entrar en alternativas, conviene aclarar algo que genera confusión frecuente: bajo el término «NGINX Ingress Controller» conviven dos proyectos completamente distintos.

ingress-nginx (kubernetes/ingress-nginx)

Mantenido por la comunidad bajo el paraguas del proyecto Kubernetes, ingress-nginx es el controlador que aparece recomendado en la documentación oficial de Kubernetes y el que la mayoría de equipos instala por defecto. Usa NGINX open source como proxy de datos, con configuración dinámica implementada mediante scripts Lua y la directiva nginx.conf generada automáticamente.

Es, con diferencia, el controlador de ingress más extendido en clusters autogestionados, instalaciones on-premise y la mayoría de entornos cloud que no usan soluciones propietarias del proveedor.

NGINX Ingress Controller (nginxinc/kubernetes-ingress)

Este es el proyecto comercial de F5/NGINX. Soporta NGINX Plus, usa las APIs nativas de NGINX en lugar del enfoque Lua-heavy, y está orientado a clientes enterprise que necesitan soporte con contrato. A diferencia de ingress-nginx, no usa anotaciones en el mismo formato y tiene su propia Helm chart con valores distintos.

Estos dos controladores no son intercambiables. Las anotaciones de configuración son diferentes, los valores de los Helm charts son diferentes, y el comportamiento ante casos extremos difiere de forma sustancial. Si alguien del equipo habla de «migrar del NGINX Ingress Controller», lo primero es confirmar de cuál de los dos se habla.

Lo que pasó en 2024-2025: vulnerabilidades y deprecación

IngressNightmare: CVE con CVSS 9.8

En marzo de 2024, el proyecto ingress-nginx acumuló un conjunto de vulnerabilidades críticas que los investigadores agruparon bajo el nombre IngressNightmare. La más grave obtuvo una puntuación CVSS de 9.8 y permitía ejecución remota de código sin autenticación a través del admission webhook.

El vector de ataque era el siguiente: el admission webhook de ingress-nginx valida los objetos Ingress cuando se crean o modifican. Un atacante con capacidad de crear o modificar recursos Ingress en el cluster — no necesariamente con privilegios de administrador — podía inyectar directivas de configuración arbitrarias de NGINX que se ejecutaban en el contexto del controlador, el cual corre con permisos elevados. Desde ahí, el salto a comprometer el cluster completo era trivial.

Los investigadores estimaron que aproximadamente el 43% de los entornos cloud analizados tenían instalaciones vulnerables expuestas. La superficie de ataque era particularmente amplia porque muchos equipos no eran conscientes de que el admission webhook escuchaba en una red accesible.

Las versiones que corrigen estas vulnerabilidades son la 1.11.5+ y la 1.12.1+. Si tu instalación está por debajo de esos números, tienes que actualizar o deshabilitar el admission webhook antes de hacer cualquier otra cosa.

F5/NGINX depreca su controlador open source

Paralelamente, F5/NGINX anunció que dejaba de desarrollar activamente el kubernetes-ingress open source y pivotaba hacia NGINX Gateway Fabric, una implementación de la Kubernetes Gateway API con NGINX como plano de datos. Este movimiento es coherente con la dirección general del ecosistema Kubernetes, pero deja a los equipos que usan el controlador open source de F5/NGINX con una decisión clara: migrar a NGINX Gateway Fabric o evaluar otras alternativas.

Impacto real en clusters en producción

Estos dos eventos — las vulnerabilidades y la deprecación — tienen tres consecuencias prácticas que cualquier equipo de plataforma debe gestionar:

1. Riesgo de seguridad inmediato. Una instalación de ingress-nginx sin parchear es una superficie de ataque crítica. Esto no es negociable: la actualización o el hardening del admission webhook es la primera acción, independientemente de cualquier decisión sobre migración.

2. Incertidumbre operativa a medio plazo. Incluso si parchas ahora, la pregunta sigue sobre la mesa: ¿tiene sentido seguir invirtiendo en un controlador con historial de CVEs críticos y una comunidad que tiene que gestionar deuda técnica acumulada? No hay una respuesta universal, pero el debate ya no puede posponerse.

3. Complejidad de migración de configuraciones. Los equipos que llevan años usando ingress-nginx tienen acumuladas configuraciones complejas basadas en anotaciones nginx.ingress.kubernetes.io/*. Migrar eso a otro controlador — o a Gateway API — requiere trabajo real. No es un cambio de Helm chart.

Alternativas al NGINX Ingress Controller

A continuación analizamos las principales opciones. No todas son equivalentes en madurez, complejidad operativa ni casos de uso ideales.

Traefik

Traefik es la alternativa más popular entre los equipos que salen de ingress-nginx. Escrito en Go, soporta simultáneamente la Ingress API estándar, sus propios CRDs IngressRoute, y la Gateway API de Kubernetes. Tiene automatización TLS integrada (Let’s Encrypt y otros proveedores ACME), un dashboard visual, y un modelo de configuración que muchos equipos encuentran más comprensible que NGINX.

Ventajas clave:
– Curva de aprendizaje baja para equipos que vienen de ingress-nginx
– TLS automation sin configuración adicional
– Soporte activo de Gateway API
– Muy buena integración con Prometheus y Grafana
– Helm chart mantenida y bien documentada

Limitaciones a considerar:
– El modelo de configuración dinámica puede generar comportamientos inesperados en migraciones complejas
– El dashboard, aunque útil, no sustituye a un sistema de observabilidad propio
– En cargas muy altas, el overhead de Go frente a implementaciones eBPF puede ser medible

Traefik es la opción de menor fricción para migraciones desde ingress-nginx. Si el objetivo principal es salir de NGINX sin comprometer semanas de trabajo, Traefik es probablemente el punto de partida más sensato.

Envoy Gateway

Envoy Gateway es un proyecto CNCF que implementa la Kubernetes Gateway API de forma nativa, usando Envoy como plano de datos. Envoy lleva años siendo el proxy subyacente de Istio y de los load balancers de grandes plataformas cloud, con lo que tiene una base técnica muy sólida.

Ventajas clave:
– Implementación de referencia de Gateway API — las features llegan antes que en otros controladores
– Plano de datos battle-tested a escala
– Separación de responsabilidades clara entre infraestructura y aplicaciones (ver sección Gateway API más abajo)
– Soporte robusto para routing avanzado: header-based, weight-based, retries, timeouts

Limitaciones a considerar:
– Curva de aprendizaje más pronunciada, especialmente si el equipo no tiene experiencia con Envoy
– La Gateway API tiene una abstracción diferente a Ingress — la migración requiere reescribir configuraciones, no solo adaptar anotaciones
– Relativamente más joven como proyecto autónomo (aunque el plano de datos es maduro)

Envoy Gateway es la elección estratégicamente más sólida si el equipo está dispuesto a invertir en aprender el modelo de Gateway API desde cero. A 18 meses vista, es probablemente donde está el ecosistema.

Cilium Gateway API

Si tu cluster ya usa Cilium como CNI, la Cilium Gateway API es una opción que merece evaluación seria. Cilium usa eBPF para procesar tráfico a nivel de kernel, eliminando el overhead del proxy userspace. El resultado es una reducción medible de latencia en percentiles altos (p99, p999) que en cargas intensas puede ser significativa.

Ventajas clave:
– Rendimiento superior gracias a eBPF — menos saltos de red, menos contexto switch
– Integración nativa con network policy de Cilium y con Hubble (observabilidad)
– Un único componente gestionando CNI, network policy e ingress — menos piezas en el cluster
– Implementación de Gateway API bien mantenida

Limitaciones a considerar:
– Solo tiene sentido si ya usas Cilium como CNI — añadir Cilium solo para el ingress no es justificable en la mayoría de casos
– La Gateway API de Cilium tiene gaps de features frente a Envoy Gateway o Traefik en algunos escenarios avanzados
– Cilium en sí tiene una curva de aprendizaje operativa no trivial

Si ya tienes Cilium, considera seriamente consolidar en Cilium Gateway API. Si no lo tienes, no es el punto de entrada.

HAProxy Ingress

HAProxy tiene reputación sólida en rendimiento bruto y control preciso del tráfico. El HAProxy Ingress Controller es una opción válida para equipos con experiencia previa en HAProxy — su modelo de configuración y sus capacidades de balanceo tienen décadas de madurez detrás.

Cuándo tiene sentido:
– El equipo tiene expertise en HAProxy y quiere mantener esa consistencia
– Se requieren capacidades de balanceo muy específicas que otros controladores no exponen fácilmente
– Migración desde un entorno que ya usaba HAProxy como load balancer externo

Cuándo no es la opción ideal:
– El equipo no conoce HAProxy — la curva de aprendizaje no se justifica frente a Traefik
– Se busca una implementación de Gateway API madura — HAProxy Ingress está más orientada a Ingress API estándar

Kong Ingress Controller

Kong ocupa un espacio propio: es más que un ingress controller, es una plataforma de API gateway con un sistema de plugins para autenticación, rate limiting, transformación de peticiones, logging avanzado, y más. Esto lo hace muy potente en contextos donde el ingress controller también tiene que cumplir funciones de API gateway.

Ventajas clave:
– Sistema de plugins muy extenso (autenticación OAuth/OIDC, JWT, rate limiting, transformaciones)
– Buena opción para organizaciones que necesitan API gateway y control de tráfico en un único componente
– Soporte de Gateway API y Ingress API

Limitaciones a considerar:
– Overhead operativo — en configuración stateful requiere una base de datos PostgreSQL; en modo declarativo (DB-less) tiene limitaciones
– No es la elección correcta si solo necesitas routing HTTP básico — hay herramientas más simples para eso
– Las licencias y el soporte enterprise tienen coste

Kong tiene sentido cuando los requisitos van más allá del routing: cuando necesitas un punto centralizado de gestión de políticas para APIs internas o externas.

Istio Gateway

Istio Gateway no es un ingress controller en el sentido tradicional — es la puerta de entrada del mesh de Istio. Si tu organización está planificando o ya operando un service mesh, Istio Gateway ofrece un plano de datos unificado con observabilidad consistente (métricas, trazas distribuidas, mTLS automático) en todos los servicios.

Cuándo tiene sentido:
– Ya tienes Istio desplegado o hay un plan firme de adoptarlo
– Necesitas observabilidad de nivel L7 consistente en todo el cluster
– mTLS entre servicios es un requisito no negociable

Cuándo no tiene sentido:
– Solo necesitas routing de entrada — Istio es overhead masivo para ese único caso
– El equipo no tiene experiencia con service meshes — la carga operativa es significativa
– Clusters pequeños o de desarrollo donde la complejidad no se justifica

NGINX Gateway Fabric

NGINX Gateway Fabric es la apuesta estratégica de F5/NGINX de cara al futuro: una implementación de Kubernetes Gateway API con NGINX como plano de datos. Es la ruta de migración natural para equipos fuertemente invertidos en el ecosistema NGINX.

Ventajas clave:
– Plano de datos NGINX familiar para equipos con expertise en él
– Implementación progresiva de Gateway API activamente desarrollada
– Ruta de migración oficial para usuarios de kubernetes-ingress (F5)

Limitaciones a considerar:
– Proyecto más joven que las alternativas consolidadas
– La implementación de Gateway API todavía cubre menos features que Envoy Gateway
– Si el objetivo es alejarse del ecosistema NGINX, este no es el camino

Tabla comparativa de controladores

Gateway API: la dirección estratégica del ecosistema

Para entender por qué tiene sentido evaluar ahora la migración a Gateway API — independientemente del controlador que elijas — hay que entender qué es y por qué representa una evolución genuina.

Limitaciones del recurso Ingress

El recurso Ingress de Kubernetes lleva en el ecosistema desde prácticamente los orígenes, y eso tiene un coste: su modelo es básico y las diferencias entre controladores se resuelven con anotaciones propietarias (nginx.ingress.kubernetes.io/*, traefik.ingress.kubernetes.io/*, etc.). El resultado es configuración que no es portable entre controladores y que mezcla responsabilidades que deberían estar separadas.

El modelo de Gateway API

La Gateway API introduce una jerarquía de recursos con separación de responsabilidades explícita:

GatewayClass — Define los tipos de gateway disponibles en el cluster. Lo gestiona el equipo de infraestructura o el proveedor de la plataforma. Es el punto de configuración de qué controlador se usa y con qué capacidades.

Gateway — Una instancia específica de un listener, con configuración de puertos, protocolos y certificados TLS. Lo gestiona el equipo de plataforma. Múltiples equipos de aplicación pueden compartir un mismo Gateway.

HTTPRoute, TCPRoute, GRPCRoute — Los recursos de routing gestionados por los equipos de aplicación. Definen cómo el tráfico que llega al Gateway se dirige a los servicios del backend.

Esta separación mapea directamente en los roles organizativos típicos: el equipo de plataforma controla el gateway, los equipos de aplicación controlan sus reglas de routing. Ya no hay que dar permisos de administrador de cluster para que un equipo de desarrollo configure su routing.

Estado actual de adopción

Gateway API alcanzó la versión v1.0 en octubre de 2023 y la v1.1 en 2024. Los recursos core (HTTPRoute, GatewayClass, Gateway) están en GA. La API networking.k8s.io/v1 de Ingress no está deprecada — sigue funcionando y seguirá haciéndolo indefinidamente — pero el desarrollo de nuevas features se hace exclusivamente en Gateway API.

La conclusión práctica es esta: si construyes plataformas de Kubernetes hoy, Gateway API es donde debe ir la inversión técnica. Los controladores que implementan Gateway API de forma nativa (Envoy Gateway, Cilium, NGINX Gateway Fabric) son la dirección correcta a medio plazo.

Framework de decisión: ¿qué hacer con tu situación actual?

Mantente en ingress-nginx si…

• Has parcheado a la versión 1.11.5+ o 1.12.1+ y has deshabilitado o hardened el admission webhook
• Tu configuración tiene alta densidad de anotaciones nginx.ingress.kubernetes.io/* y el coste de migración no está justificado ahora mismo
• Tienes expertise interno en NGINX que es difícil de reemplazar
• El horizonte del proyecto es corto (menos de 12 meses) y no hay presupuesto para infraestructura

En este caso, la acción inmediata es parchear y planificar la migración como trabajo planificado, no como crisis.

Migra ahora si…

• Estás usando el kubernetes-ingress open source de F5/NGINX (el deprecado) — no el ingress-nginx comunitario
• Tienes complejidad de anotaciones moderada y cycles de ingeniería disponibles
• Estás planificando una actualización mayor de Kubernetes de todas formas — es el momento de cambiar el controlador en el mismo proceso
• El equipo de seguridad ha marcado el historial de CVEs de ingress-nginx como inaceptable para tu perfil de riesgo
• Estás construyendo clusters nuevos o refactorizando la plataforma — aquí no hay deuda histórica que arrastrar

Evalúa antes de comprometerte si…

• Tienes requisitos de tráfico complejos (routing multi-tenant, políticas de seguridad avanzadas, service mesh parcial) — vale la pena verificar que el controlador destino los cubre antes de comprometerse
• La implementación de Gateway API de tu controlador candidato tiene gaps relevantes para tus casos de uso
• Tienes requisitos multi-cluster o multi-tenant que pueden cambiar las prioridades de la evaluación
• Necesitas un análisis completo de coste total (licencias, soporte, formación, horas de migración)

Checklist de migración paso a paso

Una migración de ingress controller mal planificada puede provocar downtime en producción. Este proceso en cuatro fases minimiza el riesgo.

Fase 1: Inventario y análisis

Antes de tocar nada en producción:

• Enumera todos los recursos Ingress del cluster por namespace: kubectl get ingress -A
• Documenta todas las anotaciones usadas — especialmente las no estándar
• Identifica configuraciones que podrían no tener equivalente directo en el controlador destino (custom snippets de NGINX, configuraciones de auth externo, etc.)
• Mapea todos los certificados TLS: origen (cert-manager, secretos manuales, wildcard), referencias en los Ingress, y cómo se gestionan las renovaciones
• Documenta snippets de configuración NGINX custom (nginx.ingress.kubernetes.io/server-snippet, configuration-snippet) — estos son los que más trabajo dan en la migración

Fase 2: Validación en entorno no productivo

• Despliega el controlador candidato en un cluster de staging con recursos Ingress idénticos a producción
• Valida TLS end-to-end para todos los dominios
• Prueba con carga representativa y compara métricas (latencia, throughput, error rate)
• Verifica la integración con tu stack de observabilidad (Prometheus, Grafana, alertas)
• Prueba los escenarios de fallo: ¿qué pasa si el controlador se reinicia? ¿si un backend no responde?
• Incluye los paths de autenticación externa si los tienes (OAuth2 Proxy, autenticación básica, etc.)

Fase 3: Migración a producción en fases

• Despliega el nuevo controlador junto al existente usando IngressClasses distintas. Esto es clave: no sustituyas el controlador actual hasta que el nuevo esté validado con tráfico real.
• Migra primero los recursos de menor riesgo: servicios internos, herramientas de desarrollo, endpoints de baja criticidad
• Usa DNS como mecanismo de canary: cambia el CNAME o el A record del dominio para apuntar al nuevo controlador, con TTL bajo para poder revertir rápido
• Monitoriza métricas durante 24-48 horas por cada batch de recursos migrados antes de continuar
• Mantén el controlador antiguo activo hasta que el 100% del tráfico esté en el nuevo y hayas validado estabilidad durante al menos una semana

Fase 4: Adopción de Gateway API (si aplica)

Si el plan es migrar a Gateway API (recomendado a medio plazo):

• Instala los CRDs de Gateway API: kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/...
• Define los recursos GatewayClass según el controlador (Envoy Gateway, Traefik, Cilium…)
• Migra rutas de forma progresiva, empezando por las más simples (routing básico sin transformaciones ni auth compleja)
• Actualiza pipelines de CI/CD para generar recursos HTTPRoute/GRPCRoute en lugar de Ingress
• Verifica que cert-manager funciona con Gateway API — soportado desde la versión 1.14 para HTTP-01 challenges

Preguntas frecuentes

¿Está deprecada la Ingress API de Kubernetes?

No. El recurso networking.k8s.io/v1/Ingress no está deprecado. Sigue funcionando y seguirá haciéndolo indefinidamente. Lo que ha cambiado es que las nuevas features solo se desarrollan en Gateway API. Los Ingress existentes continúan funcionando sin ningún cambio necesario.

¿Puedo ejecutar dos ingress controllers en paralelo durante la migración?

Sí, y es la forma recomendada de migrar. Kubernetes soporta múltiples recursos IngressClass, y cada recurso Ingress puede especificar qué controlador lo gestiona mediante spec.ingressClassName. Esto permite tener el controlador antiguo y el nuevo activos simultáneamente, migrando recursos de forma gradual y reversible.

¿cert-manager sigue funcionando si cambio de controlador?

Sí. cert-manager opera de forma independiente al ingress controller y funciona con cualquiera de las alternativas analizadas. Desde la versión 1.14, cert-manager también soporta Gateway API para los challenges HTTP-01, lo que permite usarlo tanto con Ingress API como con Gateway API.

¿Hay diferencias de rendimiento relevantes entre controladores?

Para la mayoría de workloads, la diferencia entre controladores maduros (ingress-nginx, Traefik, HAProxy, Envoy) es marginal. La excepción notable es Cilium con eBPF: al procesar el tráfico a nivel de kernel elimina el overhead del proxy userspace, lo que se traduce en mejoras medibles en percentiles altos (p99, p999) bajo carga intensa. Si el rendimiento en percentiles altos es crítico para tu aplicación, Cilium Gateway API merece una evaluación seria.

¿Qué pasa si usamos los load balancers nativos del proveedor cloud?

Usar los load balancers cloud nativos (AWS ALB Ingress Controller, GKE Gateway, Azure Application Gateway Ingress Controller) elimina la carga operativa de gestionar un ingress controller en el cluster. A cambio, introduces dependencia del proveedor y costes directos por recurso de load balancer. Es una opción válida para organizaciones completamente cloud-native que no tienen estrategia multi-cloud ni on-premise.

Recomendaciones concretas

Acciones inmediatas (próximos 30 días)

Si usas ingress-nginx:
1. Actualiza a la versión 1.11.5+ o 1.12.1+
2. Evalúa deshabilitar el admission webhook si no lo necesitas (--enable-admission-webhook=false) o restringe su acceso a red
3. Revisa los permisos RBAC del serviceaccount del controlador — aplica el principio de mínimo privilegio

Si usas kubernetes-ingress de F5/NGINX (open source):
1. Contacta con el equipo de F5/NGINX para obtener el timeline de deprecación concreto
2. Empieza la evaluación de NGINX Gateway Fabric en paralelo

Medio plazo (3-6 meses)

• Evalúa Traefik si buscas la migración de menor fricción desde ingress-nginx: la curva de aprendizaje es baja y la compatibilidad con configuraciones existentes es alta
• Evalúa Envoy Gateway si buscas la elección estratégicamente más sólida y el equipo tiene capacidad de invertir en aprender Gateway API desde cero
• Despliega el candidato en staging con carga real antes de comprometerte

Largo plazo (6-18 meses)

Independientemente del controlador de datos que elijas, planifica la migración de los recursos Ingress a recursos de Gateway API (HTTPRoute, GRPCRoute, etc.). La feature parity nunca llegará al recurso Ingress. Los equipos que construyan sobre Gateway API ahora tendrán las herramientas del ecosistema trabajando a favor en los próximos años.

Conclusión

La situación actual no es una crisis, pero sí un punto de inflexión. ingress-nginx parcheado es seguro a corto plazo. Pero la combinación de historial de CVEs, deuda técnica acumulada y la dirección clara del ecosistema hacia Gateway API hace que el debate sobre migración sea inevitable — solo se trata de cuándo y con cuánto control tienes sobre el proceso.

La recomendación práctica: parchea ahora, evalúa Traefik o Envoy Gateway en staging en los próximos meses, y planifica Gateway API como destino a 12-18 meses. No es trabajo de un sprint, pero tampoco es una reescritura desde cero — con el proceso por fases descrito aquí, es perfectamente manejable sin comprometer la estabilidad de producción.