Ingress

Problemas con los Ingress en Kubernetes: limitaciones reales y por qué Gateway API es el futuro

por
Problemas con los Ingress en Kubernetes: limitaciones reales y por qué Gateway API es el futuro

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.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Uso de Ingress de Kubernetes en OpenShift: Cómo se Generan las Rutas y Cuándo Usar Cada Una

por
Uso de Ingress de Kubernetes en OpenShift: Cómo se Generan las Rutas y Cuándo Usar Cada Una

Introducción
OpenShift, la plataforma de Kubernetes de Red Hat, tiene su propia forma de exponer servicios a clientes externos. En Kubernetes estándar, normalmente usarías un recurso de Ingreso junto con un controlador de ingreso para enrutar el tráfico externo a los servicios. Sin embargo, OpenShift introdujo el concepto de un Ruta y un Enrutador integrado (construido sobre HAProxy) desde el principio, antes de que el Ingreso de Kubernetes siquiera existiera. Hoy en día, OpenShift admite tanto Rutas como objetos de Ingreso estándar, lo que a veces puede llevar a confusión sobre cuándo usar cada uno y cómo se relacionan.

Este artículo explora cómo OpenShift maneja los recursos de Ingreso de Kubernetes, cómo se traducen en Rutas, las limitaciones de este enfoque y orientación sobre cuándo usar Ingreso versus Rutas.

Rutas de OpenShift y el Enrutador: Una Visión Rápida


Las Rutas de OpenShift son recursos específicos de OpenShift diseñados para exponer servicios externamente. Son servidas por el Enrutador de OpenShift, que es un proxy basado en HAProxy que se ejecuta dentro del clúster. Las Rutas admiten características avanzadas como:

  • Backends ponderados para división de tráfico
  • Sesiones persistentes (afinidad de sesión)
  • Múltiples modos de terminación TLS (borde, paso a través, re-encriptar)
  • Subdominios comodín
  • Certificados personalizados y SNI
  • Enrutamiento basado en rutas

Debido a que las Rutas son nativas de OpenShift, el Enrutador entiende estas características de manera nativa y puede configurarse en consecuencia. Esta integración estrecha permite capacidades de enrutamiento poderosas y flexibles adaptadas a los entornos de OpenShift.

Uso de Ingreso de Kubernetes en OpenShift (Comportamiento Predeterminado)


A partir de OpenShift Container Platform (OCP) 3.10, se admiten los recursos de Ingreso de Kubernetes. Cuando creas un Ingreso, OpenShift lo traduce automáticamente en una Ruta equivalente detrás de escena. Esto significa que puedes usar manifiestos estándar de Ingreso de Kubernetes, y OpenShift se encargará de exponer tus servicios externamente creando Rutas en consecuencia.

Ejemplo: Ingreso de Kubernetes y Ruta Resultante

Aquí hay un manifiesto de Ingreso simple:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test-service
            port:
              number: 80

OpenShift creará una Ruta similar a:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: example-route
spec:
  host: www.example.com
  path: /testpath
  to:
    kind: Service
    name: test-service
    weight: 100
  port:
    targetPort: 80
  tls:
    termination: edge

Esta traducción automática simplifica la migración y admite casos de uso básicos sin requerir manifiestos específicos de Ruta.

Ajuste del Comportamiento con Anotaciones (Ingreso ➝ Ruta)

