Conceptos de red de Red Hat OpenShift en Azure

Este artículo ofrece una visión general de las redes de Red Hat OpenShift en Azure en clústeres de OpenShift 4. Incluye un diagrama y una lista de puntos de conexión importantes. Para más información sobre los conceptos básicos de las redes de OpenShift, consulte Documentación de redes de Red Hat OpenShift en Azure 4.

Diagrama de redes de Red Hat OpenShift en Azure.

Al implementar Red Hat OpenShift en Azure en OpenShift 4, todo el clúster se encuentra dentro de una red virtual. Dentro de esta red virtual, los nodos de plano de control y los nodos de trabajo se encuentran cada uno en su propia subred. Cada subred usa un equilibrador de carga interno y un equilibrador de carga público.

Nota:

Para obtener información sobre los cambios más recientes, consulte Novedades de Red Hat OpenShift en Azure.

Componentes de red

En la lista siguiente se describen los componentes de redes más importantes de un clúster de Red Hat OpenShift en Azure.

  • aro-pls

    • Este punto de conexión de Azure Private Link se usa por los ingenieros de confiabilidad de sitios de Microsoft y Red Hat para administrar el clúster.
  • aro-internal

    • El proceso de instalación del clúster crea este equilibrador de carga interno. Equilibra el tráfico hacia el servidor API en la red interna (api-int) y transporta el tráfico interno de servicios. Los nodos del plano de control y los nodos de trabajo están en el grupo de servidores back-end.
    • El gestor del controlador en la nube podría crear direcciones IP front-end adicionales para el Load Balancer interno al crear un servicio de Kubernetes de tipo LoadBalancer con la anotación service.beta.kubernetes.io/azure-load-balancer-internal: "true". Estas direcciones IP son distintas de las administradas por RP internal-lb-ip-v4.
  • aro

    • Este punto de conexión se usa para cualquier tráfico público. Cuando se crean una aplicación y una ruta, este extremo es la ruta del tráfico de entrada.
    • Este punto de conexión también enruta y equilibra el tráfico al servidor de API (si la API es pública). Este punto de conexión asigna una dirección IP pública de salida para que los planos de control puedan acceder a Azure Resource Manager e informar sobre el estado del clúster.
    • Este equilibrador de carga también cubre la conectividad de salida a Internet desde cualquier pod que se ejecute en los nodos de trabajo mediante reglas de salida de Azure Load Balancer.
      • Actualmente no se pueden configurar las reglas de salida. Se asignan 1024 puertos TCP a cada nodo.
      • La opción DisableOutboundSnat no está configurada en las reglas de LB, por lo que los pods podrían obtener como dirección IP de salida cualquier dirección IP pública configurada en este ALB.
      • Como consecuencia de los dos puntos anteriores, la única manera de agregar puertos SNAT efímeros es agregar servicios públicos de tipo LoadBalancer a Red Hat OpenShift en Azure.
  • aro-nsg

    • Cuando se expone un servicio, la API creará una regla en este grupo de seguridad de red para que el tráfico fluya y llegue al plano de control y a los nodos a través del puerto 6443.
    • De forma predeterminada, este grupo de seguridad de red permite todo el tráfico de salida. Actualmente, el tráfico de salida solo se puede restringir al plano de control de Red Hat OpenShift en Azure.
  • Azure Container Registry

    • Microsoft proporciona y usa internamente el registro de contenedor. Es de solo lectura y no está pensado para que lo utilicen los usuarios de Red Hat OpenShift en Azure.
      • Este registro proporciona las imágenes de la plataforma del host y los componentes del clúster. Por ejemplo, los contenedores de supervisión o registro.
      • Las conexiones a este registro se producen a través de un punto de conexión privado (conectividad interna entre los servicios de Azure).
      • De manera predeterminada, este registro interno no está disponible fuera del clúster.
  • Private Link

    • Un vínculo privado permite la conectividad de red desde el plano de administración hasta un clúster. Lo utilizan los ingenieros de fiabilidad del sitio de Microsoft y Red Hat para ayudar a gestionar el clúster.

