Se aplica a SUSE Telco Cloud 3.7

24 Requisitos de puerto #

Para funcionar correctamente, un despliegue de SUSE Telco Cloud requiere que varios puertos sean accesibles en los nodos del clúster de gestión y en los nodos del clúster de Kubernetes en sentido descendente.

Nota

La lista exacta depende de los componentes opcionales desplegados y de las opciones de despliegue seleccionadas (p. ej., el complemento CNI).

24.1 Nodos de gestión #

La siguiente tabla enumera los puertos abiertos en los nodos que ejecutan el clúster de gestión:

Nota

Para los puertos relacionados con el complemento CNI, véase Requisitos de puerto específicos de CNI (Sección 24.3, “Requisitos de puerto específicos de CNI”).

Tabla 24.1: Reglas de red de entrada para nodos de gestión #

Protocolo	Puerto	Fuente	Descripción
TCP	22	Cualquier origen que requiera acceso SSH	Acceso SSH a los nodos del clúster de gestión
TCP	80	Equilibrador de carga/proxy que realiza la terminación TLS externa	Interfaz de usuario/API de Rancher cuando se utiliza la terminación TLS externa
TCP	443	Cualquier origen que requiera acceso TLS a la interfaz de usuario/API de Rancher	Agente de Rancher, interfaz de usuario/API de Rancher
TCP	2379	Nodos de servidor de RKE2 (clúster de gestión)	`etcd` Puerto de cliente
TCP	2380	Nodos de servidor de RKE2 (clúster de gestión)	`etcd` Puerto de par
TCP	6180	Cualquier BMC⁽¹⁾ al que `Metal³/ironic` haya indicado previamente que extraiga una imagen de disco RAM de IPA⁽²⁾ de este puerto expuesto (sin TLS)	`Ironic` Servidor web httpd sin TLS que sirve imágenes ISO de IPA⁽²⁾ para el arranque basado en medios virtuales En caso de que este puerto esté habilitado, el funcionalmente equivalente pero habilitado para TLS (véase más abajo) no se abre
TCP	6185	Cualquier BMC⁽¹⁾ al que `Metal³/ironic` haya indicado previamente que extraiga una imagen de disco RAM de IPA⁽²⁾ de este puerto expuesto (TLS)	`Ironic` Servidor web habilitado para TLS que sirve imágenes ISO de IPA⁽²⁾ para el arranque basado en medios virtuales En caso de que este puerto esté habilitado, el funcionalmente equivalente pero sin TLS (véase más arriba) no se abre
TCP	6385	Cualquier imagen de disco RAM de `Metal³/ironic` IPA⁽¹⁾ desplegada y ejecutándose en una instancia `BareMetalHost` "inscrita"	API de Ironic
TCP	6443	Cualquier nodo del clúster de gestión; cualquier cliente de Kubernetes externo (al clúster de gestión)	API de Kubernetes
TCP	6545	Cualquier nodo del clúster de gestión	Extraer artefactos de un registro compatible con OCI (Hauler)
TCP	9345	Nodos de servidor y agente de RKE2 (clúster de gestión)	API del supervisor de RKE2 para el registro de nodos (puerto abierto en todos los nodos de servidor de RKE2)
TCP	10250	Cualquier nodo del clúster de gestión	`kubelet` métricas
TCP/UDP/SCTP	30000-32767	Cualquier fuente externa (al clúster de gestión) que acceda a un servicio expuesto en la red principal a través de un `spec.type: NodePort` o `spec.type: LoadBalancer` objeto de API de servicio	Rango de puertos `NodePort` disponible

⁽¹⁾ BMC: Controlador de gestión de placa base
⁽²⁾ IPA: Ironic Python Agent

24.2 Nodos de sentido descendente #

En SUSE Telco Cloud, antes de que cualquier servidor en sentido descendente pase a formar parte de un clúster de Kubernetes en sentido descendente en ejecución (o ejecute por sí mismo un clúster de Kubernetes en sentido descendente de nodo único), es necesario que pase por algunos de los estados de aprovisionamiento de BaremetalHost.

El controlador de gestión de placa base (BMC) de un servidor en sentido descendente recién declarado debe ser accesible a través de la red fuera de banda. Se dan instrucciones al BMC (desde el servicio ironic que se ejecuta en el clúster de gestión) sobre los pasos iniciales a seguir:
1. Extraer y cargar la imagen de ramdisk de IPA indicada en el BMC ofrecido virtual media.
2. Encienda el servidor.

