49 Resolución de problemas de aprovisionamiento de red dirigida #

En el aprovisionamiento de red dirigida se usan Metal³ y CAPI para aprovisionar el clúster descendente. También se usa EIB para crear una imagen del sistema operativo. Pueden surgir problemas cuando se arranca el host por primera vez o durante los procesos de inspección o aprovisionamiento.

Problemas comunes #

Firmware antiguo: compruebe que todo el firmware de los hosts físicos que se utilizan esté actualizado. Esto incluye el firmware de BMC, ya que en ocasiones Metal³ requiere un firmware específico/actualizado.
El aprovisionamiento falla con errores de SSL: si el servidor Web que proporciona las imágenes utiliza https, Metal³ debe configurarse para inyectar y confiar en el certificado de la imagen IPA. Consulte la carpeta de Kubernetes (Sección 40.3.4, “Carpeta kubernetes”) para obtener información sobre cómo incluir un archivo ca-additional.crt en el chart de Metal³.
Problemas con los certificados al arrancar los hosts con IPA: algunos proveedores de servidores verifican la conexión SSL al conectar imágenes ISO de medios virtuales al BMC, lo que puede causar un problema porque los certificados generados para el despliegue de Metal3 son autofirmados. Puede ocurrir que el host se esté arrancando, pero caiga a una shell UEFI. Consulte la sección sobre cómo inhabilitar TLS para la conexión de ISO de medios virtuales (Sección 1.6.2, “Inhabilitación de TLS para la conexión ISO de medios virtuales”) para averiguar cómo solucionar este problema.
Referencia de nombre o etiqueta incorrecta: si el clúster hace referencia a un nodo con un nombre o etiqueta incorrectos, el clúster se despliega correctamente, pero el BMH permanece con el estado "Available" (Disponible). Compruebe bien las referencias de los objetos involucrados para los BMH.
Problemas de comunicación de BMC: asegúrese de que los pods de Metal³ que se ejecutan en el clúster de gestión puedan acceder al BMC de los hosts que se están aprovisionando (normalmente, la red de BMC está muy restringida).
Estado incorrecto del host bare metal: el objeto BMH pasa por diferentes estados (inspección, preparación, aprovisionamiento, etc.) durante su ciclo de vida Lifestyle of State machine (Ciclo de vida de la máquina de estados). Si se detecta un estado incorrecto, compruebe el campo status del objeto BMH, ya que contiene más información, como kubectl get bmh <nombre> -o jsonpath=’{.status}’| jq.
El host no se ha desaprovisionado: en caso de que falle el desaprovisionamiento de un host, se puede intentar eliminarlo después de añadir la anotación "detached" al objeto BMH de la siguiente manera: kubectl annotate bmh/<BMH> baremetalhost.metal3.io/detached=””.
Errores de imagen: compruebe que la imagen que se está creando con EIB para el clúster descendente esté disponible, tenga una suma de comprobación correcta y no sea demasiado grande para descomprimirla ni para el disco.
Discrepancia en el tamaño del disco: de forma predeterminada, el disco no se expandirá hasta ocupar todo el espacio disponible. Como se explica en la sección del guion Growfs (Sección 1.3.4.1.2, “Guion Growfs”), es necesario incluir un guion growfs en la imagen que se está creando con EIB para los hosts del clúster descendente.
Proceso de limpieza bloqueado: el proceso de limpieza se reintenta varias veces. Si debido a un problema con el host ya no es posible realizar la limpieza, inhabilite primero la limpieza definiendo en el campo automatedCleanMode el valor disabled en el objeto BMH.
Aviso
No se recomienda eliminar manualmente el finalizador cuando el proceso de limpieza tarda más de lo deseado o falla. Si se hiciera, se eliminaría el registro del host de Kubernetes, pero se dejaría en Ironic. La acción que se está ejecutando actualmente continuaría en segundo plano, y es posible que el intento de volver a añadir el host fallara debido al conflicto.
Problemas en los pods de Metal3/Rancher Turtles/CAPI: el flujo de despliegue para todos los componentes necesarios es:
- El controlador de Rancher Turtles despliega el controlador del operador de CAPI.
- A continuación, el controlador del operador de CAPI despliega los controladores del proveedor (plano de control/arranque del núcleo de CAPI, CAPM3 y RKE2).

Compruebe que todos los pods funcionen correctamente y, si no fuera así, revise los registros.

Registros #

Registros de Metal³: consulte los registros de los distintos pods.
```
kubectl logs -n metal3-system -l app.kubernetes.io/component=baremetal-operator
kubectl logs -n metal3-system -l app.kubernetes.io/component=ironic
```
Nota
El pod metal3-ironic contiene al menos 4 contenedores distintos (ironic-httpd,` ironic-log-watch`, ironic e ironic-ipa-downloader (init)) en el mismo pod. Use el indicador -c cuando utilice kubectl logs para verificar los registros de cada contenedor.
Nota
El contenedor ironic-log-watch expone los registros del panel de control de los hosts tras la inspección o el aprovisionamiento, siempre que la conectividad de red permita enviar estos registros al clúster de gestión. Esto puede resultar útil en casos en los que se producen errores de aprovisionamiento, pero no se tiene acceso directo a los registros del panel de control de BMC.

Registros de Rancher Turtles: consulte los registros de los diferentes pods.

