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.
Preguntas frecuentes
¿Qué diferencia hay entre una Route de OpenShift y un Ingress de Kubernetes?
Route es la API nativa de OpenShift, anterior a Ingress, para exponer servicios; Ingress es el estándar upstream de Kubernetes. Se solapan funcionalmente, pero las Routes soportan de forma nativa los modos TLS de OpenShift (edge, reencrypt, passthrough), mientras que Ingress es portable a cualquier distribución.
¿OpenShift soporta el Ingress estándar de Kubernetes?
Sí. Al crear un Ingress, el router de OpenShift genera automáticamente las Routes equivalentes, así que los manifiestos upstream funcionan sin cambios. Las Routes generadas pertenecen al Ingress: edita el Ingress, no las Routes.
¿Route o Ingress en OpenShift?
Usa Ingress si tus manifiestos deben ser portables o vienen de Helm charts upstream. Usa Route cuando necesites comportamiento específico de OpenShift (reencrypt, passthrough) o tu plataforma sea OpenShift por política. Mezclar funciona, pero estandarizar en uno mantiene sanos los diffs de GitOps.
¿Cómo funciona el TLS cuando un Ingress genera una Route?
La configuración TLS del Ingress (bloque tls con un Secret de certificado) se traduce en una Route con terminación edge. Para reencrypt o passthrough necesitas Routes directamente o la anotación route.openshift.io/termination en el Ingress.