40 Requisitos y supuestos #

40.1 Hardware #

Estos son los requisitos de hardware de SUSE Telco Cloud:

Clúster de gestión: el clúster de gestión tiene componentes como SUSE Linux Micro, RKE2, SUSE Rancher Prime y Metal³, y se utiliza para gestionar varios clústeres descendentes. Dependiendo del número de clústeres descendentes que se vayan a gestionar, los requisitos de hardware para el servidor pueden variar.
- Los requisitos mínimos para el servidor (MV o bare metal) son:
  - RAM: 8 GB como mínimo (se recomiendan al menos 16 GB)
  - CPU: 2 como mínimo (se recomiendan al menos 4 CPU)
Clústeres descendentes: los clústeres descendentes son los clústeres desplegados para ejecutar cargas de trabajo de telecomunicaciones. Hay requisitos específicos para habilitar ciertas capacidades de telecomunicaciones como SR-IOV, Optimización del rendimiento de la CPU, etc.
- SR-IOV: para adjuntar funciones virtuales (VF) en modo de encaminamiento a varias CNF/VNF, la tarjeta de interfaz de red debe admitir SR-IOV y VT-d/AMD-Vi debe estar habilitado en el BIOS.
- Procesadores CPU: para ejecutar cargas de trabajo específicas de telecomunicaciones, el modelo de procesador CPU debe adaptarse para permitir la mayoría de las funciones disponibles en esta tabla de referencia (Capítulo 42, Configuración de funciones de telecomunicaciones).
- Requisitos de firmware para la instalación con medios virtuales:
  Hardware del servidor Modelo de BMC Gestión
  Hardware Dell
  15.ª generación
  iDRAC9
  Hardware Supermicro
  01.00.25
  Supermicro SMC - Redfish
  Hardware HPE
  1.50
  iLO6

Hardware del servidor	Modelo de BMC	Gestión
Hardware Dell	15.ª generación	iDRAC9
Hardware Supermicro	01.00.25	Supermicro SMC - Redfish
Hardware HPE	1.50	iLO6

40.2 Red #

Como referencia para la arquitectura de red, el siguiente diagrama muestra una arquitectura de red típica para un entorno de telecomunicaciones:

La arquitectura de red se basa en los siguientes componentes:

Red de gestión: esta red se usa para la gestión de los nodos del clúster descendentes. Se utiliza para la gestión fuera de banda. Por lo general, esta red también está conectada a un conmutador de gestión independiente, pero puede conectarse al mismo conmutador de servicio mediante VLAN para aislar el tráfico.
Red de plano de control: esta red se usa para la comunicación entre los nodos del clúster descendente y los servicios que se ejecutan en ellos. Esta red también se utiliza para la comunicación entre los nodos y los servicios externos, como los servidores DHCP o DNS. En algunos casos, para entornos conectados, el conmutador/enrutador puede gestionar el tráfico a través de Internet.
Otras redes: en algunos casos, los nodos podrían conectarse a otras redes con fines específicos.

Nota

Para utilizar el flujo de trabajo de aprovisionamiento de red dirigida, el clúster de gestión debe tener conectividad de red con el controlador de gestión de la placa base (BMC) del servidor del clúster descendente, de modo que se puedan automatizar la preparación y el aprovisionamiento del host.

40.3 Requisitos de puertos #

Para funcionar correctamente, un despliegue de SUSE Telco Cloud requiere que se pueda acceder a un número de puertos en los nodos de los clústeres de gestión y descendentes de Kubernetes.

Nota

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

40.3.1 Nodos de gestión #

En la tabla siguiente se muestran los puertos abiertos en los nodos en los que se ejecuta el clúster de gestión:

Nota

Para los puertos relacionados con el complemento de CNI, consulte los requisitos específicos de CNI (Sección 40.3.3, “Requisitos específicos del puerto de CNI”).

Tabla 40.1: Reglas de red entrante para nodos de gestión #

Protocolo	Puerto	Origen	Descripción
TCP	22	Cualquier fuente que requiera acceso SSH	Acceso SSH a los nodos del clúster de gestión
TCP	80	Equilibrador de carga/proxy que realice una terminación TLS externa	Interfaz de usuario o API de Rancher si se usa terminación TLS externa
TCP	443	Cualquier fuente 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 RKE2 (clúster de gestión)	Puerto cliente `etcd`
TCP	2380	Nodos de servidor RKE2 (clúster de gestión)	Puerto de par `etcd`
TCP	6180	Cualquier BMC⁽¹⁾ al que `Metal³/ironic` haya solicitado previamente que extraiga una imagen ramdisk de IPA⁽²⁾ de su puerto expuesto (no TLS)	Servidor Web HTTPD `Ironic` que no sea TLS que proporcione imágenes ISO de IPA⁽²⁾ para el arranque basado en medios virtuales. Si este puerto está habilitado, el equivalente funcional con TLS habilitado (consulte más abajo) no se abre.
TCP	6185	Cualquier BMC⁽¹⁾ al que `Metal³/ironic` haya solicitado previamente que extraiga una imagen ramdisk de IPA⁽²⁾ de su puerto expuesto (TLS)	Servidor Web HTTPD `Ironic` con TLS habilitado que proporcione imágenes ISO de IPA⁽²⁾ para el arranque basado en medios virtuales. Si este puerto está habilitado, el equivalente funcional que no tenga TLS habilitado (consulte más arriba) no se abre.
TCP	6385	Cualquier imagen ramdisk de IPA⁽¹⁾ de `Metal³/ironic` que se ejecute en una instancia de `BareMetalHost` "inscrita"	API de Ironic
TCP	6443	Cualquier nodo de clúster de gestión; cualquier cliente de Kubernetes externo (al clúster de gestión)	API de Kubernetes
TCP	6545	Cualquier nodo de clúster de gestión	Extrae artefactos del registro conforme con OCI (Hauler)
TCP	9345	Servidor RKE2 y nodos de agente (clúster de gestión)	API de supervisor de RKE2 para el registro de nodos (puerto abierto en todos los nodos de servidor RKE2)
TCP	10250	Cualquier nodo de clúster de gestión	Métricas de `kubelet`
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 objeto API de servicio `spec.type: NodePort` o `spec.type: LoadBalancer`	Intervalo de puertos `NodePort` disponible

⁽¹⁾ BMC: Baseboard Management Controller (controlador de gestión de la placa base)
⁽²⁾ IPA: Ironic Python Agent (agente Python de Ironic)

40.3.2 Nodos descendentes #

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

El controlador de gestión de la placa base (BMC) de un servidor descendente recién declarado debe ser accesible a través de la red fuera de banda. El BMC recibe instrucciones (del servicio Ironic que se ejecuta en el clúster de gestión) sobre los pasos iniciales que debe seguir:
1. Extraer y cargar la imagen ramdisk de IPA indicada en el medio virtual ofrecido por el BMC.
2. Encender el servidor.

Se espera que los siguientes puertos estén expuestos desde el BMC (pueden variar en función del hardware concreto):

Tabla 40.2: Reglas de red entrante para controladores de gestión de la placa base #

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

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

Tabla 40.3: Reglas de red entrante para nodos descendentes: fase de aprovisionamiento de Metal³/Ironic #

Protocolo	Puerto	Origen	Descripción
TCP	22	Cualquier fuente que requiera acceso SSH a la imagen ramdisk de IPA	Acceso SSH a un nodo de clúster descendente que se esté inspeccionando
TCP	9999	Conductor de Ironic (del clúster de gestión)	Comandos de Ironic para ejecutar la imagen ramdisk en ejecución

Una vez que el host bare metal está correctamente aprovisionado y se ha unido a un clúster descendente de Kubernetes, expone los siguientes puertos:

Nota

Para los puertos relacionados con el complemento de CNI, consulte los requisitos específicos de CNI (Sección 40.3.3, “Requisitos específicos del puerto de CNI”).

Tabla 40.4: Reglas de red entrante para nodos descendentes #

Protocolo	Puerto	Origen	Descripción
TCP	22	Cualquier fuente que requiera acceso SSH	Acceso SSH a los nodos de los clústeres descendentes
TCP	80	Equilibrador de carga/proxy que realice una terminación TLS externa	Interfaz de usuario o API de Rancher si se usa terminación TLS externa
TCP	443	Cualquier fuente 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 RKE2 (clúster descendente)	Puerto cliente `etcd`
TCP	2380	Nodos de servidor RKE2 (clúster descendente)	Puerto de par `etcd`
TCP	6443	Cualquier nodo de clúster descendente; cualquier cliente de Kubernetes externo (al clúster descendente).	API de Kubernetes
TCP	9345	Servidor y nodos de agente de RKE2 (clúster descendente)	API de supervisor de RKE2 para el registro de nodos (puerto abierto en todos los nodos de servidor RKE2)
TCP	10250	Cualquier nodo de clúster descendente	Métricas de `kubelet`
TCP	10255	Cualquier nodo de clúster descendente	Acceso de solo lectura a `kubelet`
TCP/UDP/SCTP	30000-32767	Cualquier fuente externa (al clúster descendente) que acceda a un servicio expuesto en la red principal a través de un objeto API de servicio `spec.type: NodePort` o `spec.type: LoadBalancer`	Intervalo de puertos `NodePort` disponible

40.3.3 Requisitos específicos del puerto de CNI #

Cada variante de CNI compatible tiene su propio conjunto de requisitos de puerto. Para obtener más información, consulte CNI Specific Inbound Network Rules (Reglas de red entrantes específicas de CNI) en la documentación de RKE2.

Si Cilium se ha definido como complemento de CNI predeterminado/principal, el puerto TCP siguiente también se expone cuando la carga de trabajo cilium-operator se configura para exponer las métricas fuera del clúster de Kubernetes donde se ha desplegado. Esto garantiza que las instancias de servidor Prometheus externas que se ejecuten fuera del clúster de Kubernetes puedan seguir recopilando esas métricas.

Nota

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

Tabla 40.5: Reglas de red entrantes para nodos de gestión/descendentes: exposición externa de métricas de cilium-operator habilitada #

Protocolo	Puerto	Origen	Descripción
TCP	9963	Recopilador de métricas externo (al clúster de Kubernetes)	Exposición de métricas de cilium-operator

40.4 Servicios (DHCP, DNS, etc.) #

Algunos servicios externos como DHCP, DNS, etc. podrían ser necesarios dependiendo del tipo de entorno en el que se desplieguen:

Entorno conectado: en este caso, los nodos estarán conectados a Internet (a través de protocolos de enrutamiento L3) y el cliente proporcionará los servicios externos.
Entorno desconectado/aislado: en este caso, los nodos no tendrán conectividad IP a Internet y se necesitarán servicios adicionales para duplicar localmente el contenido requerido por el flujo de trabajo de aprovisionamiento de red dirigida.
Servidor de archivos: se utiliza para almacenar las imágenes del sistema operativo que se aprovisionarán en los nodos del clúster descendente durante el flujo de trabajo de aprovisionamiento de red dirigida. El chart de Helm de Metal³ puede desplegar un servidor multimedia para almacenar las imágenes del sistema operativo, consulte la siguiente sección (Nota), pero también es posible utilizar un servidor Web local existente.

40.5 Inhabilitación de servicios systemd #

Para las cargas de trabajo de telecomunicaciones, es importante inhabilitar o configurar adecuadamente algunos de los servicios que se ejecutan en los nodos para evitar cualquier impacto en el rendimiento de la carga de trabajo que se ejecuta en los nodos (latencia).

rebootmgr es un servicio que permite configurar una estrategia de rearranque cuando el sistema tenga actualizaciones pendientes. Para las cargas de trabajo de telecomunicaciones, es muy importante inhabilitar o configurar correctamente el servicio rebootmgr para evitar el rearranque de los nodos en caso de actualizaciones programadas por el sistema, con el fin de evitar cualquier impacto en los servicios que se ejecutan en los nodos.

Nota

Para obtener más información sobre rebootmgr, consulte el repositorio GitHub de rebootmgr.

Verifique la estrategia que se está utilizando ejecutando:

cat /etc/rebootmgr.conf
[rebootmgr]
window-start=03:30
window-duration=1h30m
strategy=best-effort
lock-group=default

Puede inhabilitarla ejecutando:

sed -i 's/strategy=best-effort/strategy=off/g' /etc/rebootmgr.conf

O con el comando rebootmgrctl:

rebootmgrctl strategy off

Nota

Esta configuración para establecer la estrategia de rebootmgr se puede automatizar mediante el flujo de trabajo de aprovisionamiento de red dirigida. Para obtener más información, consulte el capítulo correspondiente (Capítulo 43, Aprovisionamiento de red dirigida totalmente automatizado).

transactional-update es un servicio que permite actualizaciones automáticas controladas por el sistema. Para las cargas de trabajo de telecomunicaciones, es importante inhabilitar las actualizaciones automáticas para evitar cualquier impacto en los servicios que se ejecutan en los nodos.

Para inhabilitar las actualizaciones automáticas, puede ejecutar:

systemctl --now disable transactional-update.timer
systemctl --now disable transactional-update-cleanup.timer

fstrim es un servicio que permite recortar los sistemas de archivos automáticamente cada semana. Para las cargas de trabajo de telecomunicaciones, es importante inhabilitar el recorte automático para evitar cualquier impacto en los servicios que se ejecutan en los nodos.

Para inhabilitar el recorte automático, puede ejecutar:

systemctl --now disable fstrim.timer