kubectl logs -n rancher-turtles-system -l control-plane=controller-manager
kubectl logs -n rancher-turtles-system -l app.kubernetes.io/name=cluster-api-operator
kubectl logs -n rke2-bootstrap-system -l cluster.x-k8s.io/provider=bootstrap-rke2
kubectl logs -n rke2-control-plane-system -l cluster.x-k8s.io/provider=control-plane-rke2
kubectl logs -n capi-system -l cluster.x-k8s.io/provider=cluster-api
kubectl logs -n capm3-system -l cluster.x-k8s.io/provider=infrastructure-metal3

Registros de BMC: por lo general, los BMC tienen una interfaz de usuario en la que se puede realizar la mayor parte de la interacción. Suele haber una sección de "registros" en la que se pueden observar posibles problemas (imposibilidad de acceder a la imagen, fallos de hardware, etc.).
Registros del panel de control: conéctese al panel de control de BMC (a través de la interfaz Web de BMC, en serie, etc.) y compruebe si hay errores en los registros que se están escribiendo.

Pasos para resolver problemas #

Compruebe el estado de BareMetalHost:
- kubectl get bmh -A muestra el estado actual, que puede ser provisioning, ready, error o registering.
- kubectl describe bmh -n <espaciodenombres> <nombre_bmh> proporciona información detallada sobre los eventos y condiciones que explican por qué un BMH podría estar bloqueado.
Pruebe la conectividad de Redfish:
- Use curl desde el plano de control de Metal³ para comprobar la conectividad con los BMC a través de Redfish.
- Asegúrese de que se proporcionan las credenciales de BMC correctas en la definición de BareMetalHost-Secret.
Verifique el estado del pod de turtles/CAPI/metal3: asegúrese de que los contenedores del clúster de gestión estén activos y en ejecución: kubectl get pods -n metal3-system y kubectl get pods -n rancher-turtles-system (consulte también capi-system, capm3-system, rke2-bootstrap-system y rke2-control-plane-system).
Verifique que se pueda acceder al punto final de Ironic desde el host que se está aprovisionando: el host que se está aprovisionando debe poder acceder al punto final de Ironic para informar a Metal³. Compruebe la IP con kubectl get svc -n metal3-system metal3-metal3-ironic e intente acceder a ella mediante curl/nc.
Verifique que se pueda acceder a la imagen IPA desde el BMC: el punto final Ironic proporciona la imagen IPA, a la que se debe poder acceder desde el BMC, ya que se utiliza como un CD virtual.
Verifique que se pueda acceder a la imagen del sistema operativo desde el host que se está aprovisionando: debe poder accederse a la imagen que se utiliza para aprovisionar el host desde el propio host (cuando se ejecuta IPA), ya que se descargará temporalmente y se escribirá en el disco.
Examine los registros de componentes de Metal³: consulte las secciones anteriores.
Vuelva a lanzar la inspección de BMH: si una inspección falla o cambia el hardware de un host disponible, se puede iniciar un nuevo proceso de inspección anotando el objeto BMH con inspect.metal3.io: "". Consulte la guía de inspección de control de Metal³ para obtener más información.
Panel de control IPA bare metal: para solucionar problemas relacionados con IPA, existen varias alternativas:
- Habilite el "inicio de sesión automático". Esto permite que el usuario root inicie sesión automáticamente al conectarse al panel de control de IPA.
  Aviso
  Esto es solo para fines de depuración, ya que proporciona acceso completo al host.
  Para habilitar el inicio de sesión automático, el valor de helm global.ironicKernelParams de Metal3 debe tener el siguiente aspecto: console=ttyS0 suse.autologin=ttyS0 (dependiendo del panel de control, ttyS0 puede cambiarse). A continuación, se debe realizar un nuevo despliegue del chart de Metal³. (Nota: ttyS0 es un ejemplo, debe coincidir con el terminal real, por ejemplo, puede ser tty1 en muchos casos en bare metal. Esto se puede verificar mirando la salida del panel de control desde el ramdisk de IPA al arrancar, donde /etc/issue produce el nombre del panel de control).
  Otra forma de hacerlo es cambiando el parámetro IRONIC_KERNEL_PARAMS en el mapa de configuración ironic-bmo del espacio de nombres metal3-system. Esto puede resultar más sencillo, ya que se puede hacer editando kubectl, pero se sobrescribirá al actualizar el chart. A continuación, es necesario reiniciar el pod de Metal³ con kubectl delete pod -n metal3-system -l app.kubernetes.io/component=ironic.
- Inyecte una clave ssh para el usuario root en el IPA.
  Aviso
  Esto es solo para fines de depuración, ya que proporciona acceso completo al host.
  Para inyectar la clave ssh para el usuario root, se debe utilizar el valor de helm debug.ironicRamdiskSshKey de Metal³. A continuación, se debe realizar un nuevo despliegue del chart de Metal³.
  Otra forma de hacerlo es cambiando el parámetro IRONIC_RAMDISK_SSH_KEY en el mapa de configuración ironic-bmo del espacio de nombres metal3-system. Esto puede resultar más sencillo, ya que se puede hacer editando kubectl, pero se sobrescribirá al actualizar el chart. A continuación, es necesario reiniciar el pod de Metal³ con kubectl delete pod -n metal3-system -l app.kubernetes.io/component=ironic.

Nota

Consulte las guías de resolución de problemas de CAPI y de resolución de problemas de Metal³.