Ingress

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:

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.

Preguntas frecuentes