Redes Open Virtual Network (OVN) en Red Hat OpenShift para administradores de vSphere
Descubre en qué se diferencia la tecnología de redes Open Virtual Networking (OVN) de « Red Hat OpenShift on IBM Cloud » de NSX-T, y cómo utilizar los tipos de red «User-Defined Network» (UDN), «Cluster User-Defined Network» (CUDN) y «Localnet».
Si has utilizado NSX-T, ya entiendes la idea fundamental. Open Virtual Networking (OVN) es la capa de red definida por software integrada en OpenShift. Sustituye a la antigua pila de red « Calico » del mismo modo que NSX-T sustituyó a la pila estándar « vSwitches, », trasladando la inteligencia de red al software en lugar de depender de la red física subyacente. OVN se encarga de toda la red interna del clúster: cómo se comunican entre sí las máquinas virtuales, cómo acceden a las redes externas y cómo se aísla el tráfico entre inquilinos o cargas de trabajo.
Al implementar un nuevo clúster de ROKS, debes elegir entre OVN o Calico en el momento de la implementación. No existe una ruta de migración entre ambos, del mismo modo que no se puede cambiar de un « vSwitch » estándar a un « dvSwitch » en un « VM » en funcionamiento sin una transición planificada.
OVN es la capa de red definida por software integrada en Red Hat OpenShift on IBM Cloud. De forma similar a como NSX-T sustituye a vSwitches,, OVN sustituye a la antigua pila de red Calico al trasladar la inteligencia de red al software, en lugar de depender de la red física subyacente. OVN gestiona toda la red interna del clúster, incluyendo la forma en que las máquinas virtuales se comunican entre sí, cómo acceden a redes externas y cómo se aísla el tráfico entre inquilinos o cargas de trabajo.
Al implementar un nuevo clúster de Red Hat® OpenShift® on IBM Cloud®, debes elegir entre OVN o Calico en el momento de la implementación, ya que no existe una ruta de migración entre ambos. El cambio entre pilas de red requiere planificar la transición, de forma similar a lo que ocurre al cambiar entre un « vSwitch » estándar y un « dvSwitch » en una máquina virtual en funcionamiento.
Tipos de redes
La siguiente tabla establece una correspondencia entre los conceptos de OVN y las estructuras habituales de vSphere:
| Concepto OVN | vSphere equivalente |
|---|---|
| UDN o CUDN | Segmento lógico de NSX o dvPortGroup |
| Red de infraestructura de clúster (primaria) | Funcionamiento en segundo plano: comprobaciones de estado, DNS y servicios de Kubernetes |
| VM red de carga de trabajo (secundaria) | Tu red real VM: la dirección IP que utiliza tu aplicación |
| Baile de máscaras | Red con traducción de direcciones de red (NAT): las máquinas virtuales salen, pero no entra nada directamente |
| Secundaria de nivel 2 | Segmento superpuesto aislado de NSX: direcciones IP estáticas, control total |
| Nivel 2: Primaria | Segmento NSX enrutado con un enlace ascendente BGP a la red física |
| Red local | dvPortGroup con soporte VLAN: paso directo a la red física |
UDN y CUDN
Red Hat OpenShift agrupa las cargas de trabajo en espacios de nombres. Piensa en los espacios de nombres como conjuntos de recursos o carpetas que aíslan una aplicación o un equipo de otro. Las definiciones de red siguen el mismo patrón:
- Red definida por el usuario (UDN)
- Limitado a un único espacio de nombres: el equivalente a un grupo de puertos que solo puede utilizar un clúster o una carpeta.
- Red definida por el usuario en clúster (CUDN)
- Puede abarcar varios espacios de nombres: el equivalente a un dvPortGroup compartido al que se puede acceder desde varios clústeres.
Normalmente se configuran las CUDN porque son más flexibles y evitan tener que duplicar las definiciones de red para cada espacio de nombres que necesite acceder al mismo segmento.
Red de infraestructura de clúster frente a red de cargas de trabajo de « VM »
La terminología no resulta intuitiva, por lo que es importante comprender este concepto. OVN clasifica las redes como primarias o secundarias, pero esos nombres describen su función en el clúster de Red Hat OpenShift on IBM Cloud, no su importancia para tus máquinas virtuales. La correspondencia es la siguiente:
- Red de infraestructura de clúster (primaria)
- Infraestructura de fondo que gestiona el tráfico interno de Kubernetes, como comprobaciones de estado, detección de servicios, direcciones IP virtuales (VIP) del equilibrador de carga y el DNS interno. Por lo general, tus máquinas virtuales no utilizan esta red para el tráfico de aplicaciones. Manténla como una red de enmascaramiento. Esta red debe existir para que los pods y servicios internos de Red Hat OpenShift on IBM Cloud sigan funcionando.
- VM red de carga de trabajo (secundaria)
- Dónde se ejecutan las máquinas virtuales. Tus aplicaciones utilizan esta red, te conectas a su dirección IP mediante SSH y gestionas su subred. Al tratarse de una red secundaria, tienes control total sobre el direccionamiento IP, incluida la asignación estática. Esta red es la opción ideal para casi cualquier carga de trabajo de máquina virtual.
La denominación puede parecer contradictoria desde el punto de vista de las máquinas virtuales. Desde el punto de vista del clúster, «primario» se refiere a «la red propia del clúster», y «secundario» a «todo lo demás que se conecte a él» En el caso de las cargas de trabajo de máquinas virtuales, el aspecto secundario no es algo que se tenga en cuenta a posteriori. Esta red es la red principal.
Un espacio de nombres no necesita una red de infraestructura de clúster. Si tus máquinas virtuales no necesitan servicios de « Kubernetes », equilibradores de carga ni DNS interno, puedes omitir este paso y utilizar únicamente redes secundarias.
Topologías de red
Masquerade: red de infraestructura de clústeres (NAT)
Utiliza esta red como opción predeterminada para la red principal de la infraestructura del clúster y para los pods que se ejecutan en el clúster. Si lo utilizas para redes de máquinas virtuales, funciona como una máquina virtual protegida por una regla NAT en un NSX Edge:
- Las máquinas virtuales pueden establecer conexiones salientes con el exterior.
- Las máquinas virtuales no pueden recibir conexiones entrantes directas procedentes de fuentes externas. El tráfico debe pasar por un equilibrador de carga o un servicio, del mismo modo que se utilizaría una regla NAT de destino (DNAT) en un NSX Edge para dar acceso a un servicio.
- Las máquinas virtuales utilizan la asignación automática de direcciones IP. No lo gestionas.
- Las máquinas virtuales pueden utilizar todas las funciones de red de Kubernetes, incluidos los equilibradores de carga, los servicios, las políticas de red y el DNS.
Algunos casos de uso en el borde pueden requerir la red «masquerade» para tu máquina virtual, como por ejemplo cuando tus máquinas virtuales necesitan acceso directo a los servicios de Kubernetes. Sin embargo, en la mayoría de los casos de uso de máquinas virtuales no se utiliza la red de enmascaramiento.
Capa 2 primaria: red de máquinas virtuales enrutable directamente (enlace ascendente BGP)
Esta topología es equivalente a un segmento superpuesto de NSX conectado a una pasarela de « Tier-0 » con la redistribución de rutas BGP activada. Utiliza esta opción, menos habitual, cuando necesites que se pueda acceder directamente a las máquinas virtuales desde redes externas sin pasar por un equilibrador de carga o un NAT:
- Las máquinas virtuales reciben direcciones IP directamente de la subred del segmento y siguen siendo accesibles desde el exterior mediante el enrutamiento.
- Las redes externas se conectan a las máquinas virtuales individuales a través de los anuncios de rutas BGP que envía cada nodo de trabajo. Este enfoque equivale a lo que hace el enrutador de servicio (SR) de NSX Edge cuando redistribuye las rutas conectadas.
- Las máquinas virtuales admiten multidifusión y difusión.
- Los espacios de nombres no pueden utilizar la función «masquerade» cuando se habilita una red primaria de capa 2. Ambas cosas no pueden coexistir.
Actualmente, VPC no admite un servicio de enrutamiento dinámico (Protocolo de puerta de enlace fronteriza, BGP); por lo tanto, deben utilizarse rutas VPC personalizadas con salto siguiente.
La asignación de direcciones IP se realiza mediante un sistema DHCP que funciona según el principio de «por orden de llegada». Las direcciones IP no cambian durante el ciclo de vida de una máquina virtual, pero no es posible asignar previamente una dirección IP concreta a una máquina virtual específica. Si necesitas direcciones IP estáticas, utiliza en su lugar una red secundaria de capa 2.
Algunos casos de uso en el borde pueden requerir la red principal para tu máquina virtual, como por ejemplo cuando tus máquinas virtuales necesitan acceso directo a los servicios de Kubernetes. Sin embargo, en la mayoría de los casos de uso de máquinas virtuales no se utiliza la red principal.
Capa 2 secundaria: red de cargas de trabajo de máquinas virtuales (segmento aislado)
Utiliza este tipo de red para casi todos los casos de uso de máquinas virtuales. Esta topología equivale a un segmento superpuesto de NSX sin enlace ascendente externo: un segmento dedicado sobre el que tienes control total.
- Esta red admite la asignación de direcciones IP estáticas. Te encargas de la gestión de direcciones IP, lo cual es lo habitual en las cargas de trabajo de máquinas virtuales.
- Esta red no se conecta automáticamente con el exterior. Para proporcionar acceso externo, conecte un cortafuegos o un router virtual al segmento, del mismo modo que conectaría una máquina virtual NSX Edge o una máquina virtual « pfSense » a un segmento en vSphere.
- Admite multidifusión y difusión.
- Se pueden asociar varias redes secundarias de capa 2 a la misma máquina virtual. Esta configuración resulta útil para separar el tráfico de las aplicaciones, el de gestión y el de almacenamiento en distintos segmentos.
- La red puede abarcar varios espacios de nombres cuando se configura como CUDN.
Esta red es la opción más adecuada para la mayoría de las cargas de trabajo de máquinas virtuales en la virtualización de Red Hat OpenShift.
Localnet: paso directo de VLAN
Esta topología es el equivalente más cercano a un grupo de puertos estándar respaldado por una VLAN o a un grupo de puertos virtuales distribuidos ( dvPortGroup ) sin superposición de NSX. La máquina virtual se conecta directamente a la red a la que está conectado el host físico:
- Esta topología no utiliza una red superpuesta definida por software (SDN). El tráfico elude por completo la conmutación del software OVN.
- Esta topología no ofrece servicios de red de tipo « Red Hat OpenShift on IBM Cloud », como el equilibrio de carga, las políticas de red o el DNS interno.
- Esta topología no incluye gestión integrada de direcciones IP. Las direcciones IP se asignan mediante las interfaces de red virtual (VNI) de VPC.
- Esta topología se configura por zona de disponibilidad.
- Esta topología admite varias redes locales en la misma máquina virtual.
Utiliza «localnet» para las máquinas virtuales que necesiten acceso directo a una subred VPC ya existente. Por ejemplo, podrías migrar una carga de trabajo heredada que se comunica con sistemas locales a través de una VLAN específica o conectarte a una red de almacenamiento que se encuentra fuera del clúster.
Resumen
| Tipo de red | Rol | Acceso externo | Direcciones IP estáticas | Servicios de Kubernetes | Difusión / multidifusión |
|---|---|---|---|---|---|
| Baile de máscaras | Infraestructura de clúster | Salida a través de NAT | No | Sí | No |
| Nivel 2: primaria | Máquinas virtuales con enrutamiento directo | Sí, mediante el enrutamiento BGP | No (solo DHCP) | Sí | Sí |
| Secundaria de nivel 2 | Red de cargas de trabajo de máquinas virtuales | A través de un router o un cortafuegos conectado | Sí | Sí | Sí |
| Red local | Pasarela física de VLAN | Acceso directo a la VLAN | Manual | No | Sí |
Próximos pasos
Consulta estos temas relacionados para obtener más detalles sobre opciones específicas de la red OVN: