Compartir a través de

Consideraciones de topología y conectividad de red de Red Hat OpenShift en Azure

  • Artículo

Revise las consideraciones y recomendaciones de diseño para la topología y conectividad de red al usar el acelerador de zonas de aterrizaje de Red Hat OpenShift en Azure.

Consideraciones de diseño

  • Red Hat OpenShift en Azure requiere una subred principal y una subred secundaria.

    • Use la subred principal para implementar los nodos maestros del clúster.
    • Use la subred secundaria para implementar los nodos de trabajo del clúster.
    • Tanto la subred secundaria como la subred principal deben ser una ruta de /27 mínima.
    • No se puede cambiar la subred secundaria ni la subred principal después de implementar el clúster.
    • La subred principal y la subred secundaria no pueden tener asociado un grupo de seguridad de red. El clúster de Red Hat OpenShift en Azure crea y administra automáticamente un grupo de seguridad de red.
    • La subred secundaria y la subred principal no se pueden superponer con redes locales ni con ninguna otra red de Azure.

  • Planifique con atención las direcciones IP y el tamaño de la subred de la red virtual para admitir el escalado del clúster. Es posible que tenga que agregar nodos.

  • Puede exponer los servicios y rutas de Red Hat OpenShift en Azure mediante equilibradores de carga públicos o internos. Configure equilibradores de carga internos en la misma subred que los nodos secundarios. En un clúster de salida restringida, no puede usar equilibradores de carga públicos debido al enrutamiento asimétrico.

  • Red Hat OpenShift en Azure usa CoreDNS para proporcionar resolución de nombres a los pods que se ejecutan en el clúster.

    • CoreDNS resuelve directamente los dominios internos del clúster.
    • Red Hat OpenShift en Azure también admite servidores DNS personalizados en la red virtual.
    • Otros dominios se reenvía a los servidores DNS configurados en Azure Virtual Network. Los servidores DNS serán el solucionador de Azure DNS predeterminado o cualquier servidor DNS personalizado que configure para cada red virtual.
    • Puede personalizar el reenvío de DNS en CoreDNS para Red Hat OpenShift en Azure.
    • Si en la red virtual no hay configurado ningún servidor DNS personalizado, Red Hat OpenShift en Azure usa la resolución de Azure DNS predeterminada.

    Para obtener más información sobre DNS, consulte Configuración de DNS para puntos de conexión privados de Azure.

  • Puede enviar tráfico de red de salida a través de Azure Firewall o a través de un clúster de aplicaciones virtuales de red.

  • De manera predeterminada, todos los pods de un clúster de Red Hat OpenShift en Azure pueden enviar y recibir tráfico sin limitaciones. Se puede acceder a todos los pods de un proyecto desde otros pods y puntos de conexión de red. Para aislar uno o varios pods de un proyecto, puede crear objetos NetworkPolicy en el proyecto para indicar las conexiones entrantes permitidas. Las conexiones en red definidas por software (SDN) de Red Hat OpenShift admiten el uso de una directiva de red en su modo de aislamiento de red predeterminado.

  • Una malla de servicio proporciona funcionalidades como administración del tráfico, resistencia, directiva, seguridad, identidad sólida y observabilidad. Para obtener más información sobre Red Hat OpenShift Service Mesh, consulte Diferencias entre Service Mesh e Istio.

  • Los mecanismos de equilibrio de carga global, como Azure Traffic Manager y Azure Front Door, aumentan la resistencia mediante el enrutamiento del tráfico entre varios clústeres y, posiblemente, diferentes regiones de Azure.

Clústeres privados

La dirección IP de un clúster de API de Red Hat OpenShift en Azure puede ser pública o privada. Los clústeres privados exponen la API de Red Hat OpenShift en Azure mediante una dirección IP privada, pero no una pública. No se debe acceder a la API de Red Hat OpenShift en Azure a través de su dirección IP. En su lugar, acceda a la API de Red Hat OpenShift en Azure a través de su nombre de dominio completo (FQDN). Azure DNS resuelve el FQDN de la API de Red Hat OpenShift en Azure en su dirección IP.

De manera similar a las prácticas probadas de la zona de aterrizaje de Azure, la resolución DNS para cargas de trabajo de Azure se ofrece mediante servidores DNS centralizados que se implementan en la suscripción de conectividad. Los servidores de Azure DNS se encuentran en una red virtual de concentrador o en una red virtual de servicios compartidos conectada a una instancia de Azure Virtual WAN. Los servidores DNS resuelven condicionalmente los nombres públicos y específicos de Azure mediante Azure DNS (dirección IP 168.63.129.16). Los servidores resuelven los nombres privados mediante servidores DNS corporativos. Este modelo de conectividad es común, y es importante permitir el acceso privado a otros recursos de Azure si se usan puntos de conexión privados.

Diagrama que muestra una red para un clúster privado.

Tráfico de los usuarios de la aplicación al clúster

Use controladores de entrada para exponer aplicaciones que se ejecutan en los clústeres de Red Hat OpenShift en Azure.

  • Los controladores de entrada proporcionan enrutamiento en el nivel de la aplicación con apenas un ligero aumento de la complejidad.
  • Red Hat OpenShift en Azure crea una entrada DNS genérica que simplifica el acceso a las aplicaciones expuestas en el clúster. Una entrada DNS de ejemplo es *.apps.<cluster-ID>.<region>.aroapp.io. Resulta útil para que un clúster privado enrute el tráfico de la aplicación.
  • Red Hat OpenShift en Azure ofrece un controlador de entrada y rutas integrados.
  • Puede usar la entrada de Red Hat OpenShift en Azure con Azure Front Door.
  • Alinee la configuración con el diseño de filtrado de salida para evitar un enrutamiento asimétrico. Las UDR podrían generar un enrutamiento asimétrico.
  • Si el escenario requiere la terminación TLS, tenga en cuenta cómo administrará los certificados TLS.

Importante

Si usa Azure Firewall para restringir el tráfico de salida y crea una UDR para forzar todo el tráfico de salida, asegúrese de crear una regla de traducción de direcciones de red de destino (DNAT) adecuada en Azure Firewall para permitir correctamente el tráfico de entrada. El uso de Azure Firewall con una UDR interrumpe la configuración de entrada debido al enrutamiento asimétrico. El problema se produce si la subred de Red Hat OpenShift en Azure tiene una ruta predeterminada que va a la dirección IP privada del firewall, pero está usando un equilibrador de carga público (de entrada o de servicio de Kubernetes del tipo Load Balancer). En este caso, el tráfico entrante del equilibrador de carga se recibe a través de su dirección IP pública, pero la ruta de vuelta pasa a través de la dirección IP privada del firewall. Dado que el firewall es con estado, quita el paquete de vuelta porque el firewall no detecta una sesión establecida. Para aprender a integrar Azure Firewall con el equilibrador de carga de entrada o de servicio, consulte Integración de Azure Firewall con Azure Standard Load Balancer.

En los pasos siguientes se describe el flujo si usa Azure Front Door con un clúster privado y un controlador de entrada de Red Hat OpenShift en Azure:

  1. Los clientes de la red pública de Internet resuelven el nombre DNS de la aplicación que apunta a Azure Front Door.
  2. Azure Front Door usa el servicio Azure Private Link para acceder a la dirección IP privada del equilibrador de carga de red interno de Azure y acceder a una aplicación en el controlador de entrada de Red Hat OpenShift en Azure.

En estos pasos se describe el flujo de una aplicación que no es web que accede a un clúster privado de Red Hat OpenShift en Azure:

  1. Los clientes de la red pública de Internet resuelven el nombre DNS de la aplicación que apunta a la dirección IP pública de Azure Firewall o a una aplicación virtual de red.
  2. Azure Firewall o la aplicación virtual de red reenvían el tráfico (DNAT) al clúster privado de Red Hat OpenShift en Azure mediante la dirección IP privada del equilibrador de carga de red interno de Azure para acceder a la aplicación en el controlador de entrada de Red Hat OpenShift en Azure.

Tráfico de los pods de Red Hat OpenShift en Azure a los servicios de back-end

