2.5. Planificación de la red¶

2.5.1. Requisitos de red generales¶

• El tráfico de almacenamiento interno debe estar separado de otros tipos de tráfico.

2.5.2. Limitaciones de red¶

• Los nodos se añaden a los clústeres por su dirección IP, no por FQDN. Cambiar la dirección IP de un nodo en el clúster quitará dicho nodo del clúster. Si tiene pensado usar DHCP en un clúster, asegúrese de que las direcciones IP están acopladas a las direcciones MAC de las interfaces de red de los nodos.
• Cada nodo debe tener acceso a Internet para que puedan instalarse las actualizaciones.
• El valor de MTU está establecido en 1500 de forma predeterminada. Consulte la información de Paso 2: Configuración de la red sobre cómo configurar un valor de MTU óptimo.
• Se requiere la sincronización de hora a través de la red (NTP) para obtener estadísticas correctas. Se habilita de forma predeterminada mediante el servicio chronyd. Si desea usar ntpdate o ntpd, detenga y deshabilite chronyd primero.
• El tipo de tráfico Gestión interna se asigna automáticamente durante la instalación y no puede cambiarse en el panel de administración posteriormente.
• Aunque se puede acceder al nodo de gestión desde un navegador web mediante el nombre de host, es necesario especificar su dirección IP, no el nombre de host, durante la instalación.

2.5.3. Requisitos y recomendaciones de red por nodo¶

• Todas las interfaces de red en un nodo deben conectarse a subredes distintas. Una interfaz de red puede ser una interfaz lógica etiquetada de VLAN, un acoplamiento no etiquetado o un vínculo de Ethernet.

• Aunque los nodos de clúster tenga las reglas necesarias de iptables configuradas, le recomendamos utilizar un cortafuegos externo para redes públicas no seguras como Internet.

• Los puertos que se abran en los nodos de clúster dependen de los servicios que se ejecutarán en cada nodo y los tipos de tráfico asociados a los mismos. Antes de habilitar un determinado servicio en un nodo de clúster, debe asignar el tipo de tráfico correspondiente a una red a la que esté conectado dicho nodo. Al asignar un tipo de tráfico a una red, se configura un cortafuegos en los nodos conectados a esta red, se abren puertos específicos en las interfaces de red del nodo y se establecen las reglas iptables necesarias.

  La siguiente tabla incluye todos los puertos y servicios necesarios que se asocian a los nodos:

  Tabla 2.5.3.1 Puertos abiertos en nodos de clúster¶

  Servicio	Tipo de tráfico	Puerto	Descripción
  Panel de control web	Panel de administración*	TCP 8888	Acceso externo al panel de administración.
  	Panel de autoservicio	TCP 8800	Acceso externo al panel de autoservicio.
  Gestión	Gestión interna	cualquier puerto disponible	Gestión del clúster interno y transferencias de los datos de supervisión del nodo al panel de administración.
  Servicio de metadatos	Almacenamiento	cualquier puerto disponible	Comunicación interna entre servicios MDS y con servicios en bloque y clientes.
  Servicio de bloques		cualquier puerto disponible	Comunicación interna con servicios MDS y clientes.
  Cliente		cualquier puerto disponible	Comunicación interna con servicios MDS y en bloque.
  Puerta de enlace de la copia de seguridad	ABGW público	TCP 44445	Intercambio de datos externos con los agentes de Acronis Backup y Acronis Backup Cloud.
  	ABGW privado	cualquier puerto disponible	Gestión interna e intercambio de datos de varios servicios de Backup Gateway.
  iSCSI	iSCSI	TCP 3260	Intercambio de datos externos con el punto de acceso de iSCSI.
  S3	S3 público	TCP 80, 443	Intercambio de datos externos con el punto de acceso de S3.
  	OSTOR privado	cualquier puerto disponible	Intercambio de datos internos entre varios servicios de S3.
  NFS	NFS	TCP/UDP 111, 892, 2049	Intercambio de datos externos con el punto de acceso de NFS.
  	OSTOR privado	cualquier puerto disponible	Intercambio de datos internos entre varios servicios de NFS.
  Procesamiento	API de procesamiento*		Acceso externo a extremos de la API de OpenStack estándar:
  		TCP 5000	API Identity v3
  		TCP 6080	noVNC WebSocket Proxy
  		TCP 8004	API Orchestration Service v1
  		TCP 8041	API Gnocchi (servicio de medición de facturación)
  		TCP 8774	API de procesamiento
  		TCP 8776	API Block Storage v3
  		TCP 8780	API Placement
  		TCP 9292	API Image Service v2
  		TCP 9313	API Key Manager v1
  		TCP 9513	API Container Infrastructure Management (servicio de Kubernetes)
  		TCP 9696	API Networking v2
  		TCP 9888	API Octavia v2 (servicio del equilibrador de carga)
  	Equipo virtual privado	UDP 4789	Tráfico de red entre equipos virtuales en redes virtuales privadas.
  		TCP 5900-5999	VNC console traffic.
  	Copias de seguridad del equipo virtual	TCP 49300-65535	Acceso externo de NBD.
  SSH	SSH	TCP 22	Acceso remoto a los nodos a través del SSH.
  SNMP	SNMP*	UDP 161	Acceso externo a las estadísticas de supervisión del clúster de almacenamiento mediante el protocolo de SNMP.

  * Los puertos para este tipo de tráfico se deben abrir solo en nodos de gestión.

