Cómo diseñar tu red para la virtualización de « Red Hat OpenShift » en IBM Cloud VPC
Diseña la red para la virtualización de « Red Hat OpenShift » en « IBM Cloud VPC », que abarca las redes VPC, las redes definidas por software (SDN) de « OpenShift » y las redes definidas por el usuario de «Open Virtual Networking» (OVN).
El diseño de red en Red Hat OpenShift Virtualization en IBM Cloud VPC tiene las siguientes capas diferenciadas.
- Redes VPC
- Red Hat OpenShift creación de redes
- Red OVN
Los elementos clave de la arquitectura de red se muestran en el siguiente diagrama.
IBM Cloud VPC creación de redes
Utiliza la red IBM Cloud VPC para desplegar y gestionar recursos en la nube. Proporciona la base para sus cargas de trabajo, incluidos servidores virtuales, contenedores e implantaciones bare metal, que pueden ayudar a garantizar la segmentación, seguridad y escalabilidad de la red.
Debes crear una VPC para configurar un Red Hat® OpenShift® Kubernetes Service grupo.
Red privada predeterminada con subredes
Es necesario crear una subred VPC en al menos una zona de disponibilidad para aprovisionar un clúster Red Hat OpenShift Kubernetes Service. Para obtener más información, consulte Red privada predeterminada con subredes.
Equilibradores de carga
En su clúster Red Hat OpenShift Kubernetes Service se instala un controlador de entrada Red Hat OpenShift que funciona como punto final de entrada para el tráfico de red externo. En un clúster Red Hat OpenShift Kubernetes Service, se crea automáticamente un equilibrador de carga de aplicaciones VPC por clúster para exponer el controlador de entrada. Para más información, consulte Balanceadores de carga.
Red Hat OpenShift Kubernetes Service realiza las siguientes funciones.
- El servicio DNS resuelve el subdominio de la ruta al nombre de host del equilibrador de carga de la VPC.
- El equilibrador de carga de la VPC resuelve el nombre de host de la VPC a una dirección IP externa disponible de un servicio de controlador de entrada que se ha notificado que funciona correctamente.
- El equilibrador de carga de la VPC envía la solicitud a un servicio de controlador de entrada.
- El controlador de Ingress reenvía la solicitud a la dirección IP privada del pod de aplicación a través de la red privada.
Puntos finales privados virtuales
Los puntos finales privados virtuales (VPE) en entornos Red Hat OpenShift Kubernetes Service se utilizan principalmente para permitir la conectividad privada entre el clúster Red Hat OpenShift y los servicios de la plataforma IBM Cloud sin tráfico de red que atraviese la Internet pública.
La siguiente tabla enumera todos los puntos finales privados virtuales que IBM Cloud aprovisiona automáticamente para las operaciones esenciales del clúster.
| Punto final privado virtual | Gestionado por | Descripción |
|---|---|---|
| iks-api | Kubernetes Service API |
|
| iks-riaas | Servicios de la infraestructura de la VPC |
|
| Registro IKS | Registro de contenedor |
|
| iks-<id_del_clúster> | Instancia de clúster específica |
|
| iks-cos-config | Cloud Object Storage (Configuración) |
|
| iks-cos | Cloud Object Storage (Datos) |
|
Red Hat OpenShift Redes de virtualización
Red Hat OpenShift La virtualización utiliza las capacidades de red de Red Hat OpenShift para proporcionar redes flexibles y definidas por software para servidores virtuales que se ejecutan junto con cargas de trabajo en contenedores. Es importante
entender la diferencia entre las redes de servidores virtuales y las redes de pods. Cada servidor virtual se ejecuta dentro de un pod virt-launcher que siempre está conectado a la red predeterminada del pod.
┌────────────────────────────────┐
│ Worker Node │
│ ┌──────────────────────────┐ │
│ │ virt-launcher │ │ ← Kubernetes Pod Security Context
│ │ pod │ │
│ │ ┌────────────────────┐ │ │
│ │ │ virtual server │ │ │ ← KVM/QEMU Hypervisor Isolation
│ │ │ (QEMU) │ │ │
│ │ └────────────────────┘ │ │
│ └──────────────────────────┘ │
└────────────────────────────────┘
Dependiendo de cómo aprovisione y configure su servidor virtual, éste comparte una red pod (o puede conectarse a diferentes redes utilizando multus).
El siguiente ejemplo describe la red de pods por defecto en Red Hat OpenShift que puede modificar con la red OVN- Kubernetes.
Redes pod (red de clústeres)
- Cada pod recibe una dirección IP privada de la red del clúster mediante el protocolo de enrutamiento entre dominios sin clases (CIDR)
- Comunicación entre nodos
- Los pods se comunican directamente utilizando sus IP privadas dentro del cluster
- Las políticas de red controlan el tráfico de pod a pod en la capa 3/4
- Modelo de red plana: todos los pods pueden comunicarse por defecto
- Sin NAT entre pods (comunicación directa de pod a pod)
- Las políticas de red proporcionan segmentación y seguridad
- Descubrimiento de servicios basado en DNS dentro del clúster
- Cuando un servidor virtual se ejecuta dentro del pod «virt-launcher», la dirección IP se somete a traducción de direcciones de red (NAT) con la dirección IP del pod «virt-launcher»
Enmascaramiento de direcciones IP (NAT de origen (SNAT))
- Cuando los pods inician conexiones salientes a redes externas, la IP de origen se enmascara
- La dirección IP de origen del paquete de solicitud se cambia por la dirección IP del nodo de trabajo en el que se ejecuta el pod
- El enmascaramiento de IP es necesario porque las IP de los pods no son enrutables fuera del clúster
- El tráfico de retorno es demasqueraded de nuevo a la IP original del pod
- Los servicios externos ven las peticiones que provienen de las IPs de los nodos trabajadores, no de las IPs de los pods
ClusterIP servicio
Los servicios proporcionan puntos finales estables y equilibrio de carga para los pods. Abstraen las IP de los pods y proporcionan puntos de acceso coherentes para las aplicaciones. El servicio ClusterIP ofrece las siguientes funciones.
- Crea una IP virtual ( ClusterIP ) accesible sólo dentro del cluster
- ClusterIP es el tipo de servicio por defecto si no se especifica
- Proporciona equilibrio de carga interno entre los pods de backend
- Utiliza kube-proxy u OVN- Kubernetes para la distribución del tráfico
Los siguientes casos de uso son un ejemplo de para qué se utiliza ClusterIP.
- Comunicación interna de microservicios
- Servicios backend que no requieren acceso externo
- Servicios de base de datos a los que sólo acceden las cargas de trabajo del clúster
- Descubrimiento de servicios intermodales
Servicio NodePort
Los servicios proporcionan puntos finales estables y equilibrio de carga para los pods. Abstraen las IP de los pods y proporcionan puntos de acceso coherentes para las aplicaciones. El servicio NodePort ofrece las siguientes funciones.
- Expone el servicio en un puerto estático (rango 30000-32767) en cada nodo trabajador
- Hace accesible el servicio a través de
<NodeIP>:<NodePort> - Crea automáticamente el servicio ClusterIP
- El tráfico a cualquier NodePort se reenvía al servicio
El siguiente ejemplo muestra el flujo de tráfico NodePort.
- El cliente externo se conecta a
<WorkerNodeIP>:<NodePort> - Los nodos reenvían el tráfico al servicio ClusterIP
- El servicio equilibra la carga a los pods backend
- La respuesta sigue la ruta inversa mediante SNAT (traducción de direcciones de red de origen)
Los siguientes casos de uso son un ejemplo de para qué se utiliza NodePorts.
- Entornos de desarrollo y pruebas
- Acceso externo rápido sin equilibrador de carga
- Integración con balanceadores de carga externos
- Soluciones personalizadas de equilibrio de carga
Servicio equilibrador de carga
En IBM Cloud Red Hat OpenShift Kubernetes Service, el servicio de equilibrador de carga aprovisiona automáticamente un equilibrador de carga de red VPC o un equilibrador de carga de aplicaciones. El servicio de balanceador de carga proporciona las siguientes funciones.
- Aprovisiona automáticamente un equilibrador de carga externo
- Asigna IP externa o nombre de host al servicio
- Crea automáticamente los servicios NodePort y ClusterIP
- Proporciona equilibrio de carga de capa 4 a los backends de servicio
El siguiente ejemplo muestra el flujo de tráfico en una VPC.
- El cliente externo se conecta a la IP o al nombre de host del equilibrador de carga de la VPC
- El equilibrador de carga de la VPC distribuye al nodo trabajador NodePorts
- Node adelante al servicio ClusterIP
- El servicio equilibra la carga a los pods backend
Los siguientes casos de uso son un ejemplo de para qué se utilizan los equilibradores de carga.
- Aplicaciones de producción que requieren un acceso externo específico
- Protocolos no HTTP (servicios TCP o UDP )
- Aplicaciones que necesitan IP externas estables
- Servicios que eluden la capa de entrada o ruta
Red Hat OpenShift rutas
Red Hat OpenShift Las rutas exponen los servicios al tráfico de red externo mediante la asignación de nombres de dominio completos (FQDN) a los servicios de fondo, lo que permite acceder a las aplicaciones desde fuera del clúster. La siguiente lista muestra las principales características de Red Hat OpenShift Routes.
- Enrutamiento de Capa 7 - HTTP / HTTPS tráfico con enrutamiento basado en nombres de host
- DNS automático - las rutas utilizan el subdominio del clúster:
<route-name>-<namespace>.apps.<cluster-domain> - Rutas no aseguradas ( HTTP )
- Terminación TLS
- Rutas terminadas en el borde ( TLS en el router)
- Rutas de paso ( TLS en Pod)
- Reencriptar rutas ( TLS en el router y Pod)
- HAProxy-es implementado por el controlador de entrada (router) Red Hat OpenShift
- Gestión del tráfico - Enrutamiento basado en rutas, división del tráfico y afinidad de sesiones
Redes virtuales abiertas (OVN)
El complemento OVN- Kubernetes Container Network Interface (CNI) es la opción de red recomendada para la virtualización « Red Hat OpenShift », que admite casos de uso de redes de servidores virtuales que se ejecutan junto con las redes de pods tradicionales. OVN- Kubernetes se basa en Open Virtual Networking (OVN) y utiliza Open vSwitch (OVS) en cada nodo de trabajo. Admite multitenencia, NetworkPolicies, y redes híbridas de servidores virtuales y pods. Red Hat OpenShift on IBM Cloud VPC admite OVN- Kubernetes como complemento de red predeterminado.
Los administradores familiarizados con VMware vSphere y NSX-T pueden consultar la sección «Redes OVN» en OpenShift, dirigida a administradores de vSphere, donde encontrarán una correspondencia entre los conceptos de OVN y sus equivalentes en vSphere.
En Red Hat OpenShift con OVN, las siguientes tres topologías de red proporcionan conectividad de red secundaria a pods y servidores virtuales.
- Capa 2 ( L2 )- Dominios de difusión L2 definidos por software mediante encapsulación Geneve
- Capa 3 ( L3 )- Segmentos de red enrutados con subredes IP personalizadas. Una red « L3 » tiene un CIDR (enrutamiento entre dominios sin clases) independiente para cada nodo.
- Localnet - Acceso directo a las VLAN de la red física subyacente
En Red Hat OpenShift Virtualization on IBM Cloud, OVN layer 2 y OVN localnet son las dos topologías principales que se utilizan con las Redes Definidas por el Usuario (UDN).
- OVN Layer 2 proporciona una red superpuesta similar a los segmentos superpuestos de NSX mediante el uso de la encapsulación Geneve para crear dominios de difusión L2 definidos por software en todo el clúster. Estas redes están aisladas de las subredes de la VPC. Requieren un pod gateway o servidor virtual que esté conectado a una OVN Localnet para proporcionar entrada y salida a la subred VPC y una ruta VPC.
- OVN Localnet proporciona acceso VLAN a la red VPC subyacente y es similar a los segmentos respaldados por VLAN de NSX. En IBM Cloud VPC, esta conectividad directa permite a los servidores virtuales y a los pods conectarse directamente a las subredes de la VPC utilizando una interfaz de red virtual (VNI) y anexos VLAN.
El siguiente diagrama presenta una visión general de la red de servidores virtuales con OVN y multus. Por defecto, Kubernetes (y Red Hat OpenShift ) asigna una única interfaz de red a cada pod utilizando un plug-in CNI primario
(como OVN- Kubernetes ). Multus en Red Hat OpenShift es un plug-in CNI que permite múltiples interfaces de red para pods y servidores virtuales.
Inicialmente, sólo está disponible la red OVN de capa 2.
Redes definidas por el usuario OVN
Red Hat OpenShift Virtualización
Una red definida por el usuario (UDN) en Red Hat OpenShift es una red personalizada que proporciona OVN- Kubernetes. Una UDN sustituye a la red de clúster predeterminada (también conocida como red de pod predeterminada) UDNs que se utilizan para crear redes con sus propias subredes IP, puertas de enlace y dominios de enrutamiento. Las UDN son independientes de la red pod primaria y se suelen utilizar cuando las cargas de trabajo requieren las siguientes funciones.
- Aislamiento de la red de otras aplicaciones del clúster
- Rangos de direcciones IP personalizados o subredes solapadas
- Control directo del tráfico este-oeste entre espacios de nombres o cargas de trabajo seleccionados
- Integración con servidores virtuales ( virtualización Red Hat OpenShift ) que requieren múltiples interfaces de red
- Segmentos de red dedicados para requisitos de seguridad o cumplimiento de normativas
A diferencia de la red de pods predeterminada, las UDN se adjuntan explícitamente a los espacios de nombres. Cada UDN crea un conmutador lógico adicional en OVN. Cuando una UDN se etiqueta como red principal definida por el usuario del espacio de nombres, todos los pods y servidores virtuales de ese espacio de nombres la utilizan como red principal en lugar de la predeterminada del clúster.
La red definida por el usuario de clúster (CUDN) amplía el concepto de UDN proporcionando un recurso de ámbito de clúster que no pertenece a ningún espacio de nombres específico. Se crea un CUDN y se asocia a uno o varios espacios de nombres.
A diferencia de los recursos NetworkAttachmentDefinition (NAD) de espacio de nombres que requieren uno por espacio de nombres, una CUDN crea automáticamente NADs en espacios de nombres cuando dichos espacios de nombres se añaden
a la definición de la CUDN.
Las UDN ofrecen opciones de red flexibles basadas en el alcance, el método de conexión y la topología:
Ámbito de la red
- UDN con ámbito de espacio de nombres: definición de red limitada a un único espacio de nombres, que requiere NetworkAttachmentDefinitions independiente para cada espacio de nombres
- CUDN en clúster: definición de red disponible en todo el clúster, que crea automáticamente NetworkAttachmentDefinitions en los espacios de nombres seleccionados
Método de fijación
- Red primaria: actúa como red predeterminada para todos los pods/servidores virtuales del espacio de nombres, sustituyendo a la red predeterminada del clúster
- Red secundaria - Conectada a través de Multus CNI para proporcionar interfaces de red adicionales a los pods/servidores virtuales junto con la red primaria
Topología de la red
- Capa 2: dominio de difusión « L2 » definido por software mediante el uso de la encapsulación Geneve, que permite el descubrimiento basado en el Protocolo de Resolución de Direcciones (ARP) y la comunicación de MAC a MAC
- Capa 3 - Segmentos de red enrutados con subredes IP y pasarelas personalizadas
- Localnet - Acceso VLAN directo a subredes VPC subyacentes mediante el uso de adjuntos de interfaz de red virtual (VNI)
Puede combinar estas características para crear soluciones de red personalizadas. Por ejemplo, una CUDN con ámbito de clúster que utilice la topología localnet puede proporcionar varios espacios de nombres con acceso directo a la subred de la VPC como red primaria o secundaria.
Redes OVN de nivel 2
Una red de capa 2 OVN es un dominio de difusión de capa 2 definido por software que es similar a un segmento superpuesto NSX o a una VLAN tradicional. La capa 2 se implementa completamente dentro de OVN utilizando encapsulación Geneve sobre la infraestructura de red existente del cluster. Una red de Capa 2 permite que los pods y los servidores virtuales se comuniquen como si estuvieran en el mismo segmento Ethernet, con soporte para descubrimiento ARP, difusión, multidifusión y comunicación directa MAC-a-MAC.
Un cluster Red Hat OpenShift tiene una red de cluster primaria donde los pods y servidores virtuales reciben IPs desde el CIDR de cluster por defecto que se enruta a través de OVN. Se define una red secundaria de Capa 2 a través de una ClusterUserDefinedNetwork (CUDN) o una UDN de espacio de nombres. Una red secundaria de capa 2 es cualquier red adicional que se cree además de la red de pods predeterminada.
Los siguientes elementos son características clave de las redes de Capa 2.
- Proporcionar dominios de difusión de Capa 2 creados por OVN con IPAM, asignación de MAC y conectividad
- No hay resolución DNS integrada para nombres de pods en redes secundarias
- El tráfico procedente de la red principal de capa 2 se somete a traducción de direcciones de red (NAT) al salir del servidor virtual y, además, se enruta hacia la red de capa 2, cuyo acceso se puede configurar mediante
FRR-K8sy rutas de VPC - Las redes secundarias de nivel 2 están aisladas por defecto sin acceso directo a Internet a menos que se configure explícitamente
- Adecuado para la comunicación entre servidores virtuales dentro del clúster y aplicaciones dependientes de la multidifusión
Redes OVN Localnet
Una red OVN Localnet proporciona a los servidores virtuales y pods acceso VLAN directo a la infraestructura de red VPC subyacente. OVN Localnet permite a los servidores virtuales y a los pods conectarse a subredes VPC utilizando una interfaz de red virtual (VNI) y adjuntos VLAN.
Con los adjuntos VLAN, puede adjuntar directamente servidores virtuales que se ejecutan en Red Hat OpenShift Virtualization a subredes VPC. Puede utilizar este enfoque para utilizar su diseño de subred de VPC existente para servidores virtuales nuevos o migrados, proporcionando una red coherente en todas sus cargas de trabajo.
La red localnet requiere que cada NIC de servidor virtual que se conecte a una subred VPC necesite los siguientes requisitos:
- Un recurso de interfaz de red virtual (VNI) que define una dirección IP reservada de la subred de la VPC y uno o varios grupos de seguridad que controlan el tráfico entrante y saliente a la VNI.
- Un anexo VLAN de servidor de metal desnudo. La capacidad de flotación de esta conexión a la VLAN, que determina si la conexión puede desplazarse entre nodos de trabajo, debe estar habilitada para que el servidor virtual pueda migrar en tiempo real a otro nodo de trabajo.
- UN ID DE VLAN. La etiqueta VLAN asocia la interfaz PCI en los nodos trabajadores. Normalmente, esta asociación es una correspondencia uno a uno entre el ID de VLAN y la subred de VPC.
Cuando diseñe reglas de grupos de seguridad para redes localnet, considere que parte de la conmutación de red ocurre dentro de OVS en el nodo trabajador y nunca llega a la infraestructura VPC. Las reglas de los grupos de seguridad se aplican únicamente al tráfico que atraviesa el tejido de red de la VPC. El tráfico entre servidores virtuales en el mismo nodo trabajador puede eludir los controles de seguridad de la VPC.
Los siguientes ejemplos son casos de uso de Localnet.
- Servidores virtuales migrados que requieren direcciones IP de subred de VPC existentes
- Integración con los grupos de seguridad VPC y las políticas de red existentes
- Conectividad directa a otros recursos de la VPC
- Requisitos de conformidad para la segmentación de redes mediante el uso de subredes VPC
- Arquitecturas híbridas que requieren un direccionamiento IP coherente entre VPC y Red Hat OpenShift Virtualization
Próximos pasos
Ahora que ya conoce el diseño de redes para la virtualización de Red Hat OpenShift, explore estos temas relacionados:
- Seguridad: Revisar las consideraciones de diseño de seguridad, incluidas las políticas de red y los SCC
- Computación: Explorar las opciones de diseño informático para los nodos trabajadores
- Almacenamiento: Conozca los patrones de diseño de almacenamiento para volúmenes persistentes
- Observabilidad: Comprender soluciones de observabilidad para la supervisión de redes