Cuando usas Ingreso en OpenShift, solo se respetan las anotaciones conscientes de OpenShift durante la traducción de Ingreso ➝ Ruta. Las anotaciones específicas del controlador para otros controladores de ingreso (por ejemplo, nginx.ingress.kubernetes.io/*) son ignoradas por el Enrutador de OpenShift. Las siguientes anotaciones son comúnmente usadas y admitidas por el enrutador de OpenShift para ajustar la Ruta generada:

Propósito Anotación Valores Típicos Efecto en la Ruta Generada
Terminación TLS route.openshift.io/termination edge · reencrypt · passthrough Establece spec.tls.termination de la Ruta al modo elegido.
Redirección HTTP→HTTPS (borde) route.openshift.io/insecureEdgeTerminationPolicy Redirect · Allow · None Controla spec.tls.insecureEdgeTerminationPolicy (comúnmente Redirect).
Balanceo de carga del backend haproxy.router.openshift.io/balance roundrobin · leastconn · source Establece el algoritmo de balanceo de HAProxy para la Ruta.
Timeout por ruta haproxy.router.openshift.io/timeout duración como 60s, 5m Configura el timeout de HAProxy para solicitudes en esa Ruta.
Cabecera HSTS haproxy.router.openshift.io/hsts_header por ejemplo, max-age=31536000;includeSubDomains;preload Inyecta la cabecera HSTS en las respuestas (borde/re-encriptar).

Nota: Las características avanzadas como backends ponderados/canario o hosts comodín no son expresables a través de Ingreso estándar. Usa una Ruta directamente para esos casos.

Ejemplo: Ingreso con anotaciones del enrutador de OpenShift

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress-https
  annotations:
    route.openshift.io/termination: edge
    route.openshift.io/insecureEdgeTerminationPolicy: Redirect
    haproxy.router.openshift.io/balance: leastconn
    haproxy.router.openshift.io/timeout: 60s
    haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: test-service
            port:
              number: 80

Este Ingreso se realizará como una Ruta con TLS de borde y una redirección automática de HTTP→HTTPS, usando balanceo de menos conexiones y un timeout de ruta de 60s. La cabecera HSTS será añadida por el enrutador en las respuestas HTTPS.

Limitaciones de Usar Ingreso para Generar Rutas
Aunque conveniente, usar Ingreso para generar Rutas tiene limitaciones:

  • Falta de características avanzadas: Los backends ponderados y las sesiones persistentes requieren anotaciones específicas de Ruta y no son compatibles a través de Ingreso.
  • Modos de paso a través y re-encriptar TLS: Estos requieren anotaciones específicas de OpenShift en las Rutas y no son compatibles a través de Ingreso estándar.
  • Ingreso sin host: Un Ingreso sin un nombre de host no creará una Ruta; las Rutas requieren un host.
  • Hosts comodín: Los hosts comodín (por ejemplo, *.example.com) solo son compatibles a través de Rutas, no Ingreso.
  • Compatibilidad de anotaciones: Algunas anotaciones de Ruta de OpenShift no tienen equivalentes en Ingreso, lo que lleva a brechas de configuración.
  • Soporte de protocolo: Ingreso solo admite protocolos HTTP/HTTPS, mientras que las Rutas pueden manejar protocolos no HTTP con TLS de paso a través.
  • Riesgo de deriva de configuración: Debido a que las Rutas creadas a partir de Ingreso son gestionadas por OpenShift, las ediciones manuales a la Ruta generada pueden ser sobrescritas o causar inconsistencias.

Estas limitaciones significan que para configuraciones de enrutamiento avanzadas o características específicas de OpenShift, es preferible usar Rutas directamente.

Cuándo Usar Ingreso vs. Cuándo Usar Rutas
Elegir entre Ingreso y Rutas depende de tus requisitos:

  • Usa Ingreso si:
  • Quieres portabilidad entre plataformas de Kubernetes.
  • Tienes manifiestos de Ingreso existentes y quieres minimizar los cambios.
  • Tu aplicación usa solo enrutamiento básico HTTP o HTTPS.
  • Prefieres manifiestos neutrales a la plataforma para pipelines de CI/CD.
  • Usa Rutas si:
  • Necesitas características avanzadas de enrutamiento como backends ponderados, sesiones persistentes o múltiples modos de terminación TLS.
  • Tu implementación es específica de OpenShift y puede aprovechar las características nativas de OpenShift.
  • Requieres estabilidad y soporte completo para las capacidades de enrutamiento de OpenShift.
  • Necesitas exponer protocolos no HTTP o usar modos de paso a través/re-encriptar TLS.
  • Quieres usar hosts comodín o anotaciones personalizadas no compatibles con Ingreso.

En muchos casos, los equipos usan una combinación: Ingreso para portabilidad y Rutas para necesidades avanzadas o específicas de OpenShift.

Conclusión


En OpenShift, los recursos de Ingreso de Kubernetes se convierten automáticamente en Rutas, permitiendo la exposición básica de servicios externos con un esfuerzo mínimo. Esto permite a los usuarios aprovechar los manifiestos existentes de Kubernetes y mantener la portabilidad. Sin embargo, para escenarios de enrutamiento avanzados y para utilizar completamente las potentes características del Enrutador de OpenShift, se recomienda usar Rutas directamente.

Ambos, Ingreso y Rutas, coexisten sin problemas en OpenShift, permitiéndote elegir la herramienta adecuada para los requisitos de tu aplicación.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.