2.5.4. Requisitos de red de Kubernetes¶

Para implementar los clúster de Kubernetes en el clúster de procesamiento y trabajar con ellos, asegúrese de que la configuración de su red permite que los servicios de procesamiento y Kubernetes envíen las siguientes solicitudes de red:

1. La solicitud para arrancar el clúster etcd en el servicio de detección pública, desde todos los nodos de gestión hasta https://discovery.etcd.io mediante la red pública.
2. La solicitud para obtener el archivo «kubeconfig» de todos los nodos de gestión mediante la red pública:
   • Si la alta disponibilidad del equipo virtual maestro está habilitada, la solicitud se envía a la dirección IP pública o flotante del equipo virtual del equilibrador de carga asociado a la API Kubernetes en el puerto 6443.
   • Si la alta disponibilidad del equipo virtual maestro está deshabilitada, la solicitud se envía a la dirección IP pública o flotante del equipo virtual maestro de Kubernetes en el puerto 6443.
3. Las solicitudes de los equipos virtuales maestros de Kubernetes para las API de procesamiento (el tipo de tráfico API de procesamiento) a través de la red con el tipo de tráfico equipo virtual público (mediante una interfaz de red de un equipo virtual disponible públicamente o un enrutador virtual con SNAT habilitado). De forma predeterminada, la API de procesamiento se expone a través de la dirección IP del nodo de gestión, o de su dirección de IP virtual si está habilitada la alta disponibilidad). Sin embargo, también puede acceder a la API de procesamiento a través del nombre del DNS (consulte Setting a DNS Name for the Compute API).
4. La solicitud para actualizar el estado del miembro del clúster etcd en el servicio de detección público del equipo virtual maestro de Kubernetes a https://discovery.etcd.io a través de la red con el tipo de tráfico equipo virtual público (mediante una interfaz de red de un equipo virtual disponible públicamente o un enrutador virtual con SNAT habilitado).
5. La solicitud para descargar las imágenes del contenedor desde el depósito de Docker Hub público, desde el equipo virtual maestro de Kubernetes a https://registry-1.docker.io a través de la red con el tipo de tráfico equipo virtual público (mediante una interfaz de red de un equipo virtual disponible públicamente o un enrutador virtual con SNAT habilitado).

La red en la que cree un clúster de Kubernetes no debe superponerse con las siguientes redes predeterminadas:

• 10.100.0.0/24, utilizada en las conexiones de redes a nivel del pod
• 10.254.0.0/16, utilizada para asignar direcciones IP del clúster Kubernetes

2.5.5. Recomendaciones de red para clientes¶

La siguiente tabla muestra el máximo rendimiento de red que puede obtener un cliente con una interfaz de red específica. La recomendación para clientes es usar un hardware de red de 10 Gbps entre dos nodos de clúster y minimizar las latencias de red, especialmente si se usan discos SSD.