Introducción
Los Ingress han sido, desde las primeras versiones de Kubernetes, la forma más habitual de exponer aplicaciones al exterior. Aunque su diseño inicial era sencillo y elegante, el éxito de Kubernetes y la creciente complejidad de los casos de uso han convertido al Ingress en una pieza problemática: limitado, inconsistente entre vendors y difícil de gobernar en entornos empresariales.
En este artículo analizamos por qué los Ingress se han convertido en una fuente constante de fricción, cómo han influido los distintos Ingress Controllers en esta situación y por qué cada vez más organizaciones están considerando alternativas como Gateway API.
Qué son los Ingress y por qué fueron diseñados así
El ecosistema de Ingress gira en torno a dos recursos principales:
🏷️ IngressClass
Define qué controlador gestionará los Ingress asociados. Su alcance es global al clúster, por lo que suele ser administrado por el equipo de plataforma.
🌐 Ingress
Es el recurso que los desarrolladores usan para exponer un servicio. Permite definir rutas, dominios, certificados TLS y poco más.
Su especificación es mínima por diseño, lo que permitió una adopción rápida, pero también sembró las bases de los problemas actuales.
El problema: un estándar demasiado simple para necesidades complejas
A medida que Kubernetes se convirtió en estándar empresarial, los usuarios querían replicar configuraciones avanzadas de proxies tradicionales: re-escrituras, timeouts, cabeceras personalizadas, CORS, etc.
Pero Ingress no daba soporte nativo a todo esto.
Los vendors reaccionaron… y ahí nació el caos.
Anotaciones vs CRDs: dos caminos incompatibles
Los distintos Ingress Controllers han tomado caminos muy diferentes para añadir capacidades avanzadas:
📝 Anotaciones (NGINX, HAProxy…)
Ventajas:
- Flexibles y fáciles de usar
- Directamente en el recurso Ingress
Desventajas:
- Cientos de anotaciones propietarias
- Documentación fragmentada
- Configuraciones no portables entre vendors
📦 CRDs personalizados (Traefik, Kong…)
Ventajas:
- Más estructurado y potente
- Mejor validación y control
Desventajas:
- Añade nuevos objetos no estándar
- Requiere instalarlos y gestionarlos
- Menor interoperabilidad
¿Resultado?
Infraestructuras profundamente acopladas a un vendor, lo que complica migraciones, auditorías y automatización.
La complejidad para los equipos de desarrollo
El diseño de Ingress implica dos responsabilidades muy diferenciadas:
- Plataforma: define IngressClass
- Aplicación: define Ingress
Pero la realidad es que el desarrollador acaba tomando decisiones que deberían ser responsabilidad del área de plataforma:
- Certificados
- Políticas de seguridad
- Reglas de reescritura
- CORS
- Timeouts
- Prácticas corporativas de naming
Esto provoca:
- Configuraciones inconsistentes
- Cuellos de botella en revisiones
- Dependencia constante entre equipos
- Falta de estandarización efectiva
En empresas grandes, donde la seguridad y la gobernanza son críticas, esto es especialmente problemático.
NGINX Ingress: la descomisión que reavivó el debate
La reciente descontinuación del NGINX Ingress Controller ha puesto en evidencia lo frágil del ecosistema:
- Miles de clústeres dependen de él
- Múltiples proyectos usan sus anotaciones
- Migrar implica reescribir configuraciones enteras
Esto ha reactivado la conversación sobre la necesidad de un estándar real… y ahí aparece Gateway API.
Gateway API: una alternativa prometedora (pero no perfecta)
Gateway API nace para resolver muchas de las limitaciones de Ingress:
- Separación clara entre responsabilidades (infraestructura vs aplicación)
- Extensibilidad estandarizada
- Más tipos de rutas (HTTPRoute, TCPRoute…)
- Mayor expresividad sin depender de anotaciones propietarias
Pero también trae desafíos:
- Requiere adopción gradual
- No todos los vendors implementan lo mismo
- La migración no es trivial
Aun así, se perfila como el futuro de la gestión de tráfico en Kubernetes.
Conclusión
Los Ingress han sido fundamentales para el éxito de Kubernetes, pero su propia simplicidad los ha llevado a convertirse en un cuello de botella. La falta de interoperabilidad, las diferencias entre vendors y la compleja gobernanza en entornos empresariales hacen evidente que es momento de adoptar modelos más maduros.
Gateway API no es perfecto, pero avanza en la dirección correcta.
Las organizaciones que quieran estabilidad a futuro deberían empezar a planificar su transición.
