Conceptos de red de Red Hat OpenShift en Azure

Artículo
06/21/2023

En esta guía se describe una introducción a las redes Red Hat OpenShift en Azure en clústeres OpenShift 4, junto con 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.

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 últimos cambios introducidos en ARO, 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
- Este punto de conexión equilibra el tráfico al servidor de API y al tráfico interno del servicio. Los nodos del plano de control y los nodos de trabajo están en el grupo de back-end.
- Este equilibrador de carga no se crea de forma predeterminada. Se crea una vez que se crea un servicio de tipo LoadBalancer con las anotaciones correctas. Por ejemplo: service.beta.kubernetes.io/azure-load-balancer-internal: "true".
aro
- Este punto de conexión se usa para cualquier tráfico público. Al crear una aplicación y una ruta, este punto de conexión es la ruta para el 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 a ARO servicios públicos de tipo equilibrador de carga.
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 este 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 mediante el punto de conexión de servicio (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. Se usa por los ingenieros de confiabilidad de sitios de Microsoft y Red Hat para ayudar a administrar el clúster.

Directivas de redes

Entrada: la directiva de redes de entrada se admite como parte de OpenShift SDN. Esta directiva de red está habilitada de forma predeterminada y los usuarios llevan a cabo la aplicación. Aunque la directiva de red de entrada es compatible con V1 NetworkPolicy, no se admiten la salida ni los tipos IPBlock.
Salida: las directivas de red de salida se admiten mediante la característica de firewall de salida de OpenShift. Solo hay una directiva de salida por espacio de nombres o proyecto. Las directivas de salida no se admiten en el espacio de nombres "default" (predeterminado) y se evalúan por orden (de la primera a la última).

Aspectos básicos de las redes en OpenShift

Las redes definidas por software (SDN) de OpenShift se usan para configurar una red de superposición mediante Open vSwitch (OVS), una implementación de OpenFlow basada en la especificación de la interfaz de red del contenedor (CNI). SDN admite diferentes complementos. La directiva de red es el complemento que se usa en Red Hat OpenShift en Azure 4. SDN administra toda la comunicación de red, por lo que no se necesitan rutas adicionales en las redes virtuales para lograr la comunicación entre pod y pod.

Redes para 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 del pod predeterminado 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 pod deben tener un tamaño mínimo de /18. (La red del pod tiene direcciones IP no enrutables y solo se usa dentro del SDN de OpenShift).
Cada nodo está asignado a una subred /23 (512 direcciones IP) para los pods. Este valor no se puede cambiar.
No se puede conectar un pod a varias redes.
No se puede configurar una dirección IP estática de salida. (Esta restricción es una característica de OpenShift. Para obtener información, consulte Configuración de direcciones 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": el servidor de la API es accesible para redes externas.
- "Privado": el servidor de API asignó una dirección IP privada de la subred de planos de control, solo accesible mediante las 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" se establecen de forma predeterminada en una instancia pública de Standard Load Balancer. (El valor predeterminado; se puede cambiar).
- Las rutas "privadas" se establecen de forma predeterminada en 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. Se puede configurar el reenvío de dominios. No puede traer su propio sistema DNS a las redes virtuales. Para más información, consulte la documentación sobre Uso del reenvío de DNS.

Pasos siguientes

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