Red de contactos

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.

Mejorando la Resolución DNS del Service Mesh con la Capacidad de Proxy DNS de Istio: Beneficios y Casos de Uso

por
Mejorando la Resolución DNS del Service Mesh con la Capacidad de Proxy DNS de Istio: Beneficios y Casos de Uso

Istio es un popular service mesh de código abierto que proporciona una gama de potentes características para gestionar y asegurar arquitecturas basadas en microservicios. Hemos hablado mucho sobre sus capacidades y componentes, pero hoy hablaremos sobre cómo podemos usar Istio para ayudar con el mecanismo de resolución de DNS.

Como ya sabes, en una implementación típica de Istio, cada servicio está acompañado por un proxy sidecar, Envoy, que intercepta y gestiona el tráfico entre servicios. La capacidad de Proxy DNS de Istio aprovecha este proxy para manejar las solicitudes de resolución de DNS de manera más inteligente y eficiente.

Tradicionalmente, cuando un servicio dentro de una arquitectura de microservicios necesita comunicarse con otro servicio, depende de la resolución de DNS para descubrir la dirección IP del servicio objetivo. Sin embargo, la resolución de DNS tradicional puede ser difícil de gestionar en entornos complejos y dinámicos, como los que se encuentran en los clústeres de Kubernetes. Aquí es donde entra en juego la capacidad de Proxy DNS de Istio.

 Capacidades de Proxy DNS de Istio

Con Proxy DNS, Istio intercepta y controla las solicitudes de resolución de DNS de los servicios y realiza la resolución en su nombre. En lugar de depender de servidores DNS externos, los proxies sidecar manejan la resolución de DNS dentro del service mesh. Esto permite a Istio proporcionar varios beneficios valiosos:

  • Descubrimiento de servicios y balanceo de carga: El Proxy DNS de Istio permite mecanismos de descubrimiento de servicios más avanzados. Puede descubrir dinámicamente servicios y sus direcciones IP correspondientes dentro del mesh y realizar balanceo de carga entre instancias de un servicio en particular. Esto elimina la necesidad de que los servicios individuales gestionen la resolución de DNS y el balanceo de carga.
  • Seguridad y observabilidad: Istio obtiene visibilidad en el tráfico entre servicios al manejar la resolución de DNS dentro del mesh. Puede aplicar políticas de seguridad, como control de acceso y encriptación de tráfico, a nivel de DNS. Además, Istio puede recopilar datos de telemetría relacionados con DNS para monitoreo y observabilidad, proporcionando información sobre los patrones de comunicación entre servicios.
  • Gestión y control del tráfico: Proxy DNS permite a Istio implementar características avanzadas de gestión de tráfico, como reglas de enrutamiento e inyección de fallos, a nivel de resolución de DNS. Esto permite mecanismos sofisticados de control de tráfico dentro del service mesh, habilitando pruebas A/B, implementaciones canarias, ruptura de circuitos y otras estrategias de gestión de tráfico.

 Casos de Uso de Proxy DNS de Istio

Hay algunos momentos en los que no puedes o no quieres depender de la resolución normal de DNS. ¿Por qué es eso? Comenzando porque DNS es un gran protocolo pero carece de algunas capacidades, como el descubrimiento de ubicación. Si tienes el mismo DNS asignado a tres IPs, proporcionará cada una de ellas de manera circular y no puede depender de la ubicación.

O tienes varias IPs, y quieres bloquear algunas de ellas para algún servicio específico; estas son grandes cosas que puedes hacer con Istio Proxy DNS.

Habilitación de Proxy DNS de Istio

Debes saber que las capacidades de Proxy DNS de Istio no están habilitadas por defecto, por lo que debes ayudar si deseas usarlo. Lo bueno es que puedes permitirlo en diferentes niveles, desde el nivel completo del mesh hasta solo el nivel de un pod individual, por lo que puedes elegir lo que es mejor para ti en cada caso.

Por ejemplo, si queremos habilitarlo a nivel de pod, necesitamos inyectar la siguiente configuración en el proxy de Istio:

    proxy.istio.io/config: |
		proxyMetadata:   
         # Habilitar proxy DNS básico
         ISTIO_META_DNS_CAPTURE: "true" 
         # Habilitar asignación automática de direcciones, opcional
         ISTIO_META_DNS_AUTO_ALLOCATE: "true"

La misma configuración puede ser parte del nivel del Mesh como parte de la instalación del operador, como puedes encontrar la documentación aquí en la página oficial de Istio.

Conclusión

En resumen, la capacidad de Proxy DNS de Istio mejora el mecanismo de resolución de DNS dentro del entorno del service mesh, proporcionando descubrimiento de servicios avanzado, balanceo de carga, seguridad, observabilidad y características de gestión de tráfico. Istio centraliza y controla la resolución de DNS aprovechando los proxies sidecar, simplificando la gestión y optimización de la comunicación entre servicios en arquitecturas de microservicios complejas.