Se espera que los siguientes puertos estén expuestos desde el BMC (podrían diferir dependiendo del hardware exacto):

Tabla 24.2: Reglas de red de entrada para controladores de gestión de placa base (BMC) #

Protocolo	Puerto	Fuente	Descripción
TCP	80	Conductor de Ironic (desde el clúster de gestión)	Acceso a la API de Redfish (HTTP)
TCP	443	Conductor de Ironic (desde el clúster de gestión)	Acceso a la API de Redfish (HTTPS)

Una vez que la imagen de ramdisk IPA cargada en el BMC virtual media se utiliza para arrancar la imagen del servidor descendente, comienza la fase de inspección del hardware. La siguiente tabla enumera los puertos expuestos por una imagen de ramdisk IPA en ejecución:

Tabla 24.3: Reglas de red de entrada para nodos descendentes - Metal³/Ironic Fase de aprovisionamiento #

Protocolo	Puerto	Fuente	Descripción
TCP	22	Cualquier origen que requiera acceso SSH a la imagen de ramdisk IPA	Acceso SSH a un nodo de clúster descendente que está siendo inspeccionado
TCP	9999	Conductor de Ironic (desde el clúster de gestión)	Comandos de Ironic hacia la imagen de ramdisk en ejecución

Una vez que el host baremetal esté correctamente aprovisionado y se haya unido a un clúster de Kubernetes en sentido descendente, expone los siguientes puertos:

Nota

Para los puertos relacionados con el complemento CNI, véase Requisitos de puerto específicos de CNI (Sección 24.3, “Requisitos de puerto específicos de CNI”).

Tabla 24.4: Reglas de red de entrada para nodos descendentes #

Protocolo	Puerto	Fuente	Descripción
TCP	22	Cualquier origen que requiera acceso SSH	Acceso SSH a nodos de clúster descendentes
TCP	80	Equilibrador de carga/proxy que realiza la terminación TLS externa	Interfaz de usuario/API de Rancher cuando se utiliza la terminación TLS externa
TCP	443	Cualquier origen que requiera acceso TLS a la interfaz de usuario/API de Rancher	Agente de Rancher, interfaz de usuario/API de Rancher
TCP	2379	Nodos de servidor de RKE2 (clúster descendente)	`etcd` Puerto de cliente
TCP	2380	Nodos de servidor de RKE2 (clúster descendente)	`etcd` Puerto de par
TCP	6443	Cualquier nodo de clúster descendente; cualquier cliente de Kubernetes externo (al clúster descendente).	API de Kubernetes
TCP	9345	Nodos de servidor y agente de RKE2 (clúster descendente)	API del supervisor de RKE2 para el registro de nodos (puerto abierto en todos los nodos de servidor de RKE2)
TCP	10250	Cualquier nodo de clúster descendente	`kubelet` métricas
TCP	10255	Cualquier nodo de clúster descendente	`kubelet` acceso de sólo lectura
TCP/UDP/SCTP	30000-32767	Cualquier fuente externa (al clúster descendente) que acceda a un servicio expuesto en la red primaria a través de un `spec.type: NodePort` o `spec.type: LoadBalancer` objeto de API de servicio	Rango de puertos `NodePort` disponible

24.3 Requisitos de puerto específicos de CNI #

Cada variante de CNI compatible viene con su propio conjunto de requisitos de puerto. Para obtener más detalles, consulte Reglas de red de entrada específicas de CNI en la documentación de RKE2.

Cuando cilium se establece como el complemento CNI predeterminado/primario, el siguiente puerto TCP se expone adicionalmente cuando la carga de trabajo cilium-operator está configurada para exponer métricas fuera del clúster de Kubernetes en el que está desplegada. Esto garantiza que una instancia de servidor Prometheus externa que se ejecute fuera de ese clúster de Kubernetes aún pueda recopilar estas métricas.

Nota

Esta es la opción predeterminada al desplegar cilium a través del gráfico de Helm rke2-cilium.

Tabla 24.5: Reglas de red de entrada para nodos de gestión/sentido descendente: exposición de métricas externas desde cilium-operator habilitada #

Protocolo	Puerto	Fuente	Descripción
TCP	9963	Colector de métricas externo (al clúster de Kubernetes)	exposición de métricas de cilium-operator