Directivas de redes

  • Ingress: El complemento de red OVN-Kubernetes es compatible con la directiva de red de entrada. La directiva de red está habilitada de forma predeterminada y los usuarios la aplican. Las políticas de red de entrada cumplen con la especificación v1 de NetworkPolicy.

  • Egress: OpenShift admite directivas de red de salida a través de la función firewall de salida. Cada espacio de nombres o proyecto solo puede tener una directiva de salida. El espacio de nombres "predeterminado" no admite directivas de salida. El sistema evalúa las directivas de salida en orden, de la primera a la última.

Aspectos básicos de las redes en OpenShift

Red Hat OpenShift en Azure usa OVN-Kubernetes como complemento de red del clúster. OVN-Kubernetes proporciona una red superpuesta mediante túneles Geneve e implementa la especificación de la interfaz de red de contenedores (CNI). OVN-Kubernetes tiene aplicación integrada de directivas de red. La superposición administra la comunicación entre pods, por lo que tus redes virtuales no necesitan rutas adicionales.

Redes de Red Hat OpenShift en Azure

Las siguientes características de redes son específicas de Red Hat OpenShift en Azure:

  • Los usuarios pueden crear su clúster de Red Hat OpenShift en Azure en una red virtual existente o crear una nueva red virtual al crear su clúster.
  • Se pueden configurar los CIDR de la red de servicio y los pods.
  • Los nodos y los planos de control se encuentran en subredes diferentes.
  • Las subredes de la red virtual de los nodos y los planos de control deben ser /27 como mínimo.
  • El CIDR predeterminado del Pod es 10.128.0.0/14.
  • El CIDR del servicio predeterminado es 172.30.0.0/16.
  • Los CIDR de la red de pod y de servicio no se deben solapar con otros intervalos de direcciones en uso en la red. No deben estar dentro del intervalo de direcciones IP de red virtual del clúster.
  • Los CIDR de los pods deben tener un tamaño mínimo de /18. (La red de pods utiliza direcciones IP no enrutables y solo se usa dentro de la red superpuesta del clúster.)
  • A cada nodo se le asigna una subred /23 (512 direcciones IP) para sus pods. Este valor no se puede cambiar.
  • No se puede conectar un pod a varias redes.
  • En el caso de los clústeres privados que usan el complemento de red de OVN-Kubernetes, puede configurar direcciones IP de salida. Para obtener más información, consulte Configuración de una dirección IP de salida.

Configuración de red

La siguiente configuración de red está disponible para los clústeres de Red Hat OpenShift en Azure 4:

  • Visibilidad de la API: establezca la visibilidad de la API mediante la ejecución del comando az aro create.
    • Público : las redes externas pueden acceder al servidor de API.
    • Privado : el servidor de API asignó una dirección IP privada desde la subred del plano de control, a la que solo se puede acceder mediante redes conectadas (redes virtuales emparejadas y otras subredes del clúster).
  • Visibilidad de entrada: establezca la visibilidad de la API mediante la ejecución del comando az aro create.
    • Las rutas públicas son predeterminadas para un equilibrador de carga estándar público. (El valor predeterminado puede cambiarse).
    • Las rutas privadas son predeterminadas para un equilibrador de carga interno. (El valor predeterminado se puede cambiar.)

Grupos de seguridad de red

Los grupos de seguridad de red se crean en el grupo de recursos del nodo, que está bloqueado para los usuarios. Los grupos de seguridad de red se asignan directamente a las subredes, no a las NIC del nodo. Los grupos de seguridad de red son inmutables. Los usuarios no tienen los permisos para cambiarlos.

Con un servidor de API visible públicamente, no puede crear grupos de seguridad de red y asignarlos a las NIC.

Reenvío de dominios

Red Hat OpenShift en Azure usa CoreDNS como proveedor DNS en clúster y no se puede reemplazar. Puede configurar el reenvío de dominios para dirigir las consultas de dominios específicos a sus propios servidores DNS. Para más información, consulte la documentación sobre Uso del reenvío de DNS.

Pasos siguientes

Para obtener más información sobre el tráfico de salida y lo que Red Hat OpenShift en Azure admite para el tráfico de salida, consulte la documentación sobre directivas de soporte.