📚 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.

Cómo habilitar los registros de acceso en las rutas predeterminadas de Openshift

por
white and gray spiral stairs

Pon algo de cerebro cuando una ruta no funciona como se espera, o tus consumidores no pueden acceder al servicio

Todos sabemos que Openshift es una distribución de Kubernetes excepcional y una de las más utilizadas, principalmente cuando se habla de implementaciones en la nube privada. Basado en la sólida reputación de Red Hat Enterprise Linux, Openshift pudo crear un producto sólido que se está convirtiendo casi en un estándar para la mayoría de las empresas.

Proporciona muchas extensiones del estilo de Kubernetes Vanilla, incluyendo algunos de los estándares de la industria de código abierto como Prometheus, Thanos y Grafana para el monitoreo de métricas o la pila ELK para la agregación de registros, pero también incluye sus extensiones como las Rutas de Openshift.

Las Rutas de Openshift fueron la solución inicial antes de que el concepto de Ingress fuera una realidad dentro del estándar. Ahora, también se implementa siguiendo ese patrón para mantener la compatibilidad. Está respaldado por HAProxy, uno de los proxies inversos más conocidos disponibles en la comunidad de código abierto.

Una de las partes complicadas por defecto es saber cómo depurar cuando una de tus rutas no funciona como se espera. La forma en que creas rutas es tan fácil que cualquiera puede hacerlo en unos pocos clics, y si todo funciona como se espera, eso es genial.

Pero si no es así, los problemas comienzan porque, por defecto, no obtienes ningún registro sobre lo que está sucediendo. Pero eso es lo que vamos a resolver aquí.

Primero, hablaremos un poco más sobre cómo se configura esto. Actualmente (versión 4.8 de Openshift), esto se implementa, como dije, usando HAProxy por defecto, así que si estás usando otra tecnología como ingresses como Istio o Nginx, este artículo no es para ti (pero no olvides dejar un comentario si un artículo similar sería de tu interés para que también pueda llevarlo al backlog 🙂 )

Desde la perspectiva de la implementación, esto se implementa usando el Marco de Operadores, por lo que el ingreso se despliega como un Operador, y está disponible en el espacio de nombres openshift-ingress-operator.

Cómo habilitar los registros de acceso en las rutas predeterminadas de Openshift
pods del operador de ingreso en el ecosistema de Openshift

Entonces, como esto es un operador, se han instalado varias Definiciones de Recursos Personalizados (CRD) para trabajar con esto, una de las más interesantes de este artículo. Este CRD es Controladores de Ingreso.

Cómo habilitar los registros de acceso en las rutas predeterminadas de Openshift
Instancias de Ingreso en el Ecosistema de Openshift

Por defecto, solo verás una instancia llamada default. Esta es la que incluye la configuración del ingreso que se está desplegando, por lo que necesitamos agregar aquí una configuración adicional para tener también los registros.

Cómo habilitar los registros de acceso en las rutas predeterminadas de Openshift
Archivo YAML del controlador de ingreso

El fragmento que necesitamos es el que se muestra a continuación bajo el parámetro spec que comienza la definición de la especificación del IngressController en sí:

   logging:
    access:
      destination:
        type: Container
      httpLogFormat: >-
        log_source="haproxy-default" log_type="http" c_ip="%ci" c_port="%cp"
        req_date="%tr" fe_name_transport="%ft" be_name="%b" server_name="%s"
        res_time="%TR" tot_wait_q="%Tw" Tc="%Tc" Tr="%Tr" Ta="%Ta"
        status_code="%ST" bytes_read="%B" bytes_uploaded="%U"
        captrd_req_cookie="%CC" captrd_res_cookie="%CS" term_state="%tsc"
        actconn="%ac" feconn="%fc" beconn="%bc" srv_conn="%sc" retries="%rc"
        srv_queue="%sq" backend_queue="%bq" captrd_req_headers="%hr"
        captrd_res_headers="%hs" http_request="%r"

Esto hará que se despliegue otro contenedor en los pods del enrutador en el espacio de nombres openshift-ingress siguiendo el patrón sidecar llamado logs.

Cómo habilitar los registros de acceso en las rutas predeterminadas de Openshift
Pods del enrutador en la instalación de Openshift

Este contenedor imprimirá los registros de las solicitudes que llegan al componente de ingreso, por lo que la próxima vez que tu consumidor no pueda llamar a tu servicio, podrás ver las solicitudes entrantes con todos sus metadatos y saber al menos qué está haciendo mal:

Cómo habilitar los registros de acceso en las rutas predeterminadas de Openshift
Registros de acceso de la Ruta de Openshift

Como puedes ver, ¡simple y fácil! Si ya no lo necesitas, puedes eliminar la configuración nuevamente y guardarla, y la nueva versión se implementará y volverá a la normalidad.

📚 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.