Es posible que los pods que se ejecuten dentro del clúster de Red Hat OpenShift en Azure tengan que acceder a servicios de back-end, como Azure Storage, Azure Key Vault, Azure SQL Database y Azure Cosmos DB. Se pueden usar puntos de conexión de servicio de red virtual y Azure Private Link para proteger la conectividad a estos servicios administrados por Azure.

Si usa puntos de conexión privados de Azure para el tráfico de back-end, puede usar zonas DNS privadas de Azure para la resolución DNS para los servicios de Azure. Dado que los solucionadores de DNS para todo el entorno se encuentran en la red virtual del concentrador (o en la red virtual de servicios compartidos si se usa el modelo de conectividad de Virtual WAN), cree estas zonas privadas en la suscripción de conectividad. Para crear el registro A necesario para resolver el FQDN del servicio privado, puede asociar la zona DNS privada en la suscripción de conectividad con el punto de conexión privado en la suscripción de la aplicación. Esta operación requiere permisos específicos en esas suscripciones.

Puede crear los registros A manualmente, pero la asociación de la zona DNS privada con el punto de conexión privado genera una configuración menos propensa a errores.

La conectividad de back-end desde pods de Red Hat OpenShift en Azure a servicios de plataforma como servicio (PaaS) de Azure expuestos a través de puntos de conexión privados sigue esta secuencia:

  1. Los pods de Red Hat OpenShift en Azure resuelven el FQDN de la PaaS de Azure mediante los servidores DNS centrales de la suscripción de conectividad, que se definen como servidores DNS personalizados en la red virtual de Red Hat OpenShift en Azure.
  2. La dirección IP resuelta será la dirección IP privada de los puntos de conexión privados, a los que se accede directamente desde los pods de Red Hat OpenShift en Azure.

De manera predeterminada, el tráfico entre los pods de Red Hat OpenShift en Azure y los puntos de conexión privados no pasa por la instancia de Azure Firewall en la red virtual del centro de conectividad (ni el centro virtual protegido, si usa una instancia de Virtual WAN), incluso si el clúster de Red Hat OpenShift en Azure está configurado para el filtrado de salida con Azure Firewall. El punto de conexión privado crea una ruta /32 en las subredes de la red virtual de la aplicación en la que se implementa Red Hat OpenShift en Azure.

Recomendaciones de diseño

  • Si la directiva de seguridad requiere que use una dirección IP privada para la API de Red Hat OpenShift en Azure, implemente un clúster privado de Red Hat OpenShift en Azure.
  • Use Azure DDoS Protection para proteger la red virtual usada para el clúster de Red Hat OpenShift en Azure, a menos que use Azure Firewall o Web Application Firewall en una suscripción centralizada.
  • Use la configuración de DNS vinculada a la configuración de red general con Azure Virtual WAN o la arquitectura en estrella tipo hub-and-spoke, zonas de Azure DNS y su propia infraestructura de DNS.
  • Use Azure Private Link para proteger las conexiones de red y use la conectividad basada en IP privada con otros servicios de Azure administrados que admitan Private Link, como Azure Storage, Azure Container Registry, Azure SQL Database y Azure Key Vault.
  • Use un controlador de entrada para proporcionar seguridad y enrutamiento HTTP avanzados y ofrecer un único punto de conexión para las aplicaciones.
  • Todas las aplicaciones web que configure para usar una entrada deben usar el cifrado TLS y no deben permitir el acceso a través de HTTP sin cifrar.
  • Use Azure Front Door con Web Application Firewall para publicar de forma segura aplicaciones de Red Hat OpenShift en Azure en Internet.
  • Si la directiva de seguridad le exige inspeccionar todo el tráfico de salida de Internet que se genera en el clúster de Red Hat OpenShift en Azure, proteja el tráfico de red de salida mediante Azure Firewall o una aplicación virtual de red de terceros implementada en la red virtual del concentrador administrada. Para obtener más información, consulte Control del tráfico de salida a un clúster de Red Hat OpenShift en Azure.
  • Use el nivel estándar de Azure Load Balancer, en lugar del nivel básico, para aplicaciones que no sean web.

Pasos siguientes