Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Red Hat OpenShift en Azure con planos de control hospedados implementa nodos de trabajo en la red virtual Azure y usa una subred dedicada para establecer la conectividad privada entre el plano de control hospedado y los nodos de trabajo. Debe planear el diseño de la red virtual, las subredes y los intervalos de direcciones IP antes de crear el clúster.
Planificación de la capacidad de cómputo
Los grupos de nodos proporcionan capacidad de proceso. Un grupo de nodos es un grupo de nodos de trabajo que comparten el mismo tamaño de máquina virtual, configuración de disco y zona de disponibilidad. Puede crear varios grupos de nodos en un único clúster para ejecutar diferentes tipos de carga de trabajo en hardware diferente. Para conocer los tamaños de máquina virtual de nodo de trabajo admitidos, consulte Tamaños de máquina virtual admitidos. Varias decisiones del grupo de nodos afectan directamente al diseño de red, por lo que debe planear la capacidad de proceso antes de ajustar el tamaño de la red.
Responder a las siguientes preguntas le ayuda a planear las subredes y los intervalos de direcciones IP del clúster:
- ¿Cuántos grupos de nodos ejecutará? El número de grupos de nodos determina cuántas subredes podría necesitar. Si todos los grupos comparten la subred de trabajo predeterminada del clúster, una subred es suficiente. Si asigna subredes independientes a grupos diferentes, cada una aumenta los requisitos de CIDR de su red virtual y de sus máquinas.
- ¿Se desplegará en varias zonas de disponibilidad? Cada grupo de nodos se implementa en una sola zona de disponibilidad. Para distribuir cargas de trabajo entre zonas para alta disponibilidad, necesita un grupo de nodos independiente y posiblemente una subred independiente para cada zona. Más zonas significa más subredes y un CIDR de máquinas más grande.
- ¿Cada grupo de nodos usará su propia subred? Los grupos de nodos se implementan en la subred de trabajo predeterminada del clúster a menos que especifique una subred diferente. Las subredes independientes proporcionan aislamiento de red entre grupos de nodos, pero cada subred debe caber dentro del intervalo CIDR de la máquina y el espacio de direcciones de red virtual.
- ¿Cuántos nodos vas a ejecutar en el momento de máxima carga? El número máximo de nodos, incluidos los máximos de escalado automático, determina el tamaño que debe tener cada subred. El clúster admite un máximo de 500 nodos totales en todos los grupos.
- ¿Agregará más grupos de nodos más adelante? Los intervalos CIDR del clúster no se pueden cambiar después de la creación. Si planea agregar grupos de nodos con nuevas subredes en el futuro, el CIDR de la máquina y la red virtual deben tener suficiente espacio de direcciones para acomodarlos.
Sugerencia
Ejemplo de ajuste de tamaño: Un clúster con 3 zonas de disponibilidad, hasta 50 nodos por zona, y una subred independiente por zona necesita tres /26 subredes (64 direcciones cada una, que admiten 50 nodos más Azure direcciones reservadas) y una /29 subred de integración de red virtual.
Las cuatro subredes caben en un /24 CIDR de máquina (256 direcciones).
Si planea agregar más grupos de nodos más adelante, use un CIDR de máquina mayor, como /22 o /16 para dejar espacio para subredes adicionales.
Requisitos de subred
La red virtual debe contener los siguientes componentes:
- Subred de los nodos de trabajo - La subred predeterminada donde se despliegan los nodos de trabajo del clúster. Al crear un grupo de nodos, se implementa en esta subred a menos que especifique otra subred. Si planea implementar grupos de nodos en varias zonas de disponibilidad, puede crear una subred independiente para cada zona. Todas las subredes del grupo de nodos deben estar en la misma red virtual que el clúster. Ajustar el tamaño de cada subred en función del número de nodos de trabajo que planea ejecutar en ella.
-
Subred de integración de VNet - Una subred dedicada que permite la conectividad privada entre el plano de control alojado (que se ejecuta en la cuenta de Azure de Red Hat) y los nodos de trabajo en su suscripción. Debe cumplir los siguientes requisitos:
- Tamaño mínimo de
/29 - Ubicado en la misma red virtual que la subred de trabajo
- No se comparte con la subred de trabajo ni con ninguna subred del grupo de nodos
- Tamaño mínimo de
- Grupo de seguridad de red: un grupo de seguridad de red Azure que se crea y asocia a la subred de trabajo. Asigna el grupo de seguridad de red directamente a las subredes, y esta asignación es inmutable. No tiene los permisos para cambiarlo.
Requisitos de CIDR
En la tabla siguiente se describen los requisitos de red virtual y CIDR:
| Requisito de red | Default | Descripción |
|---|---|---|
| Rango CIDR de la máquina | 10.0.0.0/16 |
Intervalo de direcciones IP para los nodos de cómputo. Debe abarcar todos los intervalos de direcciones CIDR para las subredes de red virtual, incluidas las subredes que planee usar para grupos de nodos adicionales. Las subredes deben ser contiguas. Se admite un mínimo de 128 direcciones (/25) para implementaciones de zona de disponibilidad única. Se admite un mínimo de 256 direcciones (/24) para varias implementaciones de zona de disponibilidad. |
| Rango CIDR de servicios | 172.30.0.0/16 |
Rango de direcciones IP para las IP de servicio de Kubernetes. El intervalo debe ser lo suficientemente grande como para adaptarse a la carga de trabajo y no debe superponerse con ningún servicio externo al que se tenga acceso desde dentro del clúster. |
| Rango CIDR de Pod | 10.128.0.0/14 |
El intervalo de direcciones IP de los pods. El intervalo debe ser lo suficientemente grande como para adaptarse a la carga de trabajo y no debe superponerse con ningún servicio externo al que se tenga acceso desde dentro del clúster. |
| Prefijo de host | 23 |
Longitud del prefijo de subred asignado a cada nodo para sus pods. Un valor de 23 asigna una subred /23 (512 direcciones IP) por nodo del rango CIDR de pods. |
Use los valores predeterminados a menos que no cumplan sus requisitos. Si necesita cambiar cualquiera de estos valores, siga estas instrucciones:
- Los CIDR de pod, servicio y máquina no deben superponerse entre sí.
- Los bloques CIDR de pods y servicios no deben superponerse con ningún intervalo de direcciones en uso en su red ni con ninguna dirección utilizada por servicios externos a los que se acceda desde dentro del clúster.
- El CIDR de la máquina debe abarcar todas las subredes de red virtual usadas por el clúster, incluida la subred de trabajo, las subredes de grupo de nodos adicionales y la subred de integración de red virtual. Si planea agregar grupos de nodos con subredes independientes en el futuro, asegúrese de que el CIDR de la máquina es lo suficientemente grande como para incluirlos. Por ejemplo, si su VNet usa
10.0.0.0/16, el CIDR predeterminado de la máquina de10.0.0.0/16cubre todas las subredes. - La red de pods usa direcciones IP no enrutables y solo se usa dentro de la red definida por software del clúster.
Conectividad de clúster privado
Si elige un servidor de API privado, una entrada predeterminada privada o ambas, debe establecer la conectividad de red privada entre las redes de los usuarios y la red virtual del clúster antes de implementar el clúster. Sin esta conectividad, los administradores, las canalizaciones de CI/CD y los usuarios finales no pueden acceder a los puntos de conexión privados.
Entre las opciones de conectividad comunes se incluyen:
- Emparejamiento de redes virtuales de Azure - Conectar dos redes virtuales de Azure para que los recursos de cada red puedan comunicarse entre sí.
- Azure VPN Gateway: conecte la red local a la red virtual del clúster a través de un túnel VPN de sitio a sitio.
- Azure ExpressRoute: establezca una conexión privada dedicada desde la red local a Azure a través de un proveedor de conectividad.
Al planificar la conectividad de red privada, asegúrese de que los intervalos de direcciones IP de las redes emparejadas mediante peering o conectadas no se superpongan con los rangos CIDR de máquinas, de pods o de servicios del clúster.