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 se usa un recurso Ingress junto con un controlador de Ingress para enrutar el tráfico externo a los servicios. Sin embargo, OpenShift introdujo el concepto de Route y un router integrado (basado en HAProxy) mucho antes de que existiera Ingress en Kubernetes. Hoy OpenShift admite tanto Routes como objetos Ingress estándar, lo que a veces puede generar confusión sobre cuándo usar cada uno y cómo se relacionan. Este artículo explora cómo OpenShift maneja los recursos Ingress, cómo se traducen en Routes, las limitaciones de este enfoque y ofrece orientación sobre cuándo utilizar Ingress frente a Routes.
OpenShift Routes y el router: Panorama rápido. Las Routes son recursos específicos de OpenShift diseñados para exponer servicios externamente. Son atendidas por el router de OpenShift, un proxy basado en HAProxy que se ejecuta dentro del clúster. Las Routes admiten funciones avanzadas como:
- Backends ponderados para dividir el tráfico.
- Sesiones persistentes (afinidad de sesión).
- Varios modos de terminación TLS (edge, passthrough, re‑encrypt).
- Subdominios comodín.
- Certificados personalizados y SNI.
- Enrutamiento basado en rutas. Debido a que las Routes son nativas de OpenShift, el router comprende estas funciones de forma nativa y puede configurarse en consecuencia. Esta integración estrecha permite capacidades de enrutamiento potentes y flexibles adaptadas a entornos de OpenShift.
A partir de OpenShift Container Platform (OCP) 3.10, se admiten los recursos Ingress de Kubernetes. Cuando creas un Ingress, OpenShift lo traduce automáticamente en una Route equivalente tras bastidores. Esto significa que puedes usar manifiestos Ingress estándar y OpenShift se encargará de exponer tus servicios externamente creando Routes en consecuencia. Esta traducción automática simplifica la migración y admite casos de uso básicos sin necesidad de manifestos específicos de Route. El comportamiento se puede ajustar con anotaciones compatibles con el router de OpenShift (por ejemplo, route.openshift.io/termination, haproxy.router.openshift.io/balance, etc.).
Sin embargo, usar Ingress para generar Routes tiene limitaciones: muchas funciones avanzadas como los backends ponderados y las sesiones persistentes requieren anotaciones específicas de Route y no son compatibles a través de Ingress. Otros modos de TLS, como passthrough y re‑encrypt, también requieren anotaciones específicas de Route. Los Ingress sin host no crean una Route; las Routes requieren un nombre de host. Los hosts comodín solo son compatibles mediante Routes. Además, algunas anotaciones de Route no tienen equivalentes en Ingress. El soporte de protocolos también es más limitado en Ingress, que solo admite HTTP/HTTPS, mientras que las Routes pueden manejar protocolos no HTTP con TLS de paso.
La elección entre Ingress y Routes depende de tus requisitos: utiliza Ingress si buscas portabilidad entre plataformas Kubernetes, ya tienes manifiestos de Ingress existentes o tu aplicación usa solo enrutamiento HTTP/HTTPS básico. Utiliza Routes si necesitas funciones avanzadas como backends ponderados, sesiones persistentes o múltiples modos de terminación TLS; si tu despliegue es específico de OpenShift y puede aprovechar funciones nativas de la plataforma; si necesitas exponer protocolos no HTTP o usar hosts comodín o anotaciones personalizadas no compatibles con Ingress. Muchas veces, los equipos usan una combinación: Ingress para portabilidad y Routes para funciones avanzadas o específicas de OpenShift.
Conclusión: En OpenShift, los recursos Ingress de Kubernetes se convierten automáticamente en Routes, lo que permite exponer servicios externos con poco esfuerzo. Esto permite a los usuarios aprovechar manifiestos de Kubernetes existentes y mantener la portabilidad. Sin embargo, para escenarios de enrutamiento avanzados y para aprovechar plenamente las potentes funciones del router de OpenShift, se recomienda utilizar Routes directamente. Ambas opciones coexisten sin problemas en OpenShift, lo que te permite elegir la herramienta adecuada según los requisitos de tu